CNI: The Universal Plug for Container Networking

WHY IT EXISTS Before CNI, container runtimes had their own tightly-coupled networking models. This made it difficult to swap out networking solutions or innovate independently. A standard was needed to decouple the runtime (which creates and runs containers) from the network implementation (which connects them).

THE MENTAL MODEL CNI is a specification, not an implementation. It's a contract between a container runtime and a networking plugin. Think of it like a USB standard for networking: the runtime doesn't need to know the specifics of a network, only how to talk to the CNI interface. The CNI plugin you install handles all the details of its specific network technology.

HOW IT WORKS When a container is created, the container runtime (e.g., containerd in Kubernetes) executes a CNI plugin binary. The runtime passes configuration and the container's network namespace details to the plugin. The plugin then performs the necessary actions—like creating a virtual ethernet pair, assigning an IP address, and setting up routes. It returns the result to the runtime as JSON. When the container is deleted, the runtime calls the plugin again to tear down the network and clean up all allocated resources.

WHEN TO USE IT CNI is the de facto standard for networking in Kubernetes environments. The kubelet invokes a CNI plugin to provide network connectivity for pods. This allows operators to choose from a wide range of networking solutions (like Calico, Cilium, or Flannel) based on their requirements for performance, security, or policy enforcement, without changing the orchestrator itself.

WHEN NOT TO USE IT If you are running a simple, single-host setup with a tool like Docker Desktop, you'll likely use its built-in networking, which does not use CNI by default. CNI's primary value is in orchestrated, multi-host environments where network pluggability and interoperability are key requirements. For simple local development, it's often overkill.

ONE CANONICAL EXAMPLE A Kubernetes cluster administrator installs the Cilium CNI plugin on all nodes. When the kubelet on a node needs to start a new pod, it calls the Cilium CNI binary. Cilium assigns an IP address, uses eBPF to efficiently wire up the pod's networking within the host's kernel, and applies any relevant NetworkPolicies. The kubelet itself remains completely unaware of Cilium's eBPF-based implementation details.