Rolling Update Strategy: maxSurge and maxUnavailable

Workloads / Guide 27 of 103 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 30 min

Sampled every few seconds, so the exact rows depend on timing. The shapes are what to learn.

This guide includes

Use this when you need to know how much capacity a rollout adds or removes while it runs. This matters because maxSurge and maxUnavailable default to 25% each without anyone setting them, and those two numbers decide whether users notice a deploy at all.

• reading back the RollingUpdate strategy and the 25% defaults nobody chose
• polling a Deployment through a rollout and watching READY exceed the replica count
• seeing maxSurge and maxUnavailable in the live counts rather than in the manifest
• switching to the Recreate strategy and watching availability hit zero

Before you start

• The Deployments guide, for rollout status, undo and revision history.
• The ReplicaSets guide, since a rolling update is two ReplicaSets existing at once.
• A scratch namespace with a Deployment to update.

1. 1

   The defaults, and why 25% is a decision

2. 2

   maxSurge, visible as READY exceeding the replica count

3. 3

   Recreate, and availability hitting zero

Official sources

• Deployments
• Rolling update strategy
• Recreate strategy
• Min ready seconds
• Progress deadline seconds