Deployments, ReplicaSets, and Rolling Updates
SummaryCovers the Deployment → ReplicaSet → Pod ownership...
Covers the Deployment → ReplicaSet → Pod ownership...
Covers the Deployment → ReplicaSet → Pod ownership hierarchy, imperative and declarative Deployment creation, rolling update mechanics with maxSurge and maxUnavailable, rollback to specific revisions, and the Recreate vs. RollingUpdate strategy trade-offs.
Deployments, ReplicaSets, and Rolling Updates
If Pods are the atomic unit of Kubernetes, Deployments are the management layer that makes them production-ready. No one runs bare Pods in production — a single Pod on a single node has no redundancy, no self-healing beyond container restarts, no mechanism for rolling out a new image version without downtime. Deployments solve all three problems, and the CKAD tests them heavily.
The argument for Deployments over raw Pods or even raw ReplicaSets is straightforward: Deployments manage the full lifecycle of your application’s rollout. A ReplicaSet maintains a stable set of replica Pods — but it does not know how to transition from one version to another. A Deployment does. It creates a new ReplicaSet for the updated Pod template, scales it up, scales the old ReplicaSet down, and keeps a revision history so you can undo the entire operation with a single command.
Why This Matters on the Exam
Deployment-related tasks appear consistently across CKAD administrations. The scenarios follow predictable patterns:
- Create a Deployment — you need to produce a running Deployment with a specified image, replica count, and labels. Speed matters: knowing the imperative
kubectl create deploymentcommand saves you from writing 25 lines of YAML from scratch. - Update an image — a running Deployment needs its container image changed. You need to trigger a rolling update and verify it completes successfully.
- Rollback — something went wrong with the update. You need to inspect the rollout history, identify the correct revision, and roll back to it.
- Scale — increase or decrease the replica count. This one is fast if you know the command, painfully slow if you are editing YAML.
Each of these tasks tests whether you understand the relationship between Deployments, ReplicaSets, and Pods — and whether you can work with that relationship efficiently under time pressure.
What This Chapter Covers
The sections that follow break Deployment mechanics into two focused areas:
-
Deployment Mechanics and ReplicaSets — the ownership chain from Deployment to ReplicaSet to Pod, why Deployments exist as a layer above ReplicaSets, imperative creation and YAML generation, scaling, and how labels and selectors bind the hierarchy together.
-
Rolling Updates, Rollbacks, and Update Strategies — the rolling update algorithm with
maxSurgeandmaxUnavailable, a step-by-step visualization of how old and new ReplicaSets transition, thekubectl rolloutfamily of commands, rollback to specific revisions, the Recreate strategy as an alternative, and pause/resume for controlled rollouts.
These two sections contain the commands and patterns you will use on virtually every CKAD task that involves application deployment. The workflow — create, update, verify, roll back if needed — is the core operational loop for Kubernetes application developers.