Container networking in Kubernetes is managed by CNI (Container Network Interface) plugins. Network Policies enforce segmentation. Understanding these layers prepares you for service mesh patterns.
Container networking in Kubernetes is managed by CNI (Container Network Interface) plugins. Network Policies enforce segmentation. Understanding these layers prepares you for service mesh patterns.
Lesson outline
K8s requires a flat network where every Pod can communicate with every other Pod (across nodes) via IP address, without NAT.
This is achieved by a CNI plugin that manages IP allocation and routing. The control plane doesn't provide networking; it delegates to the plugin.
Node-to-node connectivity is handled by the cluster infrastructure (same subnet or overlay network).
Flannel: Simple overlay network using VXLAN or host-gateway. Easy to set up, good for testing, limited features.
Calico: BGP-based networking with network policies. More complex but powerful for production multi-cluster setups.
Cilium: eBPF-based networking with observability and network policies. Modern, high performance, good for security.
Weave: Mesh-based networking, simpler than Calico, includes built-in network policies.
Each plugin has trade-offs: performance, complexity, feature set, and operational overhead.
Within a node: Pods connect via the CNI plugin's virtual bridge (cni0). Communication is local.
Across nodes: CNI plugin tunnels traffic (VXLAN, encapsulation) or routes via BGP (Calico). IP ranges are coordinated so no two nodes have overlapping Pod CIDR.
Service IP routing: Services are implemented via iptables/IPVS rules on each node, not via DNS. kube-proxy updates these rules as endpoints change.
By default, all Pods can communicate with all Pods (no segmentation). NetworkPolicy objects define allow rules (whitelist approach).
Network policies are typically enforced by CNI plugins (Calico, Cilium, Weave). Not all plugins support NetworkPolicies (e.g., Flannel is minimal).
Policies can be pod-to-pod or namespace-wide. Default-deny policies are a security best practice.
Service meshes (Istio, Linkerd) sit on top of the underlying CNI layer. They inject sidecar proxies (Envoy) into every Pod to intercept and manage traffic.
This decouples the cluster networking (CNI) from application-layer networking (mesh). You can upgrade the mesh without touching the CNI.
Key takeaways
💡 Analogy
The Kubernetes networking model is like a city with mailboxes. The CNI plugin is the city infrastructure (roads, postal service). It ensures every address (Pod IP) is reachable. Network Policies are like traffic laws (allow/deny rules). Service Mesh is like hiring a traffic cop (sidecar proxies) at every mailbox to inspect packages (traffic) and apply routing rules. The underlying mail infrastructure (CNI) still works; the traffic cop just adds an extra layer.
⚡ Core Idea
CNI plugins implement the flat Pod networking model. Network Policies enforce segmentation. Service meshes add observability and control on top without changing the underlying network.
🎯 Why It Matters
Understanding CNI plugins helps you choose the right one for your cluster. Network Policies are essential for security. Service mesh preparation means understanding how the network layer will be enhanced.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.