KCNA — Deployments & ReplicaSets
Deployments & ReplicaSets
A Deployment is the standard way to manage pods in Kubernetes. It provides declarative updates, rolling deployments, and automatic rollbacks.
The Hierarchy
Deployment (what you create)
│
└── ReplicaSet (auto-created by Deployment)
│
├── Pod 1
├── Pod 2
└── Pod 3
You create a Deployment → it creates a ReplicaSet → the ReplicaSet creates Pods.
Deployments
What a Deployment Does
| Feature | Description |
|---|---|
| Replica management | Ensures the desired number of pod replicas are always running |
| Rolling updates | Updates pods gradually with zero downtime |
| Rollback | Reverts to a previous version if something goes wrong |
| Self-healing | Replaces pods that crash or are deleted |
| Scaling | Easily scale up or down by changing the replica count |
Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3 # Desired pod count
selector:
matchLabels:
app: web # Must match pod template labels
strategy:
type: RollingUpdate # Default strategy
rollingUpdate:
maxSurge: 1 # 1 extra pod during update
maxUnavailable: 0 # 0 pods can be unavailable
template: # Pod template
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25
ReplicaSets
What a ReplicaSet Does
| Aspect | Details |
|---|---|
| Purpose | Maintains a stable set of pod replicas at any given time |
| How it works | Watches pod count; creates or deletes pods to match the desired count |
| Created by | Automatically created and managed by a Deployment |
| Direct use | You almost never create ReplicaSets directly — always use Deployments |
Reconciliation loop:
Desired state: replicas: 3
Actual state: 2 pods running (1 crashed)
ReplicaSet: "I need 3 but have 2 → create 1 more pod"
Rolling Updates
When you update a Deployment (e.g., change the image version), Kubernetes performs a rolling update:
Before: [v1] [v1] [v1] (3 pods running v1)
Step 1: [v1] [v1] [v1] [v2] (1 new pod created)
Step 2: [v1] [v1] [v2] (1 old pod terminated)
Step 3: [v1] [v1] [v2] [v2] (1 new pod created)
Step 4: [v1] [v2] [v2] (1 old pod terminated)
Step 5: [v1] [v2] [v2] [v2] (1 new pod created)
Step 6: [v2] [v2] [v2] (last old pod terminated)
After: [v2] [v2] [v2] (3 pods running v2, zero downtime)
Update Strategies
| Strategy | How It Works | Use Case |
|---|---|---|
| RollingUpdate (default) | Gradually replaces old pods with new ones | Production deployments — zero downtime |
| Recreate | Kills all old pods, then creates new ones | When you can’t run two versions simultaneously |
Rollbacks
If a new version has problems, you can roll back:
Deployment History:
Revision 1: nginx:1.24
Revision 2: nginx:1.25 ← current (broken!)
Rollback → Revision 1: nginx:1.24 (working again)
Kubernetes keeps track of previous ReplicaSets, making rollbacks fast — it simply scales up the old ReplicaSet and scales down the new one.
Scaling
| Scaling Type | How It Works |
|---|---|
| Manual | Change replicas in the Deployment spec |
| Horizontal Pod Autoscaler (HPA) | Automatically adjusts replicas based on CPU/memory metrics |
replicas: 3 → replicas: 5 (scale up)
replicas: 5 → replicas: 2 (scale down)
Exam note: Know that HPA exists and scales based on metrics. Deeper HPA knowledge is more relevant for CKA/CKAD.
Other Workload Resources
Besides Deployments, Kubernetes has other controllers for different use cases:
| Resource | Use Case | Key Behavior |
|---|---|---|
| Deployment | Stateless applications | Rolling updates, scaling, self-healing |
| StatefulSet | Stateful applications (databases) | Stable network IDs, ordered pod creation, persistent storage |
| DaemonSet | One pod per node (monitoring agents, log collectors) | Ensures a copy runs on every (or selected) node |
| Job | One-time tasks | Runs a pod to completion, then stops |
| CronJob | Scheduled tasks | Runs Jobs on a cron schedule |
Key Takeaways for the Exam
- Deployments are the standard way to run stateless applications
- Deployments create ReplicaSets, which create Pods — you work with Deployments, not ReplicaSets directly
- Rolling updates replace pods gradually with zero downtime (default strategy)
- Rollbacks are fast because Kubernetes keeps previous ReplicaSets
- ReplicaSets ensure the correct number of pod replicas at all times
- Know the other workload types: StatefulSet (stateful), DaemonSet (per-node), Job (run-to-completion), CronJob (scheduled)
- HPA can automatically scale pods based on metrics
What’s Next?
Pods need stable networking. Let’s learn how Services provide that.
