Endpoint Distribution Calculator
Calculate how evenly traffic spreads across Service endpoints as replicas scale.
About Endpoint Distribution Calculator
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.
Formula
skew% = ((busiestRPS - expectedRPS) / expectedRPS) × 100
- R_b
- Busiest endpoint's actual RPS
- R_e
- Expected per-endpoint RPS (totalRPS / endpointCount)
- S
- Skew percentage
Worked example
With the default values below, Endpoint Distribution Calculator returns Expected RPS per Endpoint of 500.0. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Total Trafficaccepts 0–10,000,000 req/s
- 4,000 req/s
- Endpoint Countaccepts 1–1,000,000 endpoints
- 8 endpoints
- Busiest Endpoint's Actual RPSaccepts 0–10,000,000 req/s
- 750 req/s
Results
- Expected RPS per Endpoint
- 500.0 req/s
- Busiest Endpoint Skew
- 50.0%
- Absolute Skew
- 250.0 req/s
- Significant Skew Detected
- true
Step by step
- 1Expected per-endpoint RPS = total ÷ endpoint count= 500.0 req/s
- 2Skew of busiest endpoint= 50.0%
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why is Kubernetes Service load balancing not perfectly even?
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.
How does connection reuse make skew worse?
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.
What fixes significant endpoint skew?
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.