# Demonstration: Watching a Rollout, Good and Bad ## A healthy rollout A Deployment `app-v1` running `nginx:1.24` at 3 replicas gets updated to `nginx:1.25`: ``` $ kubectl set image deployment/app-v1 nginx=nginx:1.25 deployment.apps/app-v1 image updated $ kubectl rollout status deployment/app-v1 Waiting for deployment "app-v1" rollout to finish: 1 out of 3 new replicas have been updated... Waiting for deployment "app-v1" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "app-v1" rollout to finish: 1 old replicas are pending termination... deployment "app-v1" successfully rolled out ``` `kubectl rollout status` blocks and reports exactly the incremental progress described in the lesson — this is your primary tool for watching (or scripting a wait on) a rollout, rather than repeatedly polling `kubectl get pods` yourself. ## Checking revision history ``` $ kubectl rollout history deployment/app-v1 REVISION CHANGE-CAUSE 1 2 ``` Revision 1 is the original ReplicaSet (now scaled to zero, still present); revision 2 is the current one. This history is exactly what `kubectl rollout undo` uses. ## A stalled rollout Now imagine the same update, but to a typo'd tag, `nginx:1.25-typo`, which doesn't exist: ``` $ kubectl rollout status deployment/app-v1 Waiting for deployment "app-v1" rollout to finish: 1 out of 3 new replicas have been updated... ``` ...and it just sits there. `kubectl get pods` shows why: ``` $ kubectl get pods NAME READY STATUS RESTARTS AGE app-v1-7d8f9c6b5d-abcde 1/1 Running 0 5m app-v1-7d8f9c6b5d-fghij 1/1 Running 0 5m app-v1-9c5b7d8f6b-klmno 0/1 ImagePullBackOff 0 30s ``` The new Pod can never become Ready because its image can't even be pulled — so the rollout correctly refuses to proceed further (removing more old Pods would reduce capacity for no benefit, since the replacement will never come up). Nothing is "broken" in the platform; the platform is behaving exactly correctly given bad input. **The fix here is `kubectl rollout undo`, not waiting longer** — this exact scenario is what `deployment-rollback`'s Lab, later in ROOT_, gives you real hands-on practice with. ## Instructor Notes **Demo script:** If time allows, run the healthy rollout live against a throwaway Deployment, then intentionally break the second one with a bad tag so students see `ImagePullBackOff` occur in real time rather than only in static text. **Approximate timing:** 8-10 minutes live; 5-7 minutes self-paced. **Common misconception to preempt:** students sometimes assume a stalled rollout will eventually time out and auto-rollback on its own. By default it will not — a Deployment has no automatic rollback trigger; a human (or automation) has to run `kubectl rollout undo` (or fix the underlying issue) explicitly. This is worth stating directly since it's a genuine and consequential production gotcha. **Optional extension:** ask what `kubectl rollout status --timeout=2m` would change about this scenario (answer: the command itself would exit with an error after 2 minutes instead of blocking forever — useful in CI/CD pipelines that need to fail a deploy step rather than hang).