What is kube-proxy's job on a Kubernetes node, and what still works if kube-proxy stops running there?

## What problem it solves A Service gets a stable virtual IP (the ClusterIP) that no network interface actually owns. Something has to make packets sent to that IP land on a real Pod. That something is the node's kernel, and kube-proxy is the agent that keeps the kernel's rules in sync with the API. The key mental model: **kube-proxy is a controller, not a proxy.** Despite the name, in the default modes it does not sit in the data path. It watches, it writes rules, and the kernel forwards at line rate. ## What it watches and writes kube-proxy watches two resources: **Services** (ClusterIP, ports, session affinity, externalTrafficPolicy) and **EndpointSlices** (the ready backend Pod IPs, maintained by the EndpointSlice controller based on readiness). On any change it recomputes and applies the node's rules. Modes: - **iptables** (default): chains that DNAT the ClusterIP and port to a randomly chosen backend, with connection tracking pinning a flow to its backend. Simple and robust; rule-set size grows with Services times endpoints, and full resyncs get expensive in very large clusters. - **IPVS**: uses the kernel's L4 load balancer with hash-table lookups, scaling better to thousands of Services and offering scheduling algorithms (round-robin, least-connection, hashing). Still uses some iptables rules for masquerading and filtering. - **nftables**: a newer backend replacing the iptables one on modern clusters, with better scaling characteristics. - **userspace**: the original mode, long deprecated and removed — describing it as current is a red flag. It also handles: - **NodePort**: making the allocated port on every node forward into the Service. - **externalTrafficPolicy**: `Cluster` load-balances to any backend but source-NATs (losing the client IP); `Local` forwards only to backends on the same node, preserving client IP and failing health checks on nodes with no backend. - **Session affinity** (`sessionAffinity: ClientIP`) and masquerading for traffic that must appear to come from the node. ## What kube-proxy does NOT do Being precise here separates candidates: - It does **not** assign Pod IPs or set up pod networking — that is the CNI plugin, invoked at sandbox creation. - It does **not** resolve DNS names; a Service's DNS name is CoreDNS's job. kube-proxy only handles the IP the DNS answer contains. - It does **not** run Ingress or do HTTP-aware routing — it is L4 only: no path-based routing, no retries, no TLS termination. - It does **not** decide readiness. Endpoints appear and disappear because the kubelet's probes drive Pod readiness and the EndpointSlice controller reflects it; kube-proxy just consumes the result. ## Failure behaviour Because the rules live in the kernel, kube-proxy going down is a **degradation, not an outage**: - Existing Services keep working against the endpoint set that was current when it died. - New Services and NodePorts get no rules on that node — connections fail. - Endpoint changes are not applied, so Pods that moved elsewhere are still targeted and a share of connections is DNATed to IPs that no longer serve. That produces the classic partial, intermittent symptom: "about a third of requests time out, but only from one node". - Conversely, newly created Pods never receive traffic even though they are Ready. Debugging means checking that the kube-proxy Pod is running on that node, reading its logs, and inspecting the rules with `iptables-save` or `ipvsadm -Ln`. Comparing `kubectl get endpointslices` against what the node has programmed settles whether the problem is control-plane (endpoints wrong) or node-level (rules stale). ## The eBPF alternative Modern CNIs increasingly replace kube-proxy: Cilium's kube-proxy replacement implements ClusterIP, NodePort and load-balancer handling in eBPF programs attached at the socket and driver level, skipping iptables and conntrack entirely. That yields lower latency and better scaling, at the cost of tighter coupling to the CNI and stricter kernel requirements. Knowing kube-proxy is replaceable — and why anyone would — is a good senior signal.