Controlling a Rollout with maxSurge and maxUnavailable

Application Deployment / Guide 16 of 44 / Intermediate

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

Both default to 25%, rounded - maxSurge up, maxUnavailable down. The asymmetry is deliberate and it means the defaults never take you to zero available on a Deployment of two or more replicas. A readiness probe with a 25-second delay is used here purely to make the rollout slow enough to observe; the arithmetic is the same at any speed.

This guide includes

Use this when a rollout has to be either cautious or fast and you need to say which. This matters because maxSurge and maxUnavailable are the only two knobs there are, and together they decide whether capacity ever dips below what you asked for.

• running two Deployments with opposite surge and unavailable settings
• rolling both at once and counting Pods immediately, so the difference is actually visible
• seeing that Recreate has neither setting, and does not pretend otherwise

Before you start

• A cluster and kubectl.
• The session creates namespace ckad-roll with Deployments careful (surge 1, unavailable 0), fast (surge 4, unavailable 4) and recreate, each with four or three replicas and a deliberately slow readiness probe.

1. 1

   Two Deployments, opposite settings

2. 2

   Roll them both and count

3. 3

   Recreate does not pretend

Official sources

• Deployment strategy
• Max Unavailable and Max Surge
• Deployment API