CKAD — Deployments Lab
Lab 1: Rolling Update and Rollback
Step 1: Create and Verify
# Create a Deployment
kubectl create deployment api --image=nginx:1.25 --replicas=3
# Verify
kubectl get deployment api
kubectl get pods -l app=api
Step 2: Perform a Rolling Update
# Update to nginx:1.26
kubectl set image deployment/api nginx=nginx:1.26
kubectl rollout status deployment/api
# Check the image
kubectl describe deployment api | grep Image
# Expected: nginx:1.26
Step 3: Push a Bad Image
# Update to a bad image
kubectl set image deployment/api nginx=nginx:nonexistent
kubectl rollout status deployment/api --timeout=30s
# This will timeout — the update is stuck
# Check what happened
kubectl get pods -l app=api
# You'll see Pods in ImagePullBackOff
Step 4: Roll Back
# Roll back
kubectl rollout undo deployment/api
# Verify it's back to nginx:1.26
kubectl describe deployment api | grep Image
kubectl get pods -l app=api
# All Pods should be Running
Cleanup
kubectl delete deployment api
Lab 2: Pause, Multi-Change, Resume
Step 1: Create and Pause
# Create a Deployment
kubectl create deployment frontend --image=nginx:1.25 --replicas=2
# Pause the rollout
kubectl rollout pause deployment/frontend
Step 2: Make Multiple Changes
# Make multiple changes — none trigger a rollout while paused
kubectl set image deployment/frontend nginx=nginx:1.27
kubectl set resources deployment/frontend -c nginx --limits=cpu=200m,memory=256Mi
# Nothing has changed yet — verify
kubectl get pods -l app=frontend -o jsonpath='{.items[0].spec.containers[0].image}'
# Still nginx:1.25
Step 3: Resume
# Resume — single rollout with both changes
kubectl rollout resume deployment/frontend
kubectl rollout status deployment/frontend
# Verify both changes applied
kubectl describe deployment frontend | grep -E "Image|Limits"
Cleanup
kubectl delete deployment frontend
Practice Questions
Q1: Create a Deployment named backend with image redis:7.0 and 4 replicas. Then scale it to 6.
Show Answer
```bash kubectl create deployment backend --image=redis:7.0 --replicas=4 kubectl scale deployment backend --replicas=6 kubectl get deployment backend # Expected: READY 6/6 ```Q2: Update the image of Deployment backend from redis:7.0 to redis:7.2. Then roll it back to the original version.
Show Answer
```bash # Update kubectl set image deployment/backend redis=redis:7.2 kubectl rollout status deployment/backend # Roll back kubectl rollout undo deployment/backend kubectl describe deployment backend | grep Image # Expected: redis:7.0 ```Q3: What is the difference between maxSurge and maxUnavailable in a rolling update strategy?
Show Answer
- **`maxSurge`** — The maximum number of Pods (or percentage) that can be created above the desired count during an update. A value of `1` with 3 replicas means up to 4 Pods can exist at any time. - **`maxUnavailable`** — The maximum number of Pods (or percentage) that can be unavailable during an update. A value of `1` with 3 replicas means at least 2 Pods must always be running. Both can be set as absolute numbers or percentages (e.g., `25%`).Q4: How do you roll back to revision 2 of a Deployment named api?
Show Answer
```bash kubectl rollout undo deployment/api --to-revision=2 kubectl rollout status deployment/api ``` To see available revisions first: ```bash kubectl rollout history deployment/api ```Q5: What happens when you set strategy.type: Recreate on a Deployment?
