Calculate how long a rolling update will take given maxSurge and maxUnavailable.
A rolling update replaces pods in waves bounded by maxUnavailable and maxSurge: each wave can bring up to maxSurge new pods while taking down up to maxUnavailable old ones. Formula: waves = ceil(total_pods ÷ (maxUnavailable + maxSurge)), duration = waves × pod_startup_time. Increasing either maxSurge or maxUnavailable reduces the number of waves and therefore total rollout time, at the cost of more simultaneous capacity change.
duration = ceil(totalPods / (maxUnavailable + maxSurge)) × podStartupTime
Increasing maxSurge adds extra capacity during rollout without reducing available replicas — generally safer for latency-sensitive services. Increasing maxUnavailable speeds things up but temporarily reduces serving capacity, which is riskier under load.
Yes, as long as your pod startup time input includes the full time to pass readiness checks — that's the point at which Kubernetes considers a pod available and proceeds to the next wave.
PodDisruptionBudgets, node capacity constraints forcing pod pending states, or slow image pulls on cold nodes can all extend rollout time beyond the pure wave-based calculation.
The rollout can't make progress — Kubernetes requires at least one of maxUnavailable or maxSurge to be greater than zero for a RollingUpdate strategy.