Kubernetes Networking Definition

Kubernetes Networking Definition is the precise characterization of Kubernetes' networking model as a fixed set of formal requirements that any conforming network implementation must satisfy, independent of the specific technology used to satisfy them. Rather than mandating a single networking mechanism, Kubernetes defines networking by its required properties, universal Pod addressability and unmediated Pod-to-Pod reachability, and delegates the means of achieving those properties to pluggable Container Network Interface (CNI) implementations.

The Formal Requirements

Universal Pod IP Assignment

Every Pod, without exception, is formally guaranteed a unique IP address for the duration of its lifetime, assigned at creation by the configured CNI plugin, distinct from the IP address of any other simultaneously running Pod in the cluster.

Unmediated Pod-to-Pod Reachability

Any Pod is formally required to be able to communicate with any other Pod in the cluster using that Pod's actual IP address, without network address translation altering the source or destination address, regardless of which nodes the two Pods are running on.

Node Agent Reachability

Agents running on a node, most notably the kubelet, are formally required to be able to reach every Pod scheduled on that same node, a requirement distinct from and in addition to inter-Pod reachability, since it underlies the kubelet's ability to perform probes and other direct Pod interactions.

Host Network Consistency

A Pod configured to use the host's network namespace directly (hostNetwork: true) is formally defined to observe the same network namespace, and therefore the same view of ports and interfaces, as any other process running directly on that node.

What the Model Deliberately Leaves Unspecified

Implementation Mechanism

The networking model formally specifies outcomes, not mechanisms: whether Pod-to-Pod traffic is carried by an encapsulated overlay, routed directly using each Pod's real IP through the underlying network fabric, or integrated natively with a cloud provider's VPC addressing is left entirely to the CNI plugin in use.

Address Allocation Scheme

The model does not formally mandate any particular IP address range, subnetting scheme, or allocation algorithm; these are determined by the CNI plugin's own configuration, commonly a per-node CIDR block from which that node's Pods draw their addresses.

# Illustrative per-node pod CIDR allocation (mechanism-specific, not formally mandated)
apiVersion: v1
kind: Node
metadata:
  name: worker-node-3
spec:
  podCIDR: 10.244.3.0/24

Formal Role of the Container Network Interface

CNI as the Conformance Boundary

The Container Network Interface (CNI) is formally the plugin contract through which a cluster's chosen network implementation fulfills the model's required properties; the kubelet invokes the configured CNI plugin at Pod creation and deletion, and it is that plugin's responsibility to satisfy the addressing and reachability requirements described above.

ls /etc/cni/net.d/
kubectl get pods -n kube-system -l k8s-app=calico-node

Conformance, Not a Single Implementation

Because the requirements are defined independently of any specific plugin, multiple, architecturally distinct CNI implementations, overlay-based, routed, or cloud-native, can each satisfy the same formal model, which is why workload manifests written against the Kubernetes networking model behave consistently regardless of which specific CNI plugin a given cluster has installed.

Service Networking as a Distinct, Layered Concern

Built Atop, Not Part of, the Base Model

Service virtual IPs and the routing behavior kube-proxy implements are formally layered on top of the base Pod networking model rather than being part of its core requirements; the base model guarantees only that Pods can reach each other directly, while Service-level addressing is a separate abstraction implemented using that underlying reachability.

kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'
kubectl get pods -o wide

Why the Model Is Defined This Way

Specifying networking by required outcome rather than by mandated mechanism is what allows Kubernetes to run correctly across an enormous range of underlying infrastructure, bare metal, private data centers, and every major cloud provider, each with fundamentally different native networking characteristics, while still guaranteeing that any workload's expectations about Pod addressability and reachability hold true universally.