← Back to recent posts
Kubernetes

How Kubernetes Builds Networking on Top of Containers

Kubernetes does not invent a new kind of network. It stacks names, rules, and a little software on the same Linux primitives you already use: network namespaces, veth pairs, iptables or nftables, and a bridge or a more serious CNI dataplane.

If you can explain that stack in an interview, you stop treating Pods and Services as magic. You can debug why a probe fails, why a Service IP does not answer, and why two Pods on different nodes cannot talk.

A Pod is a namespace with extra labels

A pause (or equivalent) container holds the network namespace. Every other container in the Pod shares it. That is why localhost works between a sidecar and the app, and why two containers in one Pod cannot both bind 8080.

  • Each Pod gets an IP from the CNI plugin, not from Docker’s default bridge.
  • kubelet and the runtime wire a veth into that namespace and hang the other end on the node’s CNI bridge or tunnel.
  • The cluster assumes Pods can reach other Pods by IP. If they cannot, the CNI or the VPC is wrong — not kubectl.

Services are stable names, not extra NICs

A ClusterIP is a virtual IP. Nothing in the Pod listens on it. kube-proxy (iptables, IPVS, or nftables) or a replacement like kube-proxy-less eBPF rewrites packets so they land on an Endpoint IP:port.

That is why deleting a Pod and creating a new one does not break clients that used the Service: the name stayed, the endpoints changed.

kubectl get endpoints -n prod api
kubectl get svc api -o wide
# If endpoints are empty, the selector does not match Pod labels.

CNI is the part you actually operate

AWS VPC CNI, Azure CNI, Calico, Cilium — they all answer the same question: how does this Pod IP exist on the node and in the cloud network? Prefix delegation, secondary IPs, overlay, and network policy all live here.

What to practice

  1. Draw one packet: curl from Pod A to Service B to Pod B on another node.
  2. Break a selector on purpose and watch Endpoints go empty.
  3. Read one NetworkPolicy and say who can still talk.

When that picture is boring, you are ready for Ingress, Gateway API, and service mesh. Those are extra hops on the same model.