Explain the Kubernetes networking architecture and its core components.
Quick Answer
Kubernetes networking provides a flat, non-NAT network where every Pod gets a unique IP address. This model is built on three layers: Pod networking (CNI for Pod-to-Pod communication), Service networking (kube-proxy for stable virtual IPs), and Ingress/Egress networking (for traffic entering and leaving the cluster).
Detailed Answer
Think of the Kubernetes network like a large office building's internal phone system. Every desk (Pod) gets its own unique extension number (IP address), and anyone can dial any other extension directly without going through an operator. This is the core principle: a flat network where all Pods can communicate with all other Pods without Network Address Translation (NAT).
The architecture is built on three main layers
1. Pod Networking (East-West Traffic): This layer handles direct communication between Pods. Kubernetes itself does not implement this; it delegates the task to a CNI (Container Network Interface) plugin. The CNI plugin (like Calico, Cilium, or Flannel) is responsible for assigning a unique IP address to every Pod and establishing routes between nodes so that Pods can communicate across the cluster. This is often achieved with an overlay network (like VXLAN) or by integrating directly with the underlying network fabric (using BGP).
2. Service Networking: This layer provides a stable endpoint for accessing a group of ephemeral Pods. Since Pods get new IPs when they restart, clients need a stable address. A Service provides a virtual IP (ClusterIP) and a DNS name. On each node, kube-proxy watches for Service and Endpoint changes and programs networking rules (using iptables, IPVS, or eBPF in modern CNIs) to intercept traffic destined for the Service's virtual IP and load-balance it to one of the healthy backend Pod IPs. This routing happens at the kernel level, making it highly efficient.
3. Ingress and Egress Networking: This layer manages traffic flowing into and out of the cluster. Ingress controllers (like NGINX, Traefik, or cloud-specific ones) manage external HTTP/S access, routing traffic based on hostname and path to internal Services. This allows many services to share a single load balancer. Egress controls how Pods connect to the outside world. This can be managed with NetworkPolicies that whitelist specific external CIDRs or through a dedicated egress gateway that provides a stable source IP for external services.