Skip to main content
< All Topics

Kube-Proxy

Posted
Updated
Author -Rajkumar Aute
Views4

Role: The Network Proxy & Load Balancer

Imagine the Kubernetes Cluster is a giant city.

  • Pods are houses where people (applications) live.
  • Services are the “Business Address” or “Phone Number” listed in the directory.
  • Packets are the cars trying to reach those addresses.

The Kube-Proxy is the Traffic Cop standing at every intersection (Node).

  • When a car (packet) comes looking for a specific Business Address (Service IP), the Traffic Cop checks his rulebook.
  • He says, “Ah, you want to go to the ‘Login Service’? Okay, I will redirect you to House #42 (Pod IP).”
  • He doesn’t drive the car; he just changes the destination on the GPS so the car goes to the right place.
  • If House #42 burns down (Pod dies), the Traffic Cop quickly updates his rulebook to send cars to House #43 instead.

Without Kube-Proxy, your Service (ClusterIP) is just a fake IP address that goes nowhere. Kube-Proxy makes that fake IP actually route to a real Pod.

  1. Kube-Proxy runs on every node in the cluster (it’s a DaemonSet(default) we can use as Linux service as well).
  2. It translates Service IPs (Virtual IPs) into Pod IPs (Real Endpoints).
  3. It is responsible for East-West traffic (communication inside the cluster).
  4. It manipulates the Linux Kernel’s networking rules (using iptables or IPVS).
  5. It implements a basic Load Balancer for Services (TCP/UDP/SCTP).
  6. It does not handle Ingress traffic (traffic coming from outside the cluster) directly; that’s for Ingress Controllers (though they rely on Kube-Proxy eventually).
  • Process Name: kube-proxy.
  • Core Job: Watch API Server -> Update Kernel Networking Rules.
  • Default Mode: iptables (most common).
  • High Performance Mode: IPVS (IP Virtual Server).
  • Modern Replacement: eBPF (tools like Cilium replace Kube-Proxy entirely).

Kube-Proxy solves the “Service Discovery” problem. When you create a Service in Kubernetes, you get a ClusterIP (e.g., 10.96.0.10). This IP does not exist on any physical network interface. It is virtual.

The Performance Bottleneck (O(n) vs O(1)):

  • Iptables: If you have 5,000 services, the kernel has to read through thousands of rules sequentially for every packet. CPU usage spikes, and latency increases. This is O(n).
  • IPVS: Uses a hash table. Looking up a rule takes the same time whether you have 5 services or 5,000. This is O(1).
  • Recommendation: Always use IPVS for production clusters with high traffic.

The eBPF Revolution (Cilium): Modern “Cloud Native” architectures often remove Kube-Proxy entirely.

  • Tools like Cilium use eBPF (Extended Berkeley Packet Filter).
  • Instead of writing slow iptables rules, they inject logic directly into the kernel code safely.
  • Benefit: Massive performance gain and better visibility (observability).
  • ipvsadm: Essential for debugging IPVS mode.
  • Kube-router: An alternative to Kube-Proxy that uses LVS/IPVS exclusively.
Key Characteristics
  • Distributed: No central point of failure (runs on every node).
  • Kernel-Native: Relies heavily on Netfilter (Linux networking stack).
  • Stateless: It just reads config from API server and writes to Kernel.
Use Case
  • Service Abstraction: Allows you to talk to “Database Service” without caring which specific pod is running the database.
  • Load Balancing: Distributing traffic across replicas.
 Benefits
  • Seamless Failover: If a pod dies, Kube-Proxy updates the rules, and traffic flows to the new pod automatically.
  • Simplicity: Developers just use a stable IP (ClusterIP) and don’t worry about networking complexity.
Common Issues, Problems, and Solutions
ProblemSymptomSolution
Conntrack FullPackets getting dropped, random timeoutsIncrease nf_conntrack_max sysctl settings on the node.
Service unreachableConnection refused on ClusterIPCheck if Kube-Proxy pod is running. Check iptables -L -n -t nat to see if rules exist.
Slow updatesNew pods take time to receive trafficThe API Server might be slow, or the node is under high load. Check Kube-Proxy logs.
Wrong ModePerformance is badCheck logs to see if it fell back to iptables because IPVS modules were missing.

–

Contents
Scroll to Top