Kubernetes Networking Boundary

Kubernetes Networking Boundary refers to the conceptual and practical dividing line between what Kubernetes itself defines and manages as part of its networking model, and what it explicitly delegates to external components, the underlying infrastructure, or the cluster operator's own configuration choices.

What Kubernetes Defines

The Networking Model's Core Requirements

Kubernetes specifies a small set of foundational requirements that any conforming network implementation must satisfy: every pod must be able to communicate with every other pod without network address translation between them, every node must be able to communicate with every pod, and a pod must see its own IP address the same way other pods see it. These requirements form the boundary of what Kubernetes itself guarantees; everything beyond that is left to the chosen implementation.

Abstractions Kubernetes Owns

Kubernetes directly defines and manages the API objects that describe desired networking behavior, Service, EndpointSlice, NetworkPolicy, Ingress, and Gateway API resources, along with the Node object's pod CIDR allocation. These are declarative intents; Kubernetes itself does not perform the packet forwarding required to realize them.

What Kubernetes Delegates

CNI Plugin Responsibility

The actual mechanics of assigning pod IPs, creating interfaces, and establishing cross-node connectivity are delegated entirely to a CNI plugin chosen and installed by the cluster operator. Kubernetes defines the interface contract, the CNI specification, through which it invokes this plugin, but has no built-in implementation of pod networking itself.

Service Data Plane Implementation Choice

Kubernetes defines the Service abstraction's expected behavior but does not mandate a specific data plane implementation; kube-proxy is the reference implementation, but the boundary explicitly allows CNI plugins to substitute their own data plane, including bypassing kube-proxy entirely with an eBPF-based alternative, as long as observed Service behavior matches the API contract.

Infrastructure-Level Boundary

Underlying Physical or Virtual Network

Kubernetes networking assumes the existence of some underlying Layer 3 network connecting nodes to each other, but does not manage or configure that network itself. Whether nodes sit on a flat Layer 2 segment, span multiple subnets, or reside in different cloud regions is entirely outside Kubernetes' awareness; the CNI plugin and cluster operator are responsible for ensuring the assumed connectivity actually exists.

External Load Balancers and DNS

Provisioning of external cloud load balancers for LoadBalancer-type Services, and the external DNS records that might point to them, are handled by cloud controller managers and external-facing automation, not by Kubernetes' core networking model, marking a clear boundary between cluster-internal networking concerns and the surrounding infrastructure.

Security Boundary Implications

NetworkPolicy as Declared Intent Only

Because NetworkPolicy objects are only enforced if the CNI plugin implements that enforcement, the boundary between Kubernetes' declared security intent and actual enforced behavior is a meaningful gap that operators must explicitly verify closes, rather than something guaranteed simply by creating the API objects.

Node-Level Trust Assumptions

Kubernetes' networking model does not attempt to protect against a compromised node tampering with its own networking configuration; the boundary of Kubernetes' security guarantees generally assumes the underlying node OS and its network stack are trustworthy, with additional hardening left to the operator's infrastructure security practices.

Practical Consequences of the Boundary

Why Implementation Choice Matters

Because so much of actual networking behavior, connectivity model, performance characteristics, policy enforcement capability, sits on the delegated side of this boundary, two Kubernetes clusters running identical application manifests can behave very differently at the network level purely due to differing CNI plugin and infrastructure choices, which is why understanding this boundary is essential to reasoning correctly about cluster networking behavior.