What is a CNI plugin, and what role does it play in Kubernetes networking?
Quick Answer
The Container Network Interface (CNI) is a standard plugin interface for configuring network connectivity for containers — Kubernetes itself doesn't implement pod-to-pod networking directly; it delegates that entirely to whichever CNI plugin is installed (Calico, Cilium, Flannel, and others). The CNI plugin is responsible for assigning Pod IP addresses and making sure every Pod can reach every other Pod across every node in the cluster, and, depending on the plugin, may also implement NetworkPolicy enforcement and other advanced networking features.
Detailed Answer
What Kubernetes requires, but doesn't itself implement
Kubernetes's networking model has a small number of hard requirements: every Pod gets its own IP, every Pod can reach every other Pod's IP without NAT (across the whole cluster, not just the local node), and a Pod sees the same IP for itself that other Pods use to reach it. Kubernetes itself has no built-in implementation of these requirements — it delegates entirely to whatever CNI plugin is installed, via the standard CNI interface (similar in spirit to how CRI standardizes the kubelet-to-runtime relationship — see that question).
kubelet, when starting a Pod:
→ calls the configured CNI plugin
→ CNI plugin assigns the Pod an IP, sets up its network namespace,
configures routes so it can reach other Pods cluster-wide
Common CNI plugins and their approaches
- Flannel — one of the simplest, focused primarily on providing basic cluster-wide Pod networking (often via a VXLAN overlay network); historically didn't support NetworkPolicy enforcement on its own.
- Calico — supports both a simpler routed (non-overlay) networking mode and NetworkPolicy enforcement; widely used specifically for clusters that need real network policy security.
- Cilium — built on eBPF (running programs directly in the Linux kernel rather than relying on iptables), offering high-performance networking, NetworkPolicy enforcement, and deep L7-aware observability/security features; increasingly popular for clusters wanting both performance and rich policy capability.
- AWS VPC CNI / Azure CNI / GCP's native networking — cloud-provider-specific CNI plugins that assign Pods IP addresses directly from the cloud's own VPC address space, integrating Kubernetes networking more tightly with the cloud's native networking and security groups.
Why the choice of CNI plugin genuinely matters
Beyond basic connectivity, the CNI plugin determines: whether NetworkPolicies are enforced at all (see that question), the underlying networking approach's performance characteristics (overlay/VXLAN vs. direct routing vs. eBPF), and whether advanced features like network observability, L7-aware policies, or multi-cluster networking are available. This is a foundational infrastructure decision typically made once when standing up a cluster, and switching CNI plugins on a live cluster is a genuinely disruptive operation — not something changed casually.
How this relates to Services and NetworkPolicies
Once the CNI plugin has established basic Pod-to-Pod IP connectivity across the cluster, Services (implemented via kube-proxy, layered on top of the CNI's basic connectivity) provide stable virtual IPs and load balancing, and NetworkPolicies (enforced by the CNI plugin itself, if it supports it) restrict which of those now-possible connections are actually allowed. All three layers work together: CNI provides the underlying "can any Pod technically reach any other Pod," Services provide "a stable way to address a group of Pods," and NetworkPolicies provide "which of these technically-possible connections are actually permitted."