What is a CNI plugin?
A CNI plugin is the program that gives a Kubernetes pod its network. When a pod starts, the container runtime on the node calls the plugin, which creates the pod’s network interface, assigns it an IP address and sets up routes. CNI stands for Container Network Interface, the spec that defines how runtimes and plugins talk.
Think of a new tenant moving into an office building. Facilities gives them a desk, a phone extension and a line into the building’s switchboard. The CNI plugin is facilities: every new pod gets an address and a connection, and loses both when it leaves.
Kubernetes itself only sets the rules. Every pod gets its own cluster-wide IP, and pods reach each other directly without NAT. The CNI plugin is what makes those rules true.
What does a CNI plugin do?
The runtime runs the plugin as a binary, passes its configuration as JSON on standard input and reads the result from standard output. The spec defines a few operations:
- ADD connects a new pod and returns its interface and IP.
- DEL removes the pod’s network setup. It may run more than once, so it should succeed even if parts are already gone.
- CHECK verifies that the network still matches what ADD set up.
- GC and STATUS clean up stale IP reservations and report whether the plugin is ready.
IP address management
Handing out addresses is often delegated to a separate IPAM plugin. The main plugin calls it to get an IP, gateway and routes for the pod. Plugins can also be chained, so a port-mapping or bandwidth plugin runs after the main one.
Network policies
A NetworkPolicy object restricts which pods may talk to each other. The plugin enforces it. If your plugin has no policy support, the API still accepts the object, but it has no effect and nothing warns you. Without any policy selecting a pod, all traffic in and out is allowed.
How do pod packets cross between nodes?
Overlay networks
In overlay mode, the plugin wraps pod packets in VXLAN or Geneve and tunnels them between nodes. The underlying network only needs normal node-to-node connectivity. The cost is header overhead: VXLAN over IPv4 adds 50 bytes per packet, which lowers the usable MTU.
Native routing
In native routing, pod packets travel unwrapped, and the network has to know where each pod range lives. When all nodes share one L2 segment, each node can add direct routes to the others’ pod ranges. Otherwise a routing protocol such as BGP announces the pod routes.
eBPF dataplanes
Some plugins, Cilium among them, program the Linux kernel with eBPF instead of long iptables chains. Some of them also replace kube-proxy with their own Service proxy.
How enum handles CNI plugins
enum Kubernetes Engine runs Cilium, with eBPF networking in the node kernel and network policies enforced with eBPF. Most teams separate workloads with namespaces and network policies on one cluster. If you plan to bring your own plugin, ask us before you build on it.
FAQ
Can I change the CNI plugin on a running cluster? It is possible but disruptive, because every pod has to be reconnected through the new plugin. The safer path is usually to build a new cluster with the target plugin and move workloads over, instead of swapping it in place.
Does every CNI plugin support NetworkPolicy? No. Some simple plugins only connect pods and ignore policies. The API accepts the policy objects anyway, so test that a deny rule really blocks traffic before you rely on it.
Does a CNI plugin handle IPv6? Only if it supports it. A dual-stack cluster needs a plugin that assigns both an IPv4 and an IPv6 address per pod, plus nodes with routable addresses for both families.