Rolling Update Surge
The extra capacity a rolling deployment temporarily adds, and the unavailability it is permitted, which together decide whether the rollout is safe under load.
A rolling update is parameterised by two numbers usually left at their defaults: how many extra instances may exist above the desired count, and how many may be missing below it. Surge and unavailability together determine whether the service keeps its capacity during a deployment.
At low utilisation the defaults are harmless. At peak they are not: allowing twenty five percent unavailable during a rollout means running at seventy five percent capacity for the duration, which is exactly when a deployment tips a loaded service into shedding. The corresponding failure with surge is quieter — extra instances all establish connections at once, and the database connection limit, not the application, becomes the constraint.
The related trap is readiness. If the readiness probe returns healthy before the instance is genuinely warm — cache cold, JIT unoptimised, connection pool empty — the rollout proceeds to the next batch while the previous one is still incapable of serving at rate, and the user-visible effect is a latency spike on every deploy that nobody attributes to the rollout parameters.