Skip to main content
In this lesson we explain kube-proxy: the node-level agent that makes Kubernetes Services reachable across a cluster. Every Pod in a Kubernetes cluster can reach every other Pod because the cluster provides a pod network that spans all nodes. Network plugins implement this cross-node pod networking. However, Pod IPs are ephemeral — Pods can be rescheduled and receive new IPs — so relying on Pod IPs directly is brittle. To provide a stable network identity, Kubernetes uses Services. A Service (for example, a database Service named db) is assigned a stable ClusterIP (for example, 10.96.0.12) and forwards traffic to one or more backend Pods. But the Service object itself is virtual: it exists in the API and control plane memory and does not have network interfaces or processes. To make a Service IP reachable from every node, something on each node must install and maintain the forwarding rules for that Service IP — that something is kube-proxy. Why kube-proxy exists and what it does
  • Ensures traffic sent to a Service IP on any node is forwarded to one of the backend Pods.
  • Watches the Kubernetes API for Service and Endpoint (or EndpointSlice) changes.
  • Converts Service definitions into node-local networking rules and implements them using the selected datapath (iptables, IPVS, eBPF, or the legacy userspace proxy).
For example, kube-proxy can add iptables rules so that traffic to 10.96.0.12 is forwarded to a backend Pod IP such as 10.32.0.15. For Services with multiple backends, kube-proxy also implements the local load-balancing behavior so traffic is routed to one of the available Pods.
A Kubernetes diagram showing kube-proxy instances routing a service IP (service: db 10.96.0.12) to pod IPs (10.32.0.14 and 10.32.0.15) across the pod network.
The diagram above is a high-level overview of how kube-proxy routes a Service IP to backend Pod IPs across the pod network.
A Kubernetes Service is a logical construct. kube-proxy is the node-level agent that implements Service IP routing on each node (commonly via iptables, IPVS, or eBPF). The Service itself does not have network interfaces or processes.
How kube-proxy is deployed There are two common deployment patterns for kube-proxy:
  • Manual install: system administrators install the kube-proxy binary and run it as a system service.
  • DaemonSet (typical for kubeadm): kube-proxy runs as a Pod on every node, managed by a DaemonSet in the kube-system namespace.
Example: manual install (illustrative)
Example: kubeadm-managed clusters When using kubeadm, kube-proxy is deployed as a DaemonSet under kube-system. Useful inspection commands:
kube-proxy responsibilities (quick reference) kube-proxy proxy modes Configure the proxy mode via the kube-proxy configuration (for kubeadm-managed clusters, this is typically stored in the kube-proxy ConfigMap). Choosing the right datapath
  • iptables: good default choice; well supported.
  • IPVS: better for high connection rates and large scale.
  • eBPF: offers very efficient packet processing and advanced features but requires kernel and tooling support.
  • userspace: avoid unless you have a specific legacy constraint.
Troubleshooting and inspection tips
  • Check the kube-proxy pods and logs in kube-system.
  • Inspect the kube-proxy ConfigMap to verify the configured mode.
  • For iptables mode, inspect iptables-save output to see Service rules.
  • For IPVS mode, use ipvsadm -L -n on nodes to view virtual servers and destinations.
Further reading and references We will cover Services, kube-proxy internals, and pod networking in more detail in later lessons. This overview explains why kube-proxy is essential and how it enables cluster-wide Service routing. That concludes this lesson on kube-proxy.

Watch Video