What is a Kubernetes Deployment and How Does It Manage Rollouts?
Learn how Kubernetes Deployments manage ReplicaSets, roll out updates safely, and roll back instantly — with a clear DevOps interview answer.
Expected Interview Answer
A Kubernetes Deployment is a controller object that manages a set of identical Pods through a ReplicaSet, declaratively keeping the desired number of replicas running and orchestrating rolling updates and rollbacks whenever the Pod template changes.
You describe the desired state in a Deployment spec — the container image, replica count, and update strategy — and the Deployment controller continuously reconciles the live cluster state toward that desired state. Internally, a Deployment owns a ReplicaSet, and the ReplicaSet owns the actual Pods; when you change the Pod template (for example, bumping the image tag), the Deployment creates a new ReplicaSet and gradually shifts Pods from the old ReplicaSet to the new one according to the `RollingUpdate` strategy, controlled by `maxSurge` and `maxUnavailable`. Every rollout is recorded in revision history, so `kubectl rollout undo` can revert to a previous ReplicaSet almost instantly if the new version misbehaves. Readiness probes gate the rollout: a new Pod is not counted as available until it passes its readiness check, which prevents a bad release from taking down all capacity at once.
- Guarantees a stable, self-healing replica count at all times
- Enables zero-downtime rolling updates with configurable pace
- Provides instant rollback via revision history
- Decouples desired state from manual Pod management
AI Mentor Explanation
A Deployment is like a franchise’s playing-XI policy that always insists on eleven fit players on the field, no matter who gets injured. When the team management wants to bring in a new set of players with updated training methods, they swap in the new players one or two at a time across matches rather than fielding an entirely new eleven at once, keeping a minimum number of experienced players on the park throughout. If the new signings clearly underperform, management reverts to the previous, proven eleven for the next match. This gradual swap-in, swap-out approach is exactly how a rolling update replaces old Pods with new ones.
Step-by-Step Explanation
Step 1
Declare desired state
Write a Deployment manifest with the container image, replica count, and update strategy.
Step 2
Controller creates a ReplicaSet
The Deployment controller creates a ReplicaSet that in turn creates and supervises the actual Pods.
Step 3
Trigger a rolling update
Changing the Pod template creates a new ReplicaSet; Pods migrate gradually per maxSurge/maxUnavailable, gated by readiness probes.
Step 4
Roll back if needed
kubectl rollout undo reverts to a prior revision by scaling the old ReplicaSet back up and the new one down.
What Interviewer Expects
- Understanding of the Deployment → ReplicaSet → Pod ownership chain
- Knowledge of maxSurge and maxUnavailable controlling rollout pace
- Awareness that readiness probes gate whether a new Pod counts as available
- Ability to explain rollback via revision history
Common Mistakes
- Confusing a Deployment with a ReplicaSet or a bare Pod
- Forgetting that Deployments are for stateless workloads, not StatefulSets
- Not mentioning readiness probes as the rollout safety gate
- Assuming rollback requires re-deploying a new manifest instead of using rollout history
Best Answer (HR Friendly)
“A Deployment is the object we use to describe how many copies of our app should be running and how to update them safely. Kubernetes constantly checks that the actual number of running copies matches what we asked for, and when we ship a new version, it swaps old copies for new ones a few at a time so users never see downtime, with an easy one-command rollback if something goes wrong.”
Code Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:2.0
readinessProbe:
httpGet:
path: /healthz
port: 8080Follow-up Questions
- What is the difference between a Deployment and a StatefulSet?
- How do maxSurge and maxUnavailable affect rollout speed and safety?
- How would you pause a rollout that appears to be failing midway?
- What role do readiness probes play during a rolling update?
MCQ Practice
1. What does a Kubernetes Deployment directly own and manage?
A Deployment creates and manages a ReplicaSet, and the ReplicaSet in turn creates and supervises the Pods.
2. What controls how many extra or unavailable Pods are allowed during a rolling update?
maxSurge caps extra Pods created above the desired count, and maxUnavailable caps how many can be unavailable during the update.
3. How does kubectl rollout undo restore a previous version?
Rollback reuses the retained prior ReplicaSet revision, scaling it up while scaling the failed ReplicaSet down.
Flash Cards
What does a Deployment manage? — A ReplicaSet, which manages the actual Pods — the Deployment reconciles desired state.
What triggers a new rollout? — Changing the Pod template, e.g. the container image tag.
What gates a Pod being counted as available during rollout? — Its readiness probe passing.
How do you roll back a bad Deployment? — kubectl rollout undo, which restores a prior ReplicaSet revision.