Why all your gRPC traffic hits one Kubernetes pod (and 3 ways to fix it)

You scale a gRPC service from 3 pods to 6. One pod sits at 90% CPU, the other five do almost nothing. Kubernetes isn't broken: a Service balances connections, not requests, and gRPC sends everything over one long-lived HTTP/2 connection. In this video: what a ClusterIP Service really does, why HTTP/2 pins each client to one pod, how to confirm it with ss, and three fixes: a headless Service with client-side round robin, an HTTP/2-aware proxy or service mesh (Envoy, Linkerd, Istio), and MaxConnectionAge on the server. Checked against the Kubernetes Service docs, the gRPC load balancing and keepalive docs, and the Linkerd docs (October 2026). Chapters 0:00 The symptom 0:29 The setup 0:59 What a Service really is 1:31 Why gRPC breaks it 2:23 How to confirm it 2:55 Fix 1: client-side balancing 3:26 Fix 2: a proxy that speaks HTTP/2 3:49 Fix 3: let connections expire 4:11 At the edge, and beyond gRPC 4:38 The short answer Tags: kubernetes, grpc, http2, load balancing, kubernetes service, service mesh, linkerd, envoy, istio, devops, sre, headless service