Determine the number of replicas needed to handle expected traffic and failover.
Sizing replicas purely on throughput (total RPS ÷ RPS per pod) leaves no slack for the moments when full capacity isn't available — during a rolling update a fraction of pods are always being replaced, and node failures can remove capacity unexpectedly. Applying an availability factor on top of the base replica count keeps the service within its SLO even when some replicas are temporarily unavailable.
replicas = ceil(ceil(totalRPS / rpsPerPod) × availabilityFactor)
1.2–1.3× is typical for standard rolling updates with maxUnavailable=25%. Multi-AZ deployments tolerating a full zone outage often need 1.33-1.5× (to survive losing 1 of 3 zones) or higher.
Load test a single pod (or extrapolate from production per-pod metrics) up to the point where p99 latency starts degrading — use that sustainable point, not the absolute breaking point.
Use this as your HPA's minReplicas floor for baseline traffic — HPA should still scale above this dynamically based on real-time metrics as load grows beyond the target RPS.