Your gRPC service gets busier, so you bump it from 2 replicas to 6. The Horizontal Pod Autoscaler says all 6 are running. But when you look at CPU, one pod is at 90% and the other five are almost idle. Latency doesn't improve at all.

Nothing is broken. This is how gRPC and Kubernetes Services behave together by default, and it catches a lot of teams the first time they move internal calls from REST to gRPC.

If you're still deciding between the two protocols, start with this gRPC vs REST comparison , which covers the trade-offs in streaming, payload size, browser support and debugging. This post assumes you've already picked gRPC and now need it to spread load properly.

Why one pod gets all the traffic

A normal Kubernetes ClusterIP Service balances at layer 4 . kube-proxy (using iptables or IPVS) picks a backend pod when a TCP connection is opened, and every byte on that connection goes to the same pod.

With REST over HTTP/1.1, that's fine.…