Cloud Native 8 min read

Choosing the Right CNI Plugin for Kubernetes: A Practical Guide

This article explains what the Container Network Interface (CNI) is, how Kubernetes uses CNI plugins, and provides a detailed comparison of Overlay, Routing, and Underlay plugins based on environment constraints, functional needs, and performance considerations.

Open Source Linux
Open Source Linux
Open Source Linux
Choosing the Right CNI Plugin for Kubernetes: A Practical Guide

1. What is CNI

CNI (Container Network Interface) is the standard API that Kubernetes uses to call network implementations. Kubelet invokes CNI plugins such as Calico, Flannel, Terway, Weave Net, and Contiv to configure pod networking.

2. How to Use CNI in Kubernetes

Kubernetes selects a CNI plugin via configuration files placed in /etc/cni/net.d/. The basic steps are:

Place a CNI configuration file (e.g., xxnet.conf) on each node.

Install the binary plugin referenced by the configuration.

When a pod is created, Kubelet reads the config and invokes the installed plugin.

The plugin configures the pod’s network.

The workflow is illustrated below:

3. Which CNI Plugin Is Right for Me

CNI plugins fall into three categories:

Overlay

Routing

Underlay

1. Environment Constraints

Virtualized environments (e.g., OpenStack) often restrict layer‑2 connectivity, so only Overlay plugins such as Flannel‑vxlan, Calico‑ipip, or Weave are viable.

Bare‑metal clusters have fewer restrictions, allowing Underlay or Routing plugins like Cilium‑BGP, Flannel‑hostgw, or SR‑IOV.

Public clouds also impose virtualized limits; using the cloud provider’s native CNI (e.g., Alibaba Cloud’s Terway) usually gives the best compatibility and performance.

2. Functional Requirements

Security: If you need NetworkPolicy support, choose plugins that implement it (e.g., Calico, Weave).

Cross‑cluster and external connectivity: For communication between pods and external VMs or physical machines, consider Underlay solutions (e.g., SR‑IOV) or routing plugins like Calico‑BGP.

Service discovery and load balancing: Not all plugins expose the pod network to kube‑proxy; ensure the chosen plugin supports these features if required.

3. Performance Requirements

Pod creation speed: Overlay and Routing plugins are faster for large‑scale pod bursts because they rely on kernel interfaces, while Underlay plugins may be slower due to additional network resource provisioning.

Network performance: Overlay adds encapsulation overhead, reducing bandwidth and increasing latency. For high‑performance workloads (e.g., machine learning, big data), prefer Underlay or Routing plugins.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeKubernetesCNINetwork Plugins
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.