Skip to content
beginner Phase 3 · Core Workloads

Deployments

Master Deployments for declarative updates, rolling updates, and rollback strategies.

1h 15m
0 problems
Topic Progress 0%

Rollouts via ReplicaSets

Rollouts via ReplicaSets

A Deployment never runs pods itself — it manages ReplicaSets. When the pod template changes, it creates a new ReplicaSet and shifts weight while honoring maxUnavailable and maxSurge:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

maxUnavailable: 0 keeps ready capacity at or above replicas; maxSurge: 1 allows exactly one extra pod during the swap. Progress depends on readiness — pods that never pass the readiness probe stall the rollout, and progressDeadlineSeconds (default 600) marks it failed.

Old ReplicaSets are retained at zero replicas as rollout history.

Controlling a Release

Controlling a Release

kubectl set image deploy/web app=registry.example.com/web:1.5.0
kubectl rollout status deploy/web
kubectl rollout pause deploy/web
kubectl rollout resume deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web --to-revision=3

Pausing freezes the Deployment's reactions so you can apply several edits — labels, env vars, images — before resuming once. Pair releases with a PodDisruptionBudget so voluntary evictions cannot empty the fleet mid-rollout.

rollout status exits non-zero on failure, which makes it the CI gate: never mark a deploy successful because the command returned without drama.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

Pitfall 1 — readiness that does not reflect serving ability. With maxUnavailable: 0, traffic safety rests entirely on the readiness probe; a trivial probe lets the rollout replace healthy pods with broken ones.

Pitfall 2 — changes that trigger no rollout. Only pod-template edits create a new ReplicaSet — editing Deployment labels or pointing at an image tag that did not move does nothing. revisionHistoryLimit (default 10) controls how many old revisions remain available to undo.

Interview-ready: compute surge and unavailable numbers for replicas=3, explain the pod-template-hash label separating ReplicaSets, and clarify rollback scope — undo swaps the pod template back; it never restores deleted Services or ConfigMaps.

Quiz

1. With replicas=3, maxUnavailable=0, maxSurge=1, how many pods may exist mid-rollout?

Question 1 options

2. What does kubectl rollout pause actually stop?

Question 2 options

3. A rollout hangs with old pods still serving. What should you check first?

Question 3 options

Flashcards

Question

maxSurge vs maxUnavailable

Answer

Surge caps extra pods during rollout; unavailable caps how many may be down — surge trades capacity for safety.

Question

rollout undo scope

Answer

Reverts the pod template to an earlier revision; dependent objects like Services are untouched.

Question

progressDeadlineSeconds

Answer

Default 600s — after this without progress the rollout is marked failed.

Question

PodDisruptionBudget role

Answer

Limits voluntary evictions so drains cannot take a Deployment below its healthy minimum mid-release.

Revision Notes

Key Takeaways

  • 1. Deployments manage ReplicaSets; template changes create new ones
  • 2. Readiness gates rollout progress more than any other setting
  • 3. rollout status is your verification gate — make it a CI step

Interview Tips

  • • Do the surge/unavailable math aloud for a small replica count
  • • Separate what undo restores (pod template) from what it does not (deleted resources)

Cheat Sheet

RollingUpdate bounded by maxUnavailable + maxSurge; readiness drives progress; pause batches edits; undo reverts template only; PDB protects voluntary evictions.

Continue Learning