Estimate per-pod load distribution behind a Kubernetes Service under a given traffic rate.
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.
perPodRPS = totalRPS / readyEndpoints
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.
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.
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.