A rolling update replaces old application Pods gradually with Pods created from an updated Pod template. It is the default update strategy for Deployments. Unlike Recreate, which removes all old Pods before creating new ones, RollingUpdate keeps Pods available to serve requests during the replacement. Old and new application versions may run at the same time. section 15.2 section 15.2.2
In a Deployment, changing the Pod template starts the rollout. The Deployment controller scales down the old ReplicaSet and scales up a new one. A Service can then send traffic to ready Pods from either version until the replacement is complete. section 15.2.2 section 15.4
Set the pace in a Deployment's spec.strategy.rollingUpdate field:
- maxSurge limits how many Pods may exist above the desired replica count during the update. section 15.2.3
- maxUnavailable limits how many Pods may be unavailable relative to the desired replica count. With three desired replicas, maxSurge: 0 and maxUnavailable: 1 permit at most three Pods and require at least two available replicas. section 15.2.3
- minReadySeconds is separate from the strategy settings; it can slow progression by requiring a new Pod to remain ready before replacement continues. section 15.2.2 section 16.3.1
Update and watch a Deployment
Set spec.strategy.type to RollingUpdate, with maxSurge: 0 and maxUnavailable: 1, in a Deployment manifest. Change the Pod template's image from luksa/kiada:0.6 to luksa/kiada:0.7, then apply the manifest with kubectl apply. Run kubectl rollout status deploy kiada to watch the new replicas become available. During the rollout, requests can reach both versions; afterward, they reach the new version. section 15.2.2 section 15.2.3
To inspect a mixed-version Deployment, use kubectl rollout pause deployment kiada; continue with kubectl rollout resume deployment kiada. This is useful for checking a new Pod, but mixed versions can serve incompatible web resources to the same browser. If an update fails, kubectl rollout undo deployment kiada rolls Pods back using the configured strategy; a paused Deployment must be resumed before undo takes effect. section 15.2.4 section 15.2.6
RollingUpdate also exists for StatefulSets and DaemonSets, but its controls differ. A StatefulSet replaces one Pod at a time, from highest ordinal downward; its partition setting can stage an update or update just a canary Pod. A DaemonSet can use maxSurge and maxUnavailable, but running two instances of a node daemon during an update may prevent the new Pod from becoming ready. section 16.3 section 16.3.1 section 16.3.2 section 17.1.4
