Service Load Calculator
Estimate per-pod load distribution behind a Kubernetes Service under a given traffic rate.
About Service Load Calculator
A Kubernetes Service load-balances only across endpoints currently marked Ready — pods that are Pending, CrashLooping, or failing readiness probes are silently excluded from the rotation. This means the same total traffic gets divided across fewer pods whenever readiness drops, spiking real per-pod load well above what capacity planning based on desired replica count would suggest.
Formula
perPodRPS = totalRPS / readyEndpoints
- T
- Total Service RPS
- E_r
- Number of currently ready endpoints
- r_p
- Actual per-pod requests per second
Worked example
With the default values below, Service Load Calculator returns Per-Pod RPS (Actual Load) of 250.0. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Total Service RPSaccepts 0–10,000,000 req/s
- 3,000 req/s
- Desired Replicasaccepts 1–1,000,000 pods
- 15 pods
- Currently Ready Endpointsaccepts 0–1,000,000 endpoints
- 12 endpoints
- Per-Pod Safe RPS Thresholdaccepts 0.1–1,000,000 req/s
- 220 req/s
Results
- Per-Pod RPS (Actual Load)
- 250.0 req/s
- Overload Risk
- true
- Endpoints Not Ready
- 3 endpoints
- Endpoint Readiness
- 80.0%
Step by step
- 1Per-pod RPS = total RPS ÷ ready endpoints= 250.0 req/s
- 2Endpoints not ready= 3
- 3Overload factor vs safe threshold= 1.14×
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges 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 would ready endpoints be lower than desired replicas?
Common causes: pods still starting up (not yet passing readiness probes), pods restarting after a crash, nodes under pressure evicting pods, or a rolling update temporarily reducing the ready pool below the deployment's full replica count.
How does this interact with HPA?
HPA typically scales based on average CPU/memory utilization or custom metrics across pods, not endpoint readiness directly — so a drop in ready endpoints can spike per-pod load and trigger HPA scale-up, but there's a lag while new pods start and become ready themselves.
What's a safe per-pod RPS threshold?
Load test each pod in isolation to find the RPS at which p99 latency degrades unacceptably, then set your safe threshold meaningfully below that point (e.g. 70-80%) to leave margin for the imbalance this calculator highlights.