Kubernetes Networking: How Pods Talk to Services

The Kubernetes Networking Model

Kubernetes networking follows a deceptively simple set of rules. First, every pod gets its own unique IP address -- no manual assignment, no port conflicts. Second, any pod can communicate with any other pod in the cluster using that IP address directly, without NAT. Third, agents on a node (like kubelet) can communicate with all pods on that node. These three rules create a flat network where every pod is a first-class citizen.

This flat network model is implemented by Container Network Interface (CNI) plugins -- software that creates the actual network plumbing. Popular CNI plugins include Calico (which uses BGP routing for high performance), Flannel (which uses simple VXLAN overlays), Cilium (which uses eBPF for advanced security and observability), and Weave Net (which creates a mesh overlay). Each plugin implements the same model differently, with tradeoffs in performance, features, and complexity.

But pod IPs are ephemeral. When a pod restarts, it gets a new IP address. If you have three replicas of your web server and one crashes, the replacement pod will have a different IP. This is where Services come in -- they provide a stable virtual IP (ClusterIP) that automatically routes traffic to whatever pods are currently running, regardless of their individual IPs.

Interactive: Service Type Comparison

Click each service type below to see how the traffic path changes for external and internal access patterns.

How kube-proxy Routes Traffic

Pod-to-Pod Communication

In Kubernetes, pods communicate directly using IP addresses, without NAT. If Pod A at 10.244.1.5 wants to talk to Pod B at 10.244.2.8, the packet goes directly from A to B. This works even when the pods are on different nodes. The CNI plugin is responsible for making this work -- it sets up routes, tunnel overlays, or BGP peering so that every node knows how to reach every pod subnet.

This flat networking model is fundamentally different from Docker's default bridge networking. In Docker, containers on different hosts cannot communicate without port mapping or overlay networks. Kubernetes mandates that all pods can reach each other, and delegates the implementation to the CNI plugin. This simplifies application design -- services can assume direct reachability to any pod, just like processes on a traditional server can assume reachability to any other process.

Network Policies

By default, Kubernetes allows all pod-to-pod traffic. This is convenient for development but dangerous in production. Network Policies let you define firewall rules at the pod level. You can specify that only pods with a specific label (like "role: frontend") can connect to pods with another label (like "role: api"), and only on specific ports. Network Policies are implemented by the CNI plugin -- Calico and Cilium support them fully, while Flannel does not. Without a CNI plugin that enforces Network Policies, the policy resources are ignored by the cluster.

Ingress: HTTP Routing from Outside

Service Mesh

For complex microservice architectures, a service mesh like Istio, Linkerd, or Consul Connect adds a sidecar proxy (typically Envoy) to every pod. This sidecar intercepts all traffic and provides mutual TLS encryption, fine-grained traffic management (canary deployments, circuit breaking, retries), and detailed observability (request latency, error rates, distributed tracing) -- all without modifying application code. The mesh control plane manages configuration across all sidecars centrally.

Service meshes add complexity and resource overhead (each sidecar consumes CPU and memory), so they are typically justified only for large deployments with many services. For smaller clusters, Kubernetes' built-in Service and Network Policy mechanisms are usually sufficient. Cilium's eBPF-based approach offers many mesh-like features without sidecars, representing a newer approach that reduces overhead.