Rollout History and Rollbacks
Kubernetes keeps a history of deployment revisions, allowing you to inspect past changes and roll back to any previous version. This is powered by ReplicaSets that are retained after each update.
Viewing Rollout History
List all revisions of a deployment:
kubectl rollout history deployment/web-app
Output shows revision numbers and change-cause annotations:
REVISION CHANGE-CAUSE
1 Initial deploy
2 Deploy v1.1 hotfix
3 Deploy v2.0 with new features
Inspecting a Specific Revision
View the full details of a past revision:
kubectl rollout history deployment/web-app --revision=2
This shows the pod template, including the image, environment variables, and resource limits that were active in that revision.
Rolling Back to the Previous Version
Undo the most recent rollout:
kubectl rollout undo deployment/web-app
This reverts to the immediately previous revision. The deployment controller creates a new revision that mirrors the old spec.
Rolling Back to a Specific Revision
Target a specific historical revision:
kubectl rollout undo deployment/web-app --to-revision=1
Use this when the previous version is also broken and you need to go further back.
Controlling Revision History Limits
By default, Kubernetes retains 10 old ReplicaSets. Adjust this with revisionHistoryLimit:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
revisionHistoryLimit: 5
template:
spec:
containers:
- name: web
image: web-app:2.0
Setting this to 0 disables history entirely and prevents rollbacks. Keep a reasonable number for your operational needs.
Monitoring Rollback Progress
After a rollback, monitor it just like any rollout:
kubectl rollout undo deployment/web-app --to-revision=1
kubectl rollout status deployment/web-app
Verify the correct image is running:
kubectl get deployment web-app -o jsonpath='{.spec.template.spec.containers[0].image}'
Rollbacks are fast because the old ReplicaSet already exists. Kubernetes simply scales it up and scales the current one down.