How does the Kubernetes network model work, and what does a CNI plugin provide?
Quick Answer
Kubernetes requires a flat network where every pod gets its own IP and can reach every other pod without NAT. A CNI (Container Network Interface) plugin — Calico, Cilium, Flannel, etc. — implements that pod networking, and some also enforce NetworkPolicy.
Detailed Answer
The model has three rules: every pod gets a unique IP, all pods can communicate with all pods across nodes without NAT, and agents on a node can reach pods on that node. Kubernetes itself doesn't implement this — it delegates to a CNI plugin the kubelet calls when a pod is created. Plugins differ in approach: Flannel is simple overlay (VXLAN), easy but no policy; Calico can do pure L3 routing (BGP) or overlay and enforces NetworkPolicy; Cilium uses eBPF for high-performance networking, policy, and observability, and can even replace kube-proxy. Choosing a CNI is a real decision: you weigh performance, whether you need NetworkPolicy enforcement (kubenet/Flannel don't), encryption (WireGuard/IPsec), and features like egress gateways. If NetworkPolicies seem ignored, it's almost always because the CNI doesn't enforce them.
Code Example
kubectl get pods -n kube-system | grep -Ei 'calico|cilium|flannel' # Each pod gets a routable IP: kubectl get pods -o wide # note unique POD IPs across nodes, no NAT between them
Interview Tip
State the model as three rules (pod IP, no-NAT pod-to-pod, node-to-pod), then note the practical trap: 'NetworkPolicy is silently ignored if your CNI doesn't enforce it (e.g., Flannel).' Mention Cilium/eBPF for current credibility.