5/845 min
Primitives
ReplicaSets — Self-Healing Guarantees
Understand how ReplicaSets maintain a desired pod count and why Deployments exist on top of them.
beginner45 minRead → Lab → Quiz → Practice
🧠 Brain Warm-Up
🧠 Brain Warm-Up: If a Deployment manages ReplicaSets and a ReplicaSet manages Pods, what happens when you delete a Pod that was created by a Deployment? Who recreates it — the Deployment or the ReplicaSet?
What is a ReplicaSet?
A ReplicaSet ensures a specified number of pod replicas are running at all times. If a pod crashes or is deleted, the ReplicaSet controller immediately creates a replacement.
ReplicaSet (desired: 3) ├── Pod nginx-abc12 ← Running ├── Pod nginx-def34 ← Running ← delete this └── Pod nginx-ghi56 ← Running After deletion: ├── Pod nginx-abc12 ← Running ├── Pod nginx-ghi56 ← Running └── Pod nginx-xyz99 ← Running (new — RS respawned it)
ReplicaSet vs Deployment
| Feature | ReplicaSet | Deployment |
|---|---|---|
| Maintains desired pod count | ✓ | ✓ (via RS) |
| Rolling updates | ✗ | ✓ |
| Rollback | ✗ | ✓ |
| Revision history | ✗ | ✓ |
You almost never create a ReplicaSet directly. Use a Deployment instead — it creates and manages the ReplicaSet for you, adding rollout and rollback on top.
Selector Must Match Template Labels
The ReplicaSet selector tells it which pods to count. If the selector does not match the pod template labels, the RS will keep creating pods forever (selector finds 0 matching pods).
selector:
matchLabels:
app: nginx # must match ↓
template:
metadata:
labels:
app: nginx # must match ↑