Lesson 7: Rolling updates and rollback
We already have a Deployment that keeps several copies (Pods) of the app alive. But what happens when you want to ship a new version — say, swap the image from nginx:1.27 to nginx:1.28? The naive way is to tear everything down and rebuild, but then the service drops for a few seconds and every user
It is like changing the wheels on a moving car without stopping it — you swap one wheel at a time, so the car keeps driving. And if the new wheel is bent, you just put the old one back.
- Rolling Update
- A way to update a Deployment with no downtime: Kubernetes replaces the old Pods with new ones gradually, a few at a time, so enough live copies always remain to serve requests.
- Rollback
- Returning the Deployment to the previous working revision when the new version turns out broken. The command kubectl rollout undo does this in one step.
- Rollout Status
- Live tracking of an update's progress: how many Pods are already updated out of the total, until a message confirms the rollout finished successfully.
- maxUnavailable
- How many Pods are allowed to be unavailable at once during a rolling update. A low value keeps more copies live at every moment but slows the update.
- maxSurge
- How many extra Pods beyond the target may be created temporarily during an update, so new copies are ready before old ones are removed.
- Revision
- A saved version of the Deployment. Each update creates a new revision, and Kubernetes remembers the previous ones so you can return to them.
