Study notes · 12% of the exam

Rollouts, Deployment Strategies and Autoscaling

Know how Deployments roll out and roll back, how traffic-shifting patterns (blue/green, canary) work on top of them, and how the HPA, VPA and node autoscalers decide when to add or remove capacity.

Key points

1
Only changes to .spec.template create a new revision; scaling never does. kubectl rollout undo re-applies an older template as a new revision number.
2
Rolling updates convert percentages with maxSurge rounded up and maxUnavailable rounded down (defaults 25%/25%); both can't be 0. minReadySeconds delays when new Pods count as available.
3
A stalled rollout is marked ProgressDeadlineExceeded after progressDeadlineSeconds (600 by default) but is never rolled back automatically.
4
HPA: desired = ceil(current × currentMetric / target), skipped inside a 0.1 tolerance; utilisation is relative to requests; with several metrics the largest proposal wins.
5
HPA behaviour defaults: scale-up has no stabilization window (rate 100% or 4 Pods per 15 s, whichever is larger); scale-down uses a 300 s window that takes the highest recent recommendation.
6
PodDisruptionBudgets only govern evictions (drains, Cluster Autoscaler); rollouts, HPA scale-down and node crashes ignore them.
7
Cluster Autoscaler adds nodes for unschedulable Pods, not for busy nodes; Karpenter provisions right-sized nodes without node groups; KEDA handles 0↔1 and an HPA it manages handles 1↔N.

Common traps

Keeping replicas: in a GitOps-managed manifest makes every sync fight the HPA; remove the field.
A CPU-utilisation HPA does nothing if any container (including sidecars) lacks a CPU request.
Running VPA and HPA on the same CPU/memory metric makes them fight; use one per metric.

Read the source

Test yourself on Rollouts, Deployment Strategies and Autoscaling

Ten questions, with the answer and explanation after each one.