Lab 7 - Rolling Updates¶
25 min Beginner
Problem¶
Your company's developers have just finished a new version of their Jedi-themed mobile game, and they're ready to update the backend running in your cluster. A Deployment named jedi-deployment manages the application replicas.
Update the container named jedi-ws to the new image quay.io/nginx/nginx-unprivileged:1.29 using a rolling update, and confirm the rollout succeeds. Then a teammate pushes a broken release. Roll it back.
Setup¶
Save this manifest to jedi-deployment.yaml and apply it:
jedi-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: jedi-deployment
labels:
app: jedi
spec:
replicas: 3
selector:
matchLabels:
app: jedi
template:
metadata:
labels:
app: jedi
spec:
containers:
- name: jedi-ws
image: quay.io/nginx/nginx-unprivileged:1.28
ports:
- containerPort: 8080
Tasks¶
- Update the
jedi-wscontainer toquay.io/nginx/nginx-unprivileged:1.29, and record why you changed it in thekubernetes.io/change-causeannotation. - Watch the rollout until it completes.
- View the rollout history. You should see two revisions.
- Deploy a broken release: update the image to
quay.io/nginx/nginx-unprivileged:9.99, a tag that doesn't exist. Check the rollout status and the pods. What happens to the old pods? - Roll back to the working version.
Hints¶
oc set imagechanges a container's image.oc annotatesets the change cause. The old--recordflag is deprecated.oc rollout status,oc rollout historyandoc rollout undomanage rollouts.- Watch the pods change in real time with
oc get pods -l app=jedi -w.
Verification¶
After the rollback, the Deployment runs version 1.29 with all 3 replicas available:
oc get deployment jedi-deployment -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
oc get deployment jedi-deployment
oc rollout history deployment/jedi-deployment