19 Kubernetes Networking

Kubernetes Networking is the set of principles and mechanisms that govern how Pods, Services, and nodes communicate within a cluster and with the outside world, built around a flat addressing model in which every Pod is directly reachable by every other Pod without manual network configuration.

Foundational Networking Requirements

The Flat Network Model

Kubernetes requires that every Pod be assigned its own IP address and be able to communicate with every other Pod in the cluster without network address translation, regardless of which node either Pod is running on. This requirement simplifies application design, since Pods can address each other directly rather than through per-node port mappings.

Node-to-Pod and Pod-to-Node Communication

In addition to Pod-to-Pod communication, nodes must be able to reach every Pod, and Pods must be able to reach every node, which is necessary for functions like health checking and for system components that need to communicate directly with workloads.

Container Network Interface

A Pluggable Networking Layer

Kubernetes itself does not implement Pod networking directly; instead, it delegates this responsibility to a Container Network Interface (CNI) plugin, which is responsible for allocating IP addresses to Pods and configuring the underlying network paths between them.

Overlay vs. Native Routing

Different CNI plugins implement the flat network model using different underlying strategies, such as overlay networks that encapsulate Pod traffic within tunnels between nodes, or native routing approaches that advertise Pod subnets directly through protocols like BGP, each with different tradeoffs in performance and complexity.

Service Networking

Virtual IPs

Services introduce a separate, virtual IP address space distinct from Pod IPs, providing a stable address that persists even as the underlying Pods backing it change, implemented through rules maintained by kube-proxy on every node.

kube-proxy Modes

kube-proxy can implement Service routing using different modes, such as iptables or IPVS, which differ in how they intercept and redirect traffic destined for a Service's virtual IP toward one of its backing Pod IPs.

DNS

Cluster-Internal Name Resolution

Kubernetes runs a cluster DNS service that automatically provisions DNS records for Services and, optionally, for individual Pods, allowing workloads to resolve one another by predictable hostnames rather than needing to hardcode or discover IP addresses.

External Connectivity

Exposing Services Outward

Traffic originating from outside the cluster reaches internal Pods through mechanisms such as NodePort, which opens a static port on every node, or LoadBalancer, which provisions an external load balancer through a cloud provider integration.

Ingress

Ingress resources provide a higher-level entry point for HTTP and HTTPS traffic, allowing host and path-based routing rules to direct external requests to the correct internal Service, along with centralized TLS certificate management.

Network Policy

Default Openness

By default, all Pods in a cluster can communicate with all other Pods without restriction, since the flat network model does not itself impose any access control between them.

Restricting Traffic

NetworkPolicies allow operators to define explicit rules restricting which Pods can communicate with which others, based on label selectors, namespaces, or IP blocks, layering access control on top of the otherwise permissive flat network.

Networking Layers Diagram