Wat zijn Deployments en ReplicaSets, en hoe werken rolling updates en rollbacks?

Question

IT Interview Practice · Accepted Answer

Een **Deployment** is de standaard-controller voor het draaien van stateless apps. Het beheert **ReplicaSets**, en een ReplicaSet houdt een opgegeven aantal identieke Pods draaiend. Jij bewerkt de Deployment; die orchestreert **rolling updates** en **rollbacks** voor je.

## De hiërarchie

```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.
```

## Een Deployment-manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # hoogstens 1 Pod down tijdens de update
      maxSurge: 1            # hoogstens 1 extra Pod boven het gewenste aantal
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: versiewissel zonder downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # trigger een rolling update
kubectl rollout status deployment/web            # volg de voortgang
```

```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 wanneer een release misgaat

```bash
kubectl rollout history deployment/web       # lijst de revisions
kubectl rollout undo deployment/web          # terug naar de vorige revision
kubectl rollout undo deployment/web --to-revision=3
```

Omdat de oude ReplicaSet bewaard blijft (naar 0 geschaald), is een rollback snel: Kubernetes schaalt de vorige ReplicaSet gewoon weer op en de nieuwe omlaag.

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # wijzig het gewenste aantal
```

## Waarom het belangrijk is

Deployments zijn het werkpaard voor het draaien van stateless applicaties op Kubernetes, dus ze begrijpen en hun relatie tot ReplicaSets is essentiële, alledaagse kennis. De gelaagdheid is het kerninzicht: jij beheert een **Deployment**, die **ReplicaSets** bezit (één per versie), en elke ReplicaSet garandeert dat een opgegeven aantal identieke Pods draait — een keten van reconciliation loops die samen self-healing en een stabiel replica-aantal leveren. De echte kracht zit in hoe de Deployment verandering afhandelt: een **rolling update** maakt een nieuwe ReplicaSet aan en verschuift Pods geleidelijk van oud naar nieuw, gestuurd door `maxSurge` en `maxUnavailable`, zodat capaciteit behouden blijft en — gecombineerd met readiness probes die bepalen welke Pods verkeer ontvangen — de release met **zero downtime** verloopt. Omdat de vorige ReplicaSet behouden blijft (naar nul geschaald in plaats van verwijderd), is een **rollback** snel en veilig: `kubectl rollout undo` schaalt simpelweg de oude versie weer op en de slechte omlaag, precies waar je naar grijpt wanneer een release zich misdraagt. Deze mechaniek begrijpen — plus hoe je schaalt (`kubectl scale`) en de voortgang inspecteert (`kubectl rollout status/history`) — is fundamenteel om software veilig te shippen op Kubernetes, en weerspiegelt het declaratieve, controller-gedreven model dat bepaalt hoe het platform in productie werkt.

De hiërarchie

Een Deployment-manifest

Rolling update: versiewissel zonder downtime

Rollback wanneer een release misgaat

Scaling

Waarom het belangrijk is

Gerelateerde vragen