# Launch Lab: Perform a Rolling Update

Time to run a real rolling update against a real Deployment in your disposable Lab.

## What you're doing

A Deployment `app-v1` is running an older image version. Your task is to update it to a newer
version and confirm every replica ends up running the new image — exactly the mechanism from
the lesson and demonstration, on a real cluster this time.

## Before you start

Recall the demonstration: `kubectl rollout status` is your tool for watching progress rather
than repeatedly polling `kubectl get pods` yourself, and a stalled rollout with no obvious error
usually means a new Pod can't become Ready. If your update seems to hang, that's exactly the
diagnostic instinct from the knowledge check to apply.

## Your task in this Lab

Update the Deployment's image and verify all replicas are running the new version. Use
`kubectl rollout status` to confirm completion, not just a single `kubectl get pods` snapshot.

This Lab has its own in-context hints if you get stuck.

When you're done, return to this module for a short reflection on what "successfully rolled
out" actually guarantees — and doesn't.

## Instructor Notes

**Classroom flow:** A good moment to have students keep `kubectl get pods --watch` open in a
second terminal (if their Lab environment supports multiple panes) so they see the incremental
old-Pod/new-Pod transition happen live, reinforcing the demonstration.

**Approximate timing:** 10-15 minutes.

**Common mistake to watch for:** running `kubectl edit deployment` and forgetting to save/apply
correctly, or editing the wrong field (e.g. `replicas` instead of the container image) — a good
moment to reinforce reading the task description precisely rather than pattern-matching to a
similar-looking previous Lab.