kube-proxy is a core component of the Kubernetes data plane that runs on every single worker node in the cluster. Its sole responsibility is to manage network routing rules on that specific node to implement the Kubernetes Service abstraction.

In Kubernetes, Pods are ephemeral; they are destroyed and recreated constantly, and their IP addresses change every time they do. To solve this, Kubernetes uses a Service (a stable, permanent IP address) to front-end a group of Pods. However, a Service IP is purely virtual—it does not belong to a real physical network card.

kube-proxy is the engine that converts that virtual Service IP into a real destination Pod IP.

1. How kube-proxy Works (The Control Loop)

kube-proxy does not actually sit in the middle of your network traffic directly intercepting packets (which would create a massive performance bottleneck). Instead, it acts as a controller that programs the host node’s underlying Linux kernel network stack.

1. The Watch: kube-proxy maintains a continuous connection to the cluster control plane (kube-apiserver), watching for the creation, modification, or deletion of Service and Endpoints (or EndpointSlice) objects.
2. The Translation: When a new Service is created (e.g., a frontend app trying to talk to a backend Service at 10.96.0.10), kube-proxy catches this event.
3. The Programming: It instantly writes low-level routing or firewall rules directly into the host node’s Linux kernel.
4. The Routing: When a container on that node tries to send a packet to the virtual Service IP 10.96.0.10, the Linux kernel intercepts the packet before it leaves the node, looks at the rules written by kube-proxy, changes the destination IP to a real, healthy backend Pod IP (e.g., 10.244.1.45), and routes it forward.

2. Operational Modes (Proxiers)

Depending on how your cluster is configured, kube-proxy can program the Linux kernel using one of three distinct proxy modes. Choosing the right one heavily impacts cluster scalability and networking performance.

A. IPTables Mode (The Longtime Default)

In this mode, kube-proxy writes sequential firewall rules using the Linux kernel’s native iptables utility.

• The Mechanics: For every Service and Endpoint added, a new iptables rule is appended. When a packet passes through, the kernel evaluates these rules sequentially from top to bottom.
• The Drawback: As a cluster scales to thousands of Services and Endpoints, the iptables list grows massive. Because the kernel must evaluate rules sequentially ($O(n)$ algorithmic complexity), packet processing slows down significantly, driving up node CPU utilization and network latency.

B. IPVS Mode (IP Virtual Server)

Designed specifically to solve the scalability bottlenecks of iptables. IPVS is a Netfilter hook built into the Linux kernel tailored for Layer-4 load balancing.

• The Mechanics: Instead of a long sequential list, IPVS organizes routing rules inside highly optimized hash tables.
• The Benefit: No matter if your cluster has 10 Services or 10,000 Services, the kernel can look up the destination Pod IP instantly ($O(1)$ constant-time complexity). This dramatically reduces CPU overhead and maintains high throughput in massive, enterprise-scale grids.

C. Userspace Mode (Legacy / Deprecated)

The oldest implementation. In this mode, kube-proxy actually sat directly in the data path. A packet would leave a container, travel up to the operating system’s user space to be processed by the kube-proxy application binary, and then travel back down to the kernel to be shipped out. Switching back and forth between kernel-space and user-space introduced severe performance penalties, making it entirely obsolete for modern workloads.

3. The Modern Alternative: Bypassing kube-proxy with eBPF

In cutting-edge Kubernetes platforms and advanced CNIs (like Cilium or modern configurations of OVNKubernetes in OpenShift), engineers are entirely disabling kube-proxy (kube-proxy-less mode).

Instead of relying on iptables or IPVS, these advanced network engines use eBPF (Extended Berkeley Packet Filter). eBPF allows the system to inject sandboxed, high-performance bytecode programs directly into network socket hooks inside the live Linux kernel.

When a container throws a packet onto its virtual network interface, the eBPF program intercepts it instantly at the software socket layer, executes the Service-to-Pod translation dynamically, and routes it. This completely sidesteps the overhead of traditional routing stacks, delivering ultra-low-latency networking and freeing up valuable host CPU cycles.