2/875 min
Primitives
Deployments — Managing Pod Lifecycle
The right way to run applications: automatic restarts, rolling updates, and rollbacks.
beginner75 minRead → Lab → Quiz → Practice
🧠 Brain Warm-Up
🧠 Brain Warm-Up: If a node crashes and runs 10 bare Pods, they die. If the node runs 10 Pods managed by a Deployment, how does Kubernetes know to recreate them? What is the controller stack doing? Think about it.
Why Not Bare Pods?
Bare Pods have three critical weaknesses:
- No self-healing — if a node crashes or a pod is deleted, it is gone forever.
- No scaling — scaling would require creating each Pod manifest manually.
- No rolling updates — updating an image on bare pods requires deleting them first, causing downtime.
A Deployment solves all three.
The Deployment Stack
A Deployment does not create Pods directly. It manages ReplicaSets, which in turn manage the Pods. This hierarchy enables zero-downtime updates and instant rollbacks.
DEPLOYMENT ← you talk to this (manages versions)
└── REPLICASET ← manages replica counts (v2-7f8d)
└── POD (v2)
└── POD (v2)
└── POD (v2)The Deployment manages ReplicaSets. A new ReplicaSet is created on each update, enabling rollbacks to previous states.
Rolling Update Strategy
Kubernetes uses a RollingUpdate strategy to upgrade application versions. By default, it spawns new pods (maxSurge) and terminates old pods (maxUnavailable) sequentially.
BEFORE: [v1] [v1] [v1] maxSurge=1, maxUnavailable=0 (zero-downtime): Step 1: [v1][v1][v1][v2] ← surge v2 created Step 2: [v1][v1][v2] ← old v1 removed after v2 ready Step 3: [v1][v1][v2][v2] ← surge another v2 Step 4: [v1][v2][v2] ← old v1 removed Step 5: [v2][v2][v2] ← done ✓