Che cosa sono i Deployment e i ReplicaSet, e come funzionano i rolling update e i rollback?

Question

IT Interview Practice · Accepted Answer

Un **Deployment** è il controller standard per far girare applicazioni stateless. Gestisce i **ReplicaSet**, e un ReplicaSet mantiene in esecuzione un numero specificato di Pod identici. Tu modifichi il Deployment; lui orchestra i **rolling update** e i **rollback** al posto tuo.

## La gerarchia

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

## Un manifest di Deployment

```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: cambio di versione a zero downtime

```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 quando un rilascio va male

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

Poiché il vecchio ReplicaSet viene mantenuto (scalato a 0), un rollback è rapido: Kubernetes si limita a riscalare verso l'alto il ReplicaSet precedente e verso il basso quello nuovo.

## Scaling

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

## Perché è importante

I Deployment sono il cavallo di battaglia per far girare applicazioni stateless su Kubernetes, quindi capirli e capire il loro rapporto con i ReplicaSet è una conoscenza essenziale, di uso quotidiano. La stratificazione è l'intuizione chiave: tu gestisci un **Deployment**, che possiede dei **ReplicaSet** (uno per versione), e ogni ReplicaSet garantisce che un numero specificato di Pod identici sia in esecuzione — una catena di reconciliation loop che insieme forniscono self-healing e un conteggio di replica stabile. La vera potenza sta in come il Deployment gestisce il cambiamento: un **rolling update** crea un nuovo ReplicaSet e sposta i Pod dal vecchio al nuovo in modo graduale, governato da `maxSurge` e `maxUnavailable`, così la capacità è preservata e — combinata con le readiness probe che regolano quali Pod ricevono traffico — il rilascio avviene a **zero downtime**. Poiché il ReplicaSet precedente è conservato (scalato a zero anziché eliminato), un **rollback** è rapido e sicuro: `kubectl rollout undo` si limita a riscalare verso l'alto la vecchia versione e verso il basso quella difettosa, ed è esattamente ciò a cui ricorri quando un rilascio si comporta male. Capire questi meccanismi — oltre a come scalare (`kubectl scale`) e ispezionare l'avanzamento (`kubectl rollout status/history`) — è fondamentale per rilasciare software in sicurezza su Kubernetes, e riflette il modello dichiarativo, guidato dai controller, che definisce come la piattaforma opera in produzione.

La gerarchia

Un manifest di Deployment

Rolling update: cambio di versione a zero downtime

Rollback quando un rilascio va male

Scaling

Perché è importante

Domande correlate