Why Deployments Exist
A bare Pod is fragile: if the node dies or the Pod crashes, nothing brings it back. Kubernetes solves this with controllers that continuously reconcile actual state with desired state. The Deployment is the standard controller for stateless workloads, and it works by managing an underlying ReplicaSet, which in turn manages a set of identical Pods.
Cricket analogy: A bare Pod is like a lone fielder with no twelfth man cover; if he twists an ankle, no one replaces him, but Kubernetes controllers act like a team management continuously checking the XI and sending in a substitute the moment someone's missing.
ReplicaSets: The Replica-Counting Layer
A ReplicaSet's only job is to ensure a specified number of Pod replicas matching a label selector are running at all times. If a Pod is deleted or its node fails, the ReplicaSet controller notices the drift and creates a replacement. You rarely create a ReplicaSet directly; instead a Deployment creates and owns one for you.
Cricket analogy: A ReplicaSet is like a team manager whose only job is keeping exactly eleven fit players named on the sheet; if a player is injured mid-match, they immediately call up a reserve from the bench matching the same squad list.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: web-rs
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.25
ports:
- containerPort: 80Deployments: Declarative Updates on Top of ReplicaSets
A Deployment adds rollout management: when you change the Pod template (for example, a new image tag), the Deployment controller creates a new ReplicaSet and gradually shifts replicas from the old ReplicaSet to the new one according to a strategy. This gives you rolling updates, rollback, and pause/resume for free.
Cricket analogy: A Deployment rolling out a new Pod template is like a captain gradually resting senior players for a new lineup across a series, bringing in the fresh XI match by match rather than dropping the whole old team at once, with the option to revert to the old lineup if the new one underperforms.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256MiThe selector Must Match the Template Labels
spec.selector.matchLabels is immutable after creation and must be a subset of spec.template.metadata.labels. If they do not match, the Deployment is rejected by the API server. A mismatched selector across two Deployments can also cause them to fight over the same Pods.
Scaling and Inspecting Rollouts
You can scale a Deployment imperatively with kubectl scale deployment/web --replicas=5, or edit spec.replicas declaratively. To watch a rollout in progress use kubectl rollout status deployment/web, and to see rollout history use kubectl rollout history deployment/web.
Cricket analogy: Scaling a Deployment to 5 replicas is like a franchise deciding to field five identical net-bowling units for practice, and checking kubectl rollout status is like the coach watching the scoreboard live to confirm the new bowling rotation has fully taken over from the old one.
Each Deployment revision is tracked via the ReplicaSet's revision annotation. kubectl rollout undo deployment/web rolls back to the previous ReplicaSet, and kubectl rollout undo deployment/web --to-revision=2 targets a specific one.
- A Deployment manages ReplicaSets; a ReplicaSet manages Pods -- you almost never create a ReplicaSet by hand.
- spec.selector.matchLabels is immutable and must match spec.template.metadata.labels.
- RollingUpdate is the default strategy; maxUnavailable and maxSurge control rollout speed and availability.
- kubectl rollout status / history / undo are the primary commands for managing rollouts.
- Old ReplicaSets are kept (scaled to 0) so rollbacks are fast; revisionHistoryLimit controls how many are retained.
- Deployments are for stateless workloads; use StatefulSets when Pods need stable identity or storage.
Practice what you learned
1. What resource does a Deployment directly create and manage to run Pods?
2. Which field is immutable once a Deployment is created?
3. During a RollingUpdate, what does maxUnavailable control?
4. Which command rolls a Deployment back to its previous revision?
5. Why do old ReplicaSets remain (scaled to 0) after a rollout instead of being deleted?
Was this page helpful?
You May Also Like
Pods Explained
An explanation of Pods, the smallest deployable unit in Kubernetes, covering their structure, lifecycle, and a minimal manifest example.
Rolling Updates and Rollbacks
Learn how Kubernetes Deployments update Pods gradually with zero downtime and how to roll back safely when a release breaks.
Horizontal Pod Autoscaling
Learn how the HorizontalPodAutoscaler automatically adjusts replica counts based on CPU, memory, or custom metrics to match workload demand.
kubectl Basics
A practical introduction to kubectl, the command-line tool used to interact with a Kubernetes cluster's API server.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics