Deployments In Depth
A Deployment is a controller that manages one or more ReplicaSets to keep a declared number of stateless pod replicas running. You describe the desired end state — image version, replica count, resource requests — and the Deployment controller continuously reconciles the cluster toward that state, replacing crashed pods and orchestrating updates without manual intervention.
Cricket analogy: Like a franchise's team management setting a fixed playing XI of 11 for every match — if Rishabh Pant gets injured, the team management (controller) automatically fields a replacement so the XI count never drops below the declared strength.
Rolling Updates and Rollback
When you change a Deployment's pod template — most commonly the container image — the default RollingUpdate strategy creates a new ReplicaSet and gradually scales it up while scaling the old one down. The fields maxSurge and maxUnavailable control how many extra pods can exist above the desired count and how many can be unavailable during the transition, letting you tune the update for speed versus safety.
Cricket analogy: Like a team transitioning its bowling attack mid-series — instead of dropping all seamers at once, the selectors bring in one new fast bowler per match while resting one veteran, keeping the attack always at full strength.
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-api
labels:
app: checkout-api
spec:
replicas: 6
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 1
selector:
matchLabels:
app: checkout-api
template:
metadata:
labels:
app: checkout-api
spec:
containers:
- name: checkout-api
image: registry.example.com/checkout-api:2.4.1
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
resources:
requests:
cpu: 250m
memory: 256MiRevisionHistory and Rollback
Kubernetes keeps old, scaled-to-zero ReplicaSets around as revision history, bounded by revisionHistoryLimit. Commands like kubectl rollout history checkout-api and kubectl rollout undo checkout-api --to-revision=3 let you inspect and revert to a prior pod template instantly, because the controller simply scales the target ReplicaSet back up and the current one down — no rebuild required.
Cricket analogy: Like a scorer's archive keeping the last few match scorecards on file — when a review shows the current XI selection was a mistake, the captain can instantly revert to the previous match's proven lineup instead of starting from scratch.
kubectl rollout pause checkout-api lets you stop a rollout mid-way after only a few pods have updated, inspect metrics or logs on the canary pods, and then either kubectl rollout resume to continue or undo to abort — a lightweight canary pattern without extra tooling.
The Recreate Strategy
The Recreate strategy terminates all existing pods before creating any new ones, guaranteeing that old and new versions never run simultaneously. It is the right choice when two versions of an application cannot coexist safely — for example, a schema migration that the new code depends on but the old code cannot handle — at the cost of a brief full outage during the switch.
Cricket analogy: Like a ground staff completely relaying an entire pitch between Test matches rather than patching it mid-series — the ground is fully closed during relay because old and new pitch surfaces cannot coexist for a single match.
Recreate causes real downtime proportional to your pod startup time, since Kubernetes waits for all old pods to terminate before scheduling any new ones. Never use it for latency-sensitive, always-on services unless a genuine version-incompatibility forces it.
- A Deployment manages ReplicaSets to keep a declared number of stateless pod replicas running and self-heals on failures.
- RollingUpdate is the default strategy; maxSurge and maxUnavailable tune how aggressively pods are replaced.
- revisionHistoryLimit retains old, scaled-to-zero ReplicaSets so kubectl rollout undo can revert instantly.
- kubectl rollout pause/resume enables a lightweight canary-style controlled rollout.
- Recreate strategy terminates all old pods before creating new ones, trading downtime for guaranteed version isolation.
- Readiness probes gate how the rolling update judges a new pod as available before proceeding.
- Deployments are for stateless workloads; they do not provide stable network identity or per-pod storage.
Practice what you learned
1. What Kubernetes object does a Deployment directly manage to run pods?
2. Which field limits how many pods above the desired replica count can exist during a rolling update?
3. Why can kubectl rollout undo revert a Deployment almost instantly?
4. When is the Recreate update strategy the correct choice?
5. What does kubectl rollout pause enable?
Was this page helpful?
You May Also Like
StatefulSets Explained
How StatefulSets provide stable network identities, ordered lifecycle guarantees, and persistent per-pod storage for stateful applications.
DaemonSets Explained
How DaemonSets guarantee exactly one pod per matching node for node-level infrastructure like log collectors, monitoring agents, and CNI plugins.
Pod Disruption Budgets
How PodDisruptionBudgets protect application availability during voluntary disruptions like node drains, upgrades, and cluster autoscaler actions.