Deployments abstract ReplicaSets to provide declarative rolling updates, rollback, and scaling. Understanding revision history, update strategies, and controller reconciliation is essential for production reliability.
Deployments abstract ReplicaSets to provide declarative rolling updates, rollback, and scaling. Understanding revision history, update strategies, and controller reconciliation is essential for production reliability.
Lesson outline
A Deployment is a higher-level abstraction that manages ReplicaSets.
When you create a Deployment, it creates a ReplicaSet. When you update a Deployment (change image, replicas, etc.), it creates a NEW ReplicaSet.
Pods are created and managed by ReplicaSets, not Deployments directly. Deployments manage the desired state and coordinate updates between ReplicaSets.
A ReplicaSet ensures that a specified number of Pods are running at all times.
If a Pod crashes, the ReplicaSet recreates it. If you scale the ReplicaSet, it creates or deletes Pods to match the desired count.
ReplicaSets are typically managed by Deployments, not created directly.
When you update a Deployment (new image), it doesn't immediately kill all old Pods and create new ones.
Instead, it gradually replaces old Pods with new ones, controlled by maxSurge (how many extra Pods can be created) and maxUnavailable (how many Pods can be down).
This keeps your service available during updates.
Every time you update a Deployment, a new ReplicaSet is created. Old ReplicaSets are kept around (controlled by revisionHistoryLimit).
If a new version has issues, you can rollback: `kubectl rollout undo deployment/<name>` switches traffic back to the previous ReplicaSet.
Rollback is fast because the old Pods are still running (if you did rolling update with minimal maxUnavailable).
DESIRED: Number of Pods you want (from the Deployment spec).
CURRENT: Number of Pods currently running (may lag behind DESIRED during updates).
UPDATED: Number of Pods with the new image/spec.
READY: Number of Pods passing readiness checks (the only ones receiving traffic).
Key takeaways
💡 Analogy
A Deployment is like a factory production line supervisor. You tell them "I want 3 perfect units." The supervisor (Deployment controller) owns ReplicaSets (production shifts). Each shift (ReplicaSet) has Pods (units). When you change the spec ("now I want v2 units"), the supervisor starts a new shift (new ReplicaSet), gradually shifts workers from old shift to new shift (rolling update), and keeps the old shift around in case you say "abort, go back" (rollback). If a unit breaks, the supervisor immediately replaces it.
⚡ Core Idea
Deployment manages the desired state and update strategy. ReplicaSet maintains the replica count. Deployment creates multiple ReplicaSets over time (one per version); Pods are the actual running instances. Reconciliation loop continuously compares desired vs actual state.
🎯 Why It Matters
Deployments are the most common abstraction you interact with in production. Understanding how they work (revision history, rolling updates, surge configuration) is crucial for safe deployment practices and debugging failed rollouts.
Related concepts
Explore topics that connect to this one.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.