Why Rolling Updates Matter
When you change a Deployment's Pod template — for example bumping a container image tag — Kubernetes does not simply kill every old Pod and start new ones at once. Instead the default RollingUpdate strategy replaces Pods incrementally, keeping the application available throughout the change. This is the mechanism that lets teams ship multiple times a day without a maintenance window.
Cricket analogy: Like a team rotating in new players one at a time across a series rather than replacing the entire XI mid-match, RollingUpdate replaces Pods incrementally so the team stays fielded throughout the change.
The Deployment update strategy
A Deployment's spec.strategy field controls how old ReplicaSets are scaled down and new ones scaled up. The two supported types are RollingUpdate (the default) and Recreate, which terminates all old Pods before creating any new ones — useful only when the app cannot tolerate two versions running simultaneously. maxUnavailable and maxSurge can be absolute numbers or percentages (e.g. "25%"); lower maxUnavailable and higher maxSurge give a smoother, more conservative rollout at the cost of needing more spare cluster capacity.
Cricket analogy: Like a captain choosing between resting bowlers gradually across overs (RollingUpdate) versus benching the entire attack at once for a completely new bowling lineup (Recreate) when the two can't share the field.
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # at most 1 pod below desired count during update
maxSurge: 2 # at most 2 extra pods above desired count
template:
spec:
containers:
- name: web
image: registry.example.com/web:1.4.0Triggering, watching, and guarding a rollout
Updating the image with kubectl set image (or applying a changed manifest) creates a new ReplicaSet. The Deployment controller then scales the new ReplicaSet up and the old one down in lockstep, respecting the maxUnavailable/maxSurge bounds and each Pod's readiness probe. A rollout only proceeds past a batch once new Pods report Ready — if readinessProbe is missing or misconfigured, Kubernetes may consider a crash-looping Pod "available" and continue anyway. progressDeadlineSeconds marks a Deployment as Failed if it cannot make progress within the given time (default 600s), useful for CI/CD gates that watch kubectl rollout status and abort on failure.
Cricket analogy: Like a selector only promoting a debutant to the next match after they've proven fit and ready in the nets (readiness probe), otherwise a struggling player keeps getting fielded as if match-ready, risking the whole innings.
kubectl set image deployment/web web=registry.example.com/web:1.5.0 --record
kubectl rollout status deployment/web
# Waiting for deployment "web" rollout to finish: 3 out of 6 new replicas have been updated...
# deployment "web" successfully rolled outRollout history, rollback, and pausing
Kubernetes keeps a bounded history of ReplicaSets for each Deployment (spec.revisionHistoryLimit, default 10) so you can review and revert to earlier revisions. If a new version is unhealthy, kubectl rollout undo reverts the Deployment to the previous ReplicaSet (or a specific revision), applying the same rolling strategy in reverse so the rollback is itself zero-downtime. Pausing a rollout is a common technique for canary-style manual verification: pause after a few Pods have updated, check metrics/logs, then resume or undo.
Cricket analogy: Like a team keeping a bounded history of past playing XIs so selectors can revert to last week's winning lineup if a new one underperforms, kubectl rollout undo reverts a Deployment to a previous ReplicaSet.
kubectl rollout history deployment/web
# REVISION CHANGE-CAUSE
# 1 kubectl create --filename=web.yaml
# 2 kubectl set image deployment/web web=web:1.4.0
kubectl rollout undo deployment/web # back to previous revision
kubectl rollout undo deployment/web --to-revision=1
kubectl rollout pause deployment/web # halt an in-progress rollout
kubectl rollout resume deployment/web- RollingUpdate is the default Deployment strategy; Recreate kills all old Pods first.
- maxUnavailable and maxSurge bound how disruptive and how resource-hungry a rollout is.
- kubectl rollout status blocks until the rollout completes or the progress deadline is hit.
- kubectl rollout history lists revisions; kubectl rollout undo reverts to a prior one.
- Readiness probes gate how fast a rollout advances — missing probes can hide broken Pods.
- kubectl rollout pause/resume enables manual canary-style verification mid-rollout.
Practice what you learned
1. Which Deployment strategy field limits how many Pods can be unavailable during an update?
2. What command reverts a Deployment to its previous revision?
3. What happens if a Deployment's rollout exceeds progressDeadlineSeconds?
4. Which strategy type terminates all old Pods before creating new ones?
5. What determines whether the rollout controller considers a new Pod ready to continue the rollout?
Was this page helpful?
You May Also Like
Deployments and ReplicaSets
Learn how Deployments manage ReplicaSets to declaratively run, scale, and update stateless Pod replicas in Kubernetes.
Health Checks and Restart Policies
How Docker uses HEALTHCHECK instructions and restart policies to detect unhealthy containers and automatically recover from failures.
Blue-Green and Canary Deployments
How to safely release new application versions to production using zero-downtime blue-green switches and gradual canary rollouts.
Helm Package Manager
Understand how Helm charts template and version Kubernetes manifests, and how to install, upgrade, and roll back releases.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics