2.10 Kubernetes Cluster Networking Architecture
Kubernetes Cluster Networking Architecture defines how nodes communicate, ensuring reliable and secure containerized application traffic across a distributed system.
Kubernetes Cluster Networking Architecture is the specific internal arrangement of the components that implement cluster-wide connectivity, describing how the CNI plugin, kube-proxy, and cluster DNS are layered together across nodes to jointly satisfy the flat Pod networking model while also providing stable Service addressing and name resolution.
Layering of Networking Responsibilities
CNI Plugin at the Pod Network Layer
The CNI plugin is architected to operate at the lowest layer of cluster networking, responsible for allocating an IP address to each new Pod and establishing the actual data path that allows that Pod's traffic to reach other Pods across the cluster, regardless of which node they reside on.
kube-proxy at the Service Routing Layer
Above the raw Pod network, kube-proxy is architected as a per-node component that installs routing rules translating traffic destined for a Service's virtual IP into traffic destined for one of that Service's currently healthy backing Pod IPs, relying on the connectivity the CNI layer already provides.
Distributed, Per-Node Architecture
No Central Routing Authority
Both the CNI plugin's data path configuration and kube-proxy's routing rules are architected to be applied independently on every node, meaning there is no single central router through which all cluster traffic passes; each node is responsible for correctly routing traffic based on its own locally maintained rules.
Consistency Achieved Through Shared Source of Truth
Despite this distributed enforcement, consistency across nodes is achieved because every node's kube-proxy derives its rules from the same EndpointSlice data served by the API server, ensuring that routing decisions converge to the same view of healthy backends everywhere.
DNS as a Workload Riding on the Same Network
Cluster DNS Deployed as an Ordinary Workload
Cluster DNS is architected not as a special networking primitive but as an ordinary workload running on the Pod network like any other application, exposed through its own Service, meaning DNS queries themselves traverse the same CNI and kube-proxy layers used by all other cluster traffic.
External Connectivity Layering
Ingress and LoadBalancer Types Building on the Same Foundation
Mechanisms for external connectivity, such as Ingress controllers or Services of type LoadBalancer, are architected as additional layers built on top of the same underlying Pod network and Service routing infrastructure, rather than as separate, parallel networking stacks.