Skip to content
Calcrivo

Endpoint Distribution Calculator

Calculate expected traffic per Service endpoint and the skew percentage when actual distribution deviates from a perfectly even split.

Inputs

req/s
endpoints
req/s

Actual measured RPS on the most heavily loaded endpoint.

Expected RPS per Endpoint

500.0req/s

Busiest Endpoint Skew

50.0%

Absolute Skew

250.0req/s

Significant Skew Detected

true

Step by step

  1. Expected per-endpoint RPS = total ÷ endpoint count

    4000 ÷ 8

    = 500.0 req/s

  2. Skew of busiest endpoint

    (750 − 500.0) ÷ 500.0

    = 50.0%

How it works

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

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.

You might also need