hello 1.0 runs on 4 replicas. The team wants 2.1, which reads its settings from /etc/hello/config.yaml.
About this scenario
hello 1.0 runs on 4 replicas. The team wants 2.1, which reads its settings from /etc/hello/config.yaml.
Update the image first and watch what a rolling update does with a version that crashes. Then roll back, add the file, and ship it again.
Objectives
- Roll out hello:2.1 and see it fail
- Roll back to the working version
- Run hello:2.1 on all 4 replicas, with its config mounted
- The Service still has 4 endpoints
What you'll practice
- A rolling update never takes more than maxUnavailable Pods away, so a crashing release leaves the old version serving.
kubectl rollout undoreapplies the previous ReplicaSet's Pod template. It's a new revision, not a time machine.- A ConfigMap mounted as a volume shows up as files, one per key.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.