Demystifying the Kubernetes Networking Model: From Pods to Services

Kubernetes is built for running distributed clusters, and networking is a core component; understanding its networking model enables correct operation, monitoring, and troubleshooting of applications.

Kubernetes Basics

The platform consists of several core concepts. The API server (kube‑apiserver) exposes the cluster state via API calls and stores desired state in etcd. Controllers continuously reconcile the actual state with the desired state, as illustrated by the following pseudocode:

while true:
    X = currentState()
    Y = desiredState()
    if X == Y:
        return  # Do nothing
    else:
        do(tasks to get to Y)

Pods are the smallest deployable unit, each receiving a unique IP address and sharing a network namespace. Nodes are the machines (bare‑metal, VM, etc.) that run the cluster.

Kubernetes Network Model

Kubernetes imposes three fundamental requirements on any network implementation:

All Pods must communicate with each other without Network Address Translation (NAT).

All Nodes must communicate with all Pods without NAT.

Each Pod must see its own IP address exactly as other Pods see it.

These requirements lead to four networking problems:

Container‑to‑container networking

Pod‑to‑Pod networking

Pod‑to‑Service networking

Internet‑to‑Service networking

Container and Container Communication

Linux places each process in a network namespace, giving it an independent routing table, firewall rules, and network devices. Namespaces can be created with ip netns add ns1 and inspected under /var/run/netns.

By default, every process belongs to the root network namespace, which provides external connectivity.

Pods are modeled as a set of Docker containers sharing a network namespace; all containers in a Pod share the same IP address and port space and can reach each other via localhost. The diagram below shows the relationship between a Pod, its containers, and the shared namespace.

Pod‑to‑Pod Communication

Each Pod has a real IP address and communicates directly with other Pods, whether they reside on the same node or different nodes. On the same node, a veth pair connects the Pod's network namespace to the root namespace, and a Linux bridge (cbr0) forwards traffic between veth interfaces. The packet flow is illustrated in the following GIF.

For cross‑node communication, each node receives a CIDR block for its Pods. When a packet reaches a node, the node routes it to the appropriate Pod based on the CIDR. In AWS, the Amazon VPC CNI plugin creates an Elastic Network Interface (ENI) for each Pod, allowing Pod IPs to be routable within the VPC.

Pod‑to‑Service Communication

Services provide a stable virtual IP (ClusterIP) that abstracts a set of Pods. kube‑proxy installs iptables (or IPVS) rules that rewrite the destination IP from the Service IP to a selected Pod IP. The return path uses conntrack to rewrite the source IP back to the Service IP, ensuring the client always sees the Service address.

Service‑to‑Pod Communication

When a Pod sends traffic to a Service IP, iptables rewrites the destination to the target Pod IP. The response packet’s source IP is rewritten back to the Service IP before leaving the node, preserving the illusion of a single endpoint.

DNS in Kubernetes

Kubernetes runs a DNS service (kubedns or CoreDNS) that maps Service names to ClusterIP addresses. The DNS deployment typically consists of three containers: kubedns (watches the API server), dnsmasq (caches queries), and a sidecar for health checks.

Internet‑to‑Service Traffic (Egress)

Pods cannot be NAT‑ed directly by an external Internet gateway because the gateway only knows node IPs. iptables on each node performs source NAT (SNAT) to masquerade Pod IPs as the node’s IP before traffic leaves the cluster.

Internet‑to‑Service Traffic (Ingress)

Ingress exposes HTTP/HTTPS services outside the cluster. Two common implementations are:

LoadBalancer services that provision a cloud provider’s external load balancer.

Ingress Controllers (e.g., AWS ALB Ingress Controller) that route traffic based on URL paths to Services.

Both rely on the same iptables (or IPVS) rules installed by kube‑proxy to forward traffic from the load balancer to the correct Pods.

Summary

This guide provides a foundation for understanding the Kubernetes networking model and how it supports common networking tasks such as intra‑cluster communication, Service abstraction, and external traffic handling.

Glossary

Key terms include Layer‑2 networking, Layer‑4 (TCP), Layer‑7 (HTTP), NAT, SNAT, DNAT, network namespaces, veth pairs, bridges, CIDR, CNI, VIP, netfilter, iptables, conntrack, and IPVS.