Kubernetes Cluster Network Model

Kubernetes Cluster Network Model is the foundational networking contract that every Kubernetes cluster must satisfy so that Pods, Services, and Nodes can communicate consistently regardless of the underlying network implementation. It is not a single technology but a set of requirements — defined by the Kubernetes networking model — that any Container Network Interface (CNI) plugin or cloud provider network must fulfill before it can be considered conformant.

Core Requirements of the Model

Pod-to-Pod Communication Without NAT

Every Pod in the cluster receives its own unique IP address from the cluster's Pod CIDR range. Pods can reach each other's IP addresses directly, without Network Address Translation (NAT), regardless of which Node they are scheduled on. This means a Pod on Node A can communicate with a Pod on Node B as if they were on the same flat network segment.

Node-to-Pod Communication

Nodes must be able to communicate with all Pods on that Node, and, in most implementations, all Pods on any Node in the cluster, without NAT. This property allows system components such as kubelet, kube-proxy, and node-level agents to reach Pods directly for health checks, log collection, and monitoring.

The "IP-per-Pod" Principle

A Pod's IP address is shared by all containers within that Pod. Containers inside a Pod communicate with each other over localhost, sharing the same network namespace. This eliminates the historical port-mapping complexity found in classic container platforms, since each Pod behaves like a distinct virtual host with its own IP.

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    ports:
    - containerPort: 8080
  - name: sidecar
    image: envoyproxy/envoy:v1.28
    ports:
    - containerPort: 9901

In this example, app and sidecar share the same Pod IP and can reach each other via localhost:8080 and localhost:9901.

Network Layers in a Cluster

Node Network

The Node network is the physical or virtual network that connects the cluster's Nodes to one another, typically provisioned by the underlying infrastructure (VPC, on-premises VLAN, or bare-metal switch fabric). This layer is outside Kubernetes' direct control but is a prerequisite for the other layers to function.

Pod Network

The Pod network is the overlay or underlay network fabric implemented by the CNI plugin. It assigns Pod CIDRs to Nodes and routes traffic between Pods across Node boundaries. Depending on the plugin, this can be implemented as:

• Overlay networks (e.g., VXLAN, IP-in-IP) that encapsulate Pod traffic inside Node network packets.
• Underlay/routed networks (e.g., BGP-based routing with Calico) that advertise Pod CIDRs directly to the physical network fabric, avoiding encapsulation overhead.

Service Network

The Service network is a separate virtual IP range (ClusterIP range) used exclusively for stable Service endpoints. These IPs are not attached to any real network interface; they are implemented through kube-proxy rules (iptables, IPVS, or eBPF) that translate Service IP traffic into one of the backing Pod IPs.

kubectl get svc -o wide
kubectl describe svc my-service

CNI Plugins and the Network Model

Role of the Container Network Interface

The CNI specification defines a standard interface between the container runtime and network plugins. When a Pod is created, the kubelet invokes the configured CNI plugin to allocate an IP address, set up virtual network interfaces (veth pairs), and configure routes so the Pod can reach the rest of the cluster.

Common CNI Implementations

• Calico — provides both overlay and BGP-routed underlay modes, plus network policy enforcement.
• Cilium — implements networking and observability using eBPF, bypassing traditional iptables datapaths.
• Flannel — a simple overlay network using VXLAN, often chosen for its low operational complexity.
• AWS VPC CNI / Azure CNI / GCP VPC-Native — cloud-native implementations that assign Pods real VPC IP addresses.

IPAM (IP Address Management)

Each CNI plugin implements an IPAM component responsible for allocating Pod IPs from the cluster's configured Pod CIDR blocks. The --pod-cidr or --cluster-cidr flags on the API server and controller manager define the address space that IPAM plugins draw from.

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

DNS and Service Discovery

Cluster DNS

CoreDNS (or kube-dns in legacy clusters) runs as a cluster-internal DNS service, resolving Service names to their ClusterIP addresses. Every Service automatically receives a DNS record in the form <service-name>.<namespace>.svc.cluster.local.

Pod DNS Records

Pods with hostname and subdomain fields, combined with a headless Service, receive individual DNS A/AAAA records, enabling direct addressing of specific Pod replicas — a pattern commonly used by StatefulSets.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    app: my-statefulset
  ports:
  - port: 80

Network Policies and Traffic Control

Default Allow-All Behavior

By default, the Kubernetes network model permits all Pods to communicate with all other Pods; there is no implicit isolation. Segmentation must be explicitly defined through NetworkPolicy resources, which are enforced only if the CNI plugin supports them.

Defining Ingress and Egress Rules

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Namespace-Level Isolation

NetworkPolicies can also select entire namespaces using namespaceSelector, enabling multi-tenant clusters to restrict cross-namespace traffic while still allowing controlled communication paths between trusted namespaces.

Practical Implications for Cluster Design

CIDR Planning

Cluster architects must plan non-overlapping CIDR ranges for the Node network, Pod network, and Service network to avoid routing conflicts, especially in hybrid or multi-cluster environments that may later be interconnected via VPC peering or service mesh federation.

Scalability Considerations

The chosen CNI's IPAM strategy directly affects how many Pods can run per Node and how large the cluster can grow, since each Node is typically allocated a fixed-size Pod CIDR block (commonly a /24) carved out of the broader cluster Pod CIDR.

Observability of the Network Layer

Because the network model spans multiple layers — Node, Pod, and Service — troubleshooting connectivity issues typically requires inspecting routes, iptables/IPVS rules, and CNI-specific diagnostics (e.g., calicoctl node status, cilium status) in addition to standard kubectl commands.