Que sont les Deployments et les ReplicaSets, et comment fonctionnent les rolling updates et les rollbacks ?

Question

IT Interview Practice · Accepted Answer

Un **Deployment** est le controller standard pour faire tourner des applications stateless. Il gère des **ReplicaSets**, et un ReplicaSet maintient un nombre spécifié de Pods identiques en cours d'exécution. Vous éditez le Deployment ; il orchestre les **rolling updates** et les **rollbacks** pour vous.

## La hiérarchie

```text
Deployment  → déclare l'état désiré + la stratégie de mise à jour (ce que VOUS gérez)
   └── ReplicaSet  → garantit que N Pods identiques existent (un par version d'app)
          └── Pod  → Pod → Pod ...  (les copies réellement en cours d'exécution)

À chaque nouvelle version, le Deployment crée un NOUVEAU ReplicaSet et y transfère les Pods.
```

## Un manifest de Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # au plus 1 Pod indisponible pendant la mise à jour
      maxSurge: 1            # au plus 1 Pod supplémentaire au-dessus du nombre désiré
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update : changement de version sans interruption

```bash
kubectl set image deployment/web web=myapp:2.0   # déclencher un rolling update
kubectl rollout status deployment/web            # suivre la progression
```

```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)
Le trafic ne va qu'aux Pods qui passent leur readiness probe → aucune interruption.
```

## Rollback quand une release tourne mal

```bash
kubectl rollout history deployment/web       # lister les révisions
kubectl rollout undo deployment/web          # revenir à la révision précédente
kubectl rollout undo deployment/web --to-revision=3
```

Parce que l'ancien ReplicaSet est conservé (mis à l'échelle 0), un rollback est rapide : Kubernetes remonte simplement le ReplicaSet précédent et redescend le nouveau.

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # changer le nombre désiré
```

## Pourquoi c'est important

Les Deployments sont le cheval de bataille pour faire tourner des applications stateless sur Kubernetes, donc les comprendre ainsi que leur relation avec les ReplicaSets est une connaissance essentielle et quotidienne. La superposition est l'idée clé : vous gérez un **Deployment**, qui possède des **ReplicaSets** (un par version), et chaque ReplicaSet garantit qu'un nombre spécifié de Pods identiques est en cours d'exécution — une chaîne de boucles de réconciliation qui, ensemble, apportent l'auto-réparation et un nombre de replicas stable. La véritable puissance réside dans la façon dont le Deployment gère le changement : un **rolling update** crée un nouveau ReplicaSet et transfère les Pods de l'ancien vers le nouveau progressivement, régi par `maxSurge` et `maxUnavailable`, de sorte que la capacité est préservée et — combiné aux readiness probes qui filtrent quels Pods reçoivent du trafic — la release se fait **sans interruption**. Parce que le ReplicaSet précédent est conservé (mis à l'échelle 0 plutôt que supprimé), un **rollback** est rapide et sûr : `kubectl rollout undo` remonte simplement l'ancienne version et redescend celle qui pose problème, exactement ce vers quoi vous vous tournez quand une release se comporte mal. Comprendre ces mécanismes — plus comment mettre à l'échelle (`kubectl scale`) et inspecter la progression (`kubectl rollout status/history`) — est fondamental pour livrer du logiciel en toute sécurité sur Kubernetes, et reflète le modèle déclaratif, piloté par des controllers, qui définit le fonctionnement de la plateforme en production.

La hiérarchie

Un manifest de Deployment

Rolling update : changement de version sans interruption

Rollback quand une release tourne mal

Scaling

Pourquoi c'est important

Questions connexes