1- Update the Propertunel scaling configuration of the Deployment web1 in the ckad00015 namespace setting maxSurge to 2 and maxUnavailable to 59 2- Update the web1 Deployment to use version tag…

Question

Explanation

CKAD Simulation: Rolling Update Strategy, Image Update, and Rollback

Overall Goal

This question tests your ability to manage a Kubernetes Deployment lifecycle: configure how updates roll out safely, trigger an update, and recover from a bad update using rollback. These are core production operations.

Note: "Propertunel" appears to be a typo/OCR artifact for RollingUpdate strategy. maxUnavailable: 59 may mean 5 or 5% - take it at face value in the exam.

Step 1 - Configure the RollingUpdate Strategy

kubectl edit deployment web1 -n ckad00015

In the spec, set:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 59

Or with kubectl patch:

kubectl patch deployment web1 -n ckad00015 \
  --type=merge \
  -p '{"spec":{"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxSurge":2,"maxUnavailable":59}}}}'

Why this step is necessary:

• maxSurge: 2 - how many extra Pods above the desired count can exist during a rollout. More surge = faster rollout.
• maxUnavailable: 59 - how many Pods can be unavailable at once during the update.
• This must be set before the image update so the new rollout uses these exact parameters. If done after, the image update already triggered a rollout under the old strategy.

Step 2 - Update the Container Image

kubectl set image deployment/web1 nginx=lfconf/nginx:1.13.7 -n ckad00015

If you don't know the exact container name, first run:

kubectl get deployment web1 -n ckad00015 -o jsonpath='{.spec.template.spec.containers[*].name}'

Why this step is necessary:

• Changing the image tag triggers a new rollout revision. Kubernetes records the current state as revision N and creates revision N+1 with the new image.
• This revision history is what makes Step 3 possible - without a prior revision recorded, there is nothing to roll back to.

What goes wrong if skipped: Step 3 would have no effect (no new revision was created), or would roll back to an unintended earlier state.

Step 3 - Rollback to Previous Version

kubectl rollout undo deployment/web1 -n ckad00015

Verify the rollback:

kubectl rollout status deployment/web1 -n ckad00015
kubectl rollout history deployment/web1 -n ckad00015

Why this step is necessary:

• rollout undo reverts to the previous revision (the one before Step 2). Kubernetes re-applies the old Pod template, which includes the old image tag.
• This simulates recovering from a bad deployment - a real-world scenario where 1.13.7 caused issues.

What goes wrong if done out of order: If you undo before the image update (Step 2), you roll back to some even older state, not the pre-1.13.7 state the question intends.

Key Concept Summary

Memory Tip

Think of the order as Configure → Deploy → Recover:

"Set the rules before you make the change, so you can undo it after."

The revision history only exists because you made the change in Step 2 - rollback always needs a prior revision to target.

No community discussion yet for this question.