Service Networking & kube-proxy

In one line

kube-proxy, running on every node, is what actually makes a Service's virtual IP work — intercepting traffic to it and forwarding to one of the real, healthy pods behind it.

0/4 · 0%

Think of it like this

A receptionist who redirects every call to a company's main phone number to whichever specific staff member is available right now — callers only ever dial the ONE published number; the receptionist (kube-proxy) is the one actually deciding, invisibly, exactly who picks up.

Key ideas

01
A Service's ClusterIP (Topic 1.2) is a VIRTUAL address — it doesn't belong to any real network interface anywhere, and nothing is actually 'listening' on it directly. KUBE-PROXY (Phase 0.2's worker-node component) is what makes traffic to that virtual address actually work, by programming rules directly into each node's own networking layer.
02
kube-proxy watches the API server for Services and their matching ENDPOINTS (the actual current IPs of healthy, ready pods behind each Service) and continuously updates each node's networking rules (historically via iptables, increasingly via the more efficient IPVS mode on larger clusters) so that any traffic sent to a Service's ClusterIP gets transparently rewritten to go to one specific pod's real IP instead.
03
This is why a Service's routing updates automatically the instant pods change — kube-proxy is continuously watching for exactly the kind of pod churn Phase 1 covered (scaling, healing, rolling updates) and rewrites its rules in near real time, with zero manual reconfiguration required anywhere.
04
An ENDPOINTS object (or the newer EndpointSlice) is the actual, concrete list of IPs currently backing a Service — kubectl get endpoints <service-name> shows you exactly which real pod IPs are currently receiving that Service's traffic, genuinely useful for confirming a Service is correctly finding its pods (or diagnosing why it isn't, if the list comes back empty).
05
An EMPTY endpoints list for a Service is one of the single most common real Kubernetes networking problems — it almost always means the Service's label SELECTOR doesn't actually match any pod's labels (a typo, a mismatched value), or that matching pods exist but aren't passing their READINESS probe yet, since only READY pods are ever added as endpoints.

Code & diagrams

KubeProxyRoutingdiagram

The virtual ClusterIP isn't real — kube-proxy rewrites traffic to it into traffic to a real pod, on every node.

Rendering diagram…

service-endpoints.shmarkdown

See kube-proxy's work directly — the endpoints list is the ground truth behind the Service.

# The Service's own virtual address
kubectl get svc my-app-svc

# The REAL pod IPs currently backing it — this is what kube-proxy routes to
kubectl get endpoints my-app-svc

# Diagnose an EMPTY endpoints list — the most common real Service problem
kubectl get endpoints my-app-svc
# <none>  <- something is wrong

# Check #1: does the selector actually match any pod's labels?
kubectl get svc my-app-svc -o jsonpath='{.spec.selector}'
kubectl get pods --show-labels

# Check #2: are matching pods actually passing their readiness probe?
kubectl get pods -l app=my-app
# a pod showing 0/1 READY will never appear in the Service's endpoints

Explain it without notes

Why does a Service's ClusterIP work correctly even though nothing is technically 'listening' on that address anywhere in the cluster?

A Service exists, its selector looks correct, but kubectl get endpoints shows nothing. What are the two most likely explanations?

Practice

On any Service you have access to, run kubectl get endpoints and confirm the listed IPs actually match your pods' real IPs from kubectl get pods -o wide.

Deliberately break a Service by editing its selector to not match any pod (change one label value), confirm the endpoints list goes empty, then fix it and confirm the endpoints reappear.

Trade-offs

↔
kube-proxy's default iptables mode is simple and works reliably for most clusters, but its rule-matching performance degrades as the NUMBER of Services grows very large (each Service adds more rules to evaluate) — larger clusters often switch to IPVS mode specifically for its more efficient, hash-based lookup at scale, a genuinely real operational tuning decision on clusters with many hundreds of Services.

Done when you can

I understand kube-proxy is what actually makes a Service's virtual ClusterIP work.
I can check a Service's endpoints and diagnose an empty list.
I know only pods matching the selector AND passing readiness end up as a Service's endpoints.