Calculate how evenly traffic spreads across Service endpoints as replicas scale.
In an ideal world a Service's traffic splits evenly across every endpoint, but kube-proxy's iptables/IPVS mode uses randomized selection rather than true round-robin, and long-lived connections (especially gRPC/HTTP2 with keep-alive) can pin disproportionate traffic to whichever endpoints were selected early. This calculator compares a pod's actual measured RPS against the theoretical even split to quantify how skewed real-world distribution has become.
skew% = ((busiestRPS - expectedRPS) / expectedRPS) × 100
Default kube-proxy modes (iptables, IPVS) make independent random selections per new connection rather than tracking global round-robin state — with enough connections this averages out, but with few long-lived connections (especially persistent gRPC/HTTP2), randomness alone can create lasting skew.
HTTP2 and gRPC multiplex many requests over one long-lived TCP connection — once that connection lands on an endpoint via load balancing, all its requests go to that same endpoint until the connection closes, unlike HTTP/1.1 where each new connection gets a fresh chance at balanced selection.
For gRPC/HTTP2 workloads, use client-side load balancing or a service mesh (e.g. Istio, Linkerd) that balances at the request level rather than the connection level; also consider setting max connection age to force periodic reconnection and rebalancing.