kube-proxy: The Plumber for Kubernetes Services

WHY IT EXISTS: Kubernetes pods are ephemeral, getting new IPs when they restart. To provide a reliable connection point, Kubernetes uses Services, which have stable virtual IPs. kube-proxy is the component that makes this abstraction a reality, ensuring traffic sent to a Service IP reaches a healthy backing pod, no matter how often pods are created or destroyed.

THE MENTAL MODEL: Think of kube-proxy as a traffic director on every node's local highway system. The control plane sends it a list of destinations (pods) for a given address (Service IP). The director then sets up road signs (iptables or IPVS rules) to guide traffic to one of the available destinations. It doesn't inspect the cargo (L7 data), just the destination address.

HOW IT WORKS: kube-proxy runs as a daemon on each node. It watches the Kubernetes API server for updates to Service and EndpointSlice objects. When a change occurs, like a pod being added to a service, kube-proxy modifies the node's networking rules to reflect the new state. It has two primary modes: iptables, which is widely compatible but can be slow at scale, and IPVS (IP Virtual Server), which uses a more efficient hash-based lookup and is better for large clusters.

WHEN TO USE IT: You don't "use" it directly; it's a fundamental component of any Kubernetes cluster. Every time you create a Service of type ClusterIP, NodePort, or LoadBalancer, you are relying on kube-proxy to implement it across the cluster by programming the underlying Linux networking stack.

WHEN NOT TO USE IT: You can't really disable it if you want to use standard Kubernetes Services. However, some CNI plugins and service meshes (like Cilium or Calico in eBPF mode) can bypass kube-proxy entirely. They implement service routing more efficiently, directly in the kernel, which can be a performance advantage in very large or high-throughput clusters.

ONE CANONICAL EXAMPLE: You create a Service named 'my-api' with a ClusterIP of 10.96.10.10 that selects three pods. On every node, kube-proxy adds rules. When a pod on Node A tries to connect to 10.96.10.10, the kernel, guided by kube-proxy's rules, intercepts the packet. It then selects one of the three healthy pod IPs as the real destination, changes the packet's destination IP (DNAT), and forwards it, all transparently to the application.