Networking & the CNI

Every Pod gets an IP address the moment it's scheduled, and every other Pod on any node can reach it directly, with nothing translating the address in between. Kubernetes itself does none of the work that makes that true — it publishes a small, non-negotiable network model and a plugin contract called the CNI (Container Network Interface), then delegates the actual wiring to whichever plugin you install. Once a Pod has an IP, a second and entirely separate problem starts: giving a shifting set of Pods behind a Service one stable virtual address, which is kube-proxy's job, done by programming the node's own packet-forwarding rules — classically iptables, increasingly IPVS, and on modern clusters sometimes skipped entirely in favor of eBPF. Services & Networking covers what the CKA blueprint expects you to operate; this page goes underneath it, into how the CNI spec actually works, exactly how kube-proxy's two dataplanes differ, and how to choose between Flannel, Calico, and Cilium for a real reason instead of a coin flip.

The flat network model: IP-per-Pod, no NAT

☺ Like you're 10: Kubernetes doesn't pave the roads itself — it just insists that every house gets its own address and any house can reach any other, then leaves the actual paving to someone else.

Kubernetes is famous for being unopinionated about networking, but it isn't silent about it. It publishes a small set of hard requirements known as the Kubernetes network model, and any implementation that satisfies them counts as valid, regardless of how it's built underneath. The three rules: every Pod gets a unique, cluster-wide routable IP address; every Pod can reach every other Pod on any node without NAT; and a node's own agents (kubelet, system daemons) can reach every Pod scheduled to that node. The shorthand for all three together is IP-per-Pod on a flat network, and the "no NAT" clause is the quiet load-bearing part: when Pod A talks to Pod B, B sees the connection arriving from A's real address, not from some translated stand-in. That single guarantee is what makes a Pod IP a genuinely usable identity — for logs, for security policy, for a service mesh's mTLS identity — instead of a leaky abstraction you have to work around.

A Pod is not one container sharing a hostname with its neighbors; it's a small group of containers sharing one network namespace. When kubelet starts a Pod, the container runtime first creates a nearly-empty sandbox that owns the Pod's network namespace and its IP, then every application container in the Pod joins that same namespace. That's why containers inside one Pod talk to each other over localhost and share one port space — and it's exactly why a sidecar proxy in a service mesh can transparently intercept a Pod's traffic without any cooperation from the application container: it's sitting inside the identical namespace.

The CNI spec: a contract, not an implementation

☺ Like you're 10: CNI isn't the road itself — it's the one-page work order every road crew has to accept: here's the house, here's the street, ADD a driveway, DEL it if the house gets torn down.

The Container Network Interface is deliberately tiny: a plugin contract between the container runtime and whatever networking implementation you've installed, governed by the containernetworking project and tightly coupled to Kubernetes' own SIG Network. When kubelet asks the runtime (containerd or CRI-O) to bring up a Pod's sandbox, the runtime invokes the CNI plugin configured on that node with a verb — ADD to wire the Pod up, DEL to tear it down, CHECK to verify an existing wiring is still correct — passing the Pod's network namespace and a JSON config over stdin and reading a JSON result back over stdout. Everything about how the flat model actually gets built underneath that one JSON exchange is left entirely to the plugin.

Concretely, on ADD a CNI plugin: allocates a free IP for the Pod from that node's slice of the cluster's Pod CIDR, using its own IPAM (IP Address Management) module; creates a veth pair — a connected pair of virtual Ethernet interfaces — moving one end into the Pod's network namespace as eth0 and leaving the other end in the node's root namespace; programs routes on the node so packets addressed to that Pod IP land in the right namespace; and records the allocation so the same IP isn't handed out twice. DEL reverses every one of those steps and returns the IP to the pool. Real clusters usually chain more than one plugin for a single Pod — a main network plugin (Calico, Cilium, Flannel) plus a small helper like portmap for hostPort support — which is exactly what the plugins array in a CNI config file represents.

// /etc/cni/net.d/10-calico.conflist — plugins run in order for every ADD
{
  "cniVersion": "1.0.0",
  "name": "k8s-pod-network",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "datastore_type": "kubernetes",
      "mtu": 1440,
      "ipam": { "type": "calico-ipam" },
      "policy": { "type": "k8s" },
      "kubernetes": { "kubeconfig": "/etc/cni/net.d/calico-kubeconfig" }
    },
    {
      "type": "portmap",
      "capabilities": { "portMappings": true }
    }
  ]
}

# Inside the Pod's own network namespace — this is the ADD result
kubectl exec checkout-7d4f9 -- ip addr show eth0
# 3: eth0@if42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440
#     inet 10.244.1.7/32 scope global eth0

# On the node, the OTHER end of that exact same veth pair (index 42 ↔ 3)
ip link show | grep '^42'
# 42: cali1a2b3c@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440

kube-proxy: turning a Service into real forwarding rules

☺ Like you're 10: Pods keep moving addresses; a Service is one phone number that never changes. kube-proxy is the operator who keeps updating, behind the scenes, exactly which desk that number currently rings.

A Pod IP is real and routable, but Pods are cattle — created, killed, and rescheduled constantly, and every new one gets a fresh address. A Service gives callers a stable virtual identity, a ClusterIP that never changes for the life of the object, sitting in front of a moving set of backing Pods selected by label. Nothing routes packets to a ClusterIP on its own — it isn't attached to any real network interface anywhere. Something has to intercept traffic addressed to it and rewrite the destination to a real, currently healthy Pod, and on most clusters that something is kube-proxy: a DaemonSet-managed process running on every node, watching kube-apiserver for Service and EndpointSlice objects and reprogramming that node's packet-forwarding rules every time either one changes.

kube-proxy has shipped three dataplane modes over Kubernetes' history. The original userspace mode actually proxied every connection through a kube-proxy process itself — correct, but slow enough that it's been effectively retired. iptables mode has been the long-standing default: for every Service, kube-proxy writes a chain of iptables rules that the kernel's netfilter evaluates in-line for every packet, no userspace hop required. IPVS mode, newer and built for scale, instead loads Services into the kernel's IP Virtual Server module as proper virtual servers backed by a hash table, giving O(1) lookup instead of iptables' linear rule scan. On a cluster running a handful of Services either mode is indistinguishable in practice; the difference becomes very real once a cluster carries thousands of them.

# iptables mode — the same Service, as real rules (abridged)
sudo iptables-save | grep -A2 checkout-svc
# -A KUBE-SERVICES -d 10.96.12.4/32 -p tcp --dport 80 -j KUBE-SVC-XPGD46QRK7WJZT7O
# -A KUBE-SVC-XPGD46QRK7WJZT7O -m statistic --mode random --probability 0.33333 \
#     -j KUBE-SEP-A1B2C3D4E5F6G7H8
# -A KUBE-SEP-A1B2C3D4E5F6G7H8 -p tcp -j DNAT --to-destination 10.244.1.7:8080

# IPVS mode — the same Service, one virtual server entry
sudo ipvsadm -Ln
# TCP  10.96.12.4:80 rr
#   -> 10.244.1.7:8080              Masq    1      0          0
#   -> 10.244.2.3:8080              Masq    1      0          0
#   -> 10.244.3.9:8080              Masq    1      0          0

Choosing a CNI plugin: Flannel, Calico, Cilium

☺ Like you're 10: Three different road crews, three different budgets — a bare road that just connects houses, a road crew that also checks IDs at every driveway, and a road crew with cameras on every corner.

Flannel is the minimalist: a simple VXLAN overlay that delivers exactly the flat network the model requires and essentially nothing else — no NetworkPolicy engine of its own. It's easy to reason about, easy to run on a laptop cluster, and a perfectly fine choice for learning or small non-production clusters, but it stops precisely where policy and deep observability begin. Calico pairs a fast datapath — native BGP routing by default, with overlay and eBPF modes available where the network won't cooperate with BGP — with a mature, well-tested NetworkPolicy engine, including extensions (global policy, ordered rules) beyond the core Kubernetes API. It's the common default for on-prem and hybrid clusters that need real policy enforcement without committing to eBPF everywhere. Cilium is the modern heavyweight: its entire datapath is built on eBPF, giving it identity-based policy instead of IP-based rules, optional L7-aware filtering (HTTP methods and paths, not just ports), a full kube-proxy-replacement mode, and Hubble for live flow observability — capability that costs real operational complexity to run and tune correctly.

Beyond kube-proxy: eBPF and kube-proxy-replacement mode

☺ Like you're 10: Instead of a phone operator manually forwarding every call, imagine wiring the phone company's own switchboard straight into the exchange — same result, one fewer hop, and it can see a lot more about the call along the way.

Both iptables and IPVS still work by intercepting packets after the kernel's normal networking stack has already done some of its own work. eBPF plugins take a different approach: small, verified programs are attached directly at points in the kernel's packet path — at the network interface (XDP) or the traffic-control layer (tc) — and can rewrite a packet's destination before it ever reaches the iptables or IPVS machinery at all. Cilium's and Calico's eBPF modes use exactly this to implement kube-proxy-replacement: kube-proxy stops running entirely, and Service load-balancing happens as one eBPF program instead of a chain of iptables rules or an IPVS lookup. The upside is fewer hops and richer context per packet — the program can see identities, not just IPs, which is what makes L7-aware policy and Hubble's flow visibility possible in the first place.

This page stops at "eBPF exists and here's why it changes the dataplane." A full treatment of eBPF program types, Cilium's identity model, and the Cilium-specific certification track lives outside this course's Kubestronaut scope, in the sibling Golden Astronaut course, alongside the rest of the wider CNCF certification ladder. If you want the platform-engineering view of this same stack — how a service mesh, an Ingress controller, and multi-cluster networking all sit on top of what this page covers — Platform Engineering's Networking & Service Connectivity goes further still.

The wiring on this page is what everything else in Kubernetes Architecture assumed already existed the moment it described kube-proxy and the container runtime. Layer a service mesh's sidecar proxies on top of this exact Pod network in Service Mesh Fundamentals, or head to Troubleshooting and A Troubleshooting Methodology for a structured way to work out which layer — CNI or kube-proxy — actually broke the next time "the Service is unreachable" turns out to mean something different than you first guessed.