2 min lesson
Health and safe rollouts
For each case in "Health and safe rollouts", name the signal and the response you would use.
Step 1 of 2
Health and safe rolloutsprobes and disruption budgets
"Is this process wedged?"
Fail → kubelet restarts the container.
Set too aggressive and healthy-but-slow pods get killed in a loop.
"Can it take traffic right now?"
Fail → pulled from Service endpoints, not restarted.
Gates rollouts so traffic only hits warmed pods.
"Has slow init finished?"
Holds liveness off until the app is up.
Stops liveness from killing apps with long cold starts.
A PodDisruptionBudget caps how many pods of a workload can be voluntarily down at once, so a node drain or cluster upgrade can't take a service below its minimum. Pair PDBs with a RollingUpdate strategy and correct readiness probes and you get zero-downtime deploys; skip them and a routine node rotation becomes an outage.
Stateful workloads are the exception on this platform, run via StatefulSets with stable network identities and per-pod PersistentVolumeClaims (EBS) that follow the pod's ordinal. They don't reschedule across AZs freely, because an EBS volume is AZ-bound, so storage topology becomes part of your HA design.
When a pod is described as "stuck," diagnose out loud by state: Pending means the scheduler can't place it (resources, taints or IP exhaustion); CrashLoopBackOff means it starts then dies (app error or a too-aggressive liveness probe); OOMKilled means it blew the memory limit. Naming the state and its likely causes shows you've actually operated clusters.
Learn more
Optional practice
Practice: Health and safe rollouts
QA deployment's pods stay Pending during a scale-up even though node CPU and memory dashboards show plenty of headroom. The events mention sandbox creation and IP allocation. What's happening?