What are Deployments and ReplicaSets, and how do rolling updates and rollbacks work?

Question

IT Interview Practice · Accepted Answer

A **Deployment** is the standard controller for running stateless apps. It manages **ReplicaSets**, and a ReplicaSet keeps a specified number of identical Pods running. You edit the Deployment; it orchestrates **rolling updates** and **rollbacks** for you.

## The hierarchy

```text
Deployment  → declares desired state + update strategy (the thing YOU manage)
   └── ReplicaSet  → ensures N identical Pods exist (one per app version)
          └── Pod  → Pod → Pod ...  (the actual running copies)

On each new version, the Deployment creates a NEW ReplicaSet and shifts Pods over.
```

## A Deployment manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # at most 1 Pod down during the update
      maxSurge: 1            # at most 1 extra Pod above desired count
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: zero-downtime version change

```bash
kubectl set image deployment/web web=myapp:2.0   # trigger a rolling update
kubectl rollout status deployment/web            # watch progress
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 old Pods)
      █████       spin up 1 new (v2), now 5 total (surge)
      ███ █       old down to 3, new is Ready
      ...gradually shift...
  v2: ████        (end: 4 new Pods, old ReplicaSet scaled to 0)
Traffic only goes to Pods that pass their readiness probe → no downtime.
```

## Rollback when a release goes bad

```bash
kubectl rollout history deployment/web       # list revisions
kubectl rollout undo deployment/web          # roll back to previous revision
kubectl rollout undo deployment/web --to-revision=3
```

Because the old ReplicaSet is kept (scaled to 0), a rollback is fast: Kubernetes just scales the previous ReplicaSet back up and the new one down.

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # change desired count
```

## Why it matters

Deployments are the workhorse for running stateless applications on Kubernetes, so understanding them and their relationship to ReplicaSets is essential, everyday knowledge. The layering is the key insight: you manage a **Deployment**, which owns **ReplicaSets** (one per version), and each ReplicaSet guarantees that a specified number of identical Pods are running — a chain of reconciliation loops that together deliver self-healing and a stable replica count. The real power is in how the Deployment handles change: a **rolling update** creates a new ReplicaSet and shifts Pods from old to new gradually, governed by `maxSurge` and `maxUnavailable`, so capacity is preserved and — combined with readiness probes that gate which Pods receive traffic — the release happens with **zero downtime**. Because the previous ReplicaSet is retained (scaled to zero rather than deleted), a **rollback** is fast and safe: `kubectl rollout undo` simply scales the old version back up and the bad one down, which is exactly what you reach for when a release misbehaves. Understanding these mechanics — plus how to scale (`kubectl scale`) and inspect progress (`kubectl rollout status/history`) — is fundamental to shipping software safely on Kubernetes, and reflects the declarative, controller-driven model that defines how the platform operates in production.

The hierarchy

A Deployment manifest

Rolling update: zero-downtime version change

Rollback when a release goes bad

Scaling

Why it matters

Related questions