During a rolling update, maxSurge limits how many extra pods may exist while old pods are replaced. Its limit is measured above the desired replica count, not above the number of pods currently running. Set it as a number or a percentage of the desired count. section 15.2.3
Replacing three replicas
Suppose a Deployment wants three replicas. With maxSurge: 0, the controller cannot add a fourth pod; if maxUnavailable is 1, it can remove one old pod before creating its replacement. With maxSurge: 1 and maxUnavailable: 0, it can temporarily have four pods while keeping at least three available. The two settings therefore control different limits: total pod count and available replicas. 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 maxSurge alongside maxUnavailable in the rollingUpdate configuration. section 15.2.3
A Deployment performs a rolling update by scaling down the old ReplicaSet and scaling up the new one. A DaemonSet also accepts maxSurge for RollingUpdate, but its default is 0: it normally stops the old daemon pod before starting its replacement. Setting a positive value can put two daemon instances on one node; a daemon that requires an exclusive lock may then fail to become ready. section 15.2.2 section 17.1.4
