Service Load Calculator
Calculate per-pod RPS from total Service traffic divided by ready endpoints, and detect load imbalance from uneven endpoint readiness.
Inputs
Pods currently passing readiness probes and receiving traffic.
Per-Pod RPS (Actual Load)
250.0req/s
Overload Risk
true
Endpoints Not Ready
3endpoints
Endpoint Readiness
80.0%
Step by step
Per-pod RPS = total RPS ÷ ready endpoints
3000 ÷ 12
= 250.0 req/s
Endpoints not ready
15 − 12
= 3
Overload factor vs safe threshold
250.0 ÷ 220
= 1.14×
How it works
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
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.