maxUnavailable limits how many pods may be unavailable during a rolling update. Set it under rollingUpdate to control how quickly a Deployment replaces old pods while retaining available ones. Its value may be a number or a percentage of the desired replica count—not the number of pods that happen to exist during the update. section 15.2.3
Listing 15.4 Specifying parameters for the rollingUpdate strategy
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 0 #1
maxUnavailable: 1 #1
This Deployment strategy sets maxUnavailable to 1 and maxSurge to 0. The first limits unavailable pods; the second prevents extra pods above the desired replica count. section 15.2.3
Three desired replicas
With three desired replicas, maxUnavailable: 1 requires at least two available replicas. Even if five pods temporarily exist, the minimum is still two, not four. When maxSurge is also 0, the Deployment cannot exceed three pods: it deletes one old pod, then waits for its replacement to become available before deleting another. section 15.2.3
The two settings express different limits. With three desired replicas, maxSurge: 1 and maxUnavailable: 0 allow up to four pods but require at least three to remain available throughout the update. A Deployment performs this transition by scaling down the old ReplicaSet and scaling up the new one; its Service can continue forwarding traffic to available pods. section 15.2.3 section 15.2.2
DaemonSets also support maxUnavailable in their RollingUpdate strategy. Their shown default combination is maxSurge: 0 and maxUnavailable: 1: an existing daemon pod is stopped before its replacement is created. A DaemonSet can wait for the new pod to become ready and then wait an additional minReadySeconds before updating pods on other nodes. This matters for node agents that should not run two instances on one node. section 17.1.4
