What is kube-proxy in Kubernetes?
kube-proxy is the network component that runs on every node and makes Kubernetes Services actually work. When you create a Service to expose a set of pods, kube-proxy is what sets up the network rules that route traffic to the right pod, whether that traffic comes from inside the cluster or from outside it.
Without kube-proxy (or something doing its job), Services wouldn’t be able to send traffic to the pods behind them.
What kube-proxy actually does
- Implements Services: Watches for Service and Endpoint changes, and updates network rules on the node accordingly.
- Load balances traffic: When a Service has multiple pods behind it, kube-proxy spreads incoming connections across them.
- Handles traffic on every node: Runs as a process on each node, so any node can correctly route traffic to a pod, even if that pod lives on a different node.
kube-proxy modes
kube-proxy can run in a few different modes, depending on how it implements those network rules:
- iptables (most common): Uses the Linux kernel’s iptables to set up rules that route traffic to pods. This has been the default mode for years.
- IPVS: Built for larger clusters. Handles high volumes of Services more efficiently than iptables.
- userspace (legacy): An older, slower mode, rarely used in current clusters.
You can check which mode your cluster is using by looking at the kube-proxy config on any node.
kube-proxy iptables example
In iptables mode, kube-proxy writes rules that intercept traffic sent to a Service’s IP and redirect it to one of the backing pods. You can see these rules directly on a node:
# View kube-proxy’s iptables rules related to Services
sudo iptables -t nat -L KUBE-SERVICES -n# Check kube-proxy’s logs
kubectl logs kube-proxy-<pod-name> -n kube-systemYou won’t usually edit these rules by hand. kube-proxy manages and updates them automatically as Services and pods change.
kube-proxy vs CNI
These two get confused because both deal with networking, but they solve different problems:
| Component | What it handles |
| kube-proxy | Routes traffic to Services, load balancing across the pods behind them |
| CNI (Container Network Interface) | Gives each pod its own IP address and handles pod-to-pod networking across nodes |
You need both in a working cluster. CNI plugins (like Calico or Flannel) build the network pods talk over. kube-proxy handles the Service layer on top of that network.
Where it fits in the cluster
kube-proxy runs independently on each node, watching kube-apiserver for Service and Endpoint changes, and updating that node’s network rules in response. It doesn’t interact with etcd or kube-scheduler directly.
For implementation details, the kube-proxy source code is in the main Kubernetes GitHub repository.
