Spring / Spring gRPC Interview Questions
Why can gRPC load balancing be trickier in Kubernetes than for plain HTTP/1.1 services?
gRPC multiplexes many logical calls over a single long-lived HTTP/2 connection. A plain L4 (TCP) load balancer, or Kubernetes' default kube-proxy-based Service, balances at the connection level - so once a client establishes one long-lived HTTP/2 connection to a pod, all its calls stick to that one pod for the connection's lifetime, which can produce very uneven load distribution across replicas, especially with few, long-lived clients.
HTTP/1.1 services don't hit this as hard because they tend to open many short-lived connections, which a connection-level balancer distributes more evenly over time. The common fixes for gRPC are client-side load balancing against individual pod addresses (see the previous question), or an L7-aware proxy/mesh (Envoy, Linkerd) that balances at the HTTP/2 stream level rather than the TCP connection level.
More Related questions...