Chapter 18: Load Balancing — Client-Side, Proxy, Look-Aside
gRPC Load Balancing Options
| Type | How | Pros | Cons |
|---|---|---|---|
| Proxy (L7) | Envoy/nginx terminates gRPC, forwards to backends | Simple client, centralized control | Extra hop, single point of failure |
| Client-side | Client knows all backends, picks one per RPC | No extra hop, no SPOF | Complex client, needs service discovery |
| Look-aside | Client asks external LB service for backend list | Centralized policy, simple client | Extra dependency |
Client-Side LB Policies
// Built-in policies:
// pick_first: use first healthy backend (default)
// round_robin: rotate across all backends
// Set via service config:
{
"loadBalancingConfig": [{"round_robin": {}}]
}Why L4 Load Balancers Don't Work Well with gRPC
gRPC uses long-lived HTTP/2 connections with multiplexing. An L4 LB assigns a connection to one backend — ALL RPCs on that connection go to the same backend. No per-RPC balancing. You need L7 (Envoy) or client-side LB.
💡 In Kubernetes
Kubernetes Services (ClusterIP) are L4 — they don't work well with gRPC. Use a service mesh (Istio/Linkerd) or headless Service + client-side LB for proper per-RPC load balancing.