Deployments : déployer et mettre à jour

🎯 Objectif : À la fin de ce chapitre, tu sauras créer des Deployments, lancer des rolling updates sans downtime, faire un rollback en cas de problème, et scaler tes applications horizontalement. ⏱️ Durée estimée : 50 minutes | Niveau : Intermédiaire

En production, personne ne lance des Pods nus. Un Pod qui crashe, il disparaît — point final. Pour qu’une application tourne de manière fiable, il faut un mécanisme qui surveille, remplace et met à jour tes Pods automatiquement. C’est exactement le rôle du Deployment, l’objet Kubernetes que tu utiliseras dans 90 % des cas pour déployer des applications stateless.

Dans ce chapitre, tu vas comprendre comment les Deployments fonctionnent sous le capot, apprendre les commandes qui comptent vraiment, et voir comment une équipe les utilise concrètement en entreprise.

Pourquoi les Deployments sont incontournables

Sans Deployment, tu gères tes Pods à la main. Un Pod tombe ? Tu le recrées manuellement. Une mise à jour ? Tu supprimes l’ancien, tu lances le nouveau — avec un trou de service entre les deux. À l’échelle d’un cluster de production avec des dizaines de microservices, c’est ingérable.

Le Deployment résout trois problèmes fondamentaux :

• La résilience : il maintient toujours le nombre de répliques que tu as défini. Un Pod crashe, un autre prend sa place en quelques secondes.
• Les mises à jour sans downtime : grâce au rolling update, les anciens Pods sont remplacés progressivement par les nouveaux. Tes utilisateurs ne voient rien.
• Le retour arrière : un bug en prod ? Un kubectl rollout undo et tu reviens à la version précédente en une commande.

🔥 Cas réel : Une startup SaaS déploie une nouvelle version de son API un vendredi soir. Le rolling update démarre, mais les nouveaux Pods crashent en boucle (une variable d’env manquante). Grâce au Deployment, les anciens Pods sont toujours actifs — aucun client n’est impacté. L’équipe lance un rollback en 10 secondes et rentre chez elle sereinement.

Comprendre le concept

Un Deployment ne gère pas les Pods directement. Il crée un ReplicaSet, et c’est le ReplicaSet qui s’occupe de maintenir le bon nombre de Pods. Cette couche intermédiaire est ce qui rend les rolling updates possibles.

Quand tu mets à jour l’image d’un Deployment, voici ce qui se passe :

1. Kubernetes crée un nouveau ReplicaSet avec la nouvelle version
2. Il monte progressivement les Pods du nouveau ReplicaSet
3. Il descend progressivement les Pods de l’ancien ReplicaSet
4. À la fin, l’ancien ReplicaSet reste (avec 0 répliques) pour permettre un rollback

💡 Tip DevOps : Ne supprime jamais les anciens ReplicaSets manuellement. Kubernetes les conserve pour l’historique de rollback (10 révisions par défaut, configurable via spec.revisionHistoryLimit).

Voici un manifest de Deployment complet et prêt pour la production :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend
  labels:
    app: api-backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-backend
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api-backend
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Décortiquons les points clés :

• selector.matchLabels doit correspondre exactement aux labels dans template.metadata.labels — sinon le Deployment ne sait pas quels Pods lui appartiennent.
• maxSurge: 1 + maxUnavailable: 0 = zero downtime garanti. Kubernetes crée un nouveau Pod, attend qu’il soit ready, puis supprime un ancien.
• readinessProbe : indispensable. Sans elle, Kubernetes envoie du trafic au Pod dès le démarrage du container, avant que ton app soit réellement prête.
• resources : toujours les définir. Sans limites, un Pod peut consommer toute la mémoire d’un nœud et faire tomber les autres workloads.

⚠️ Attention : La stratégie Recreate (l’alternative au RollingUpdate) supprime tous les anciens Pods avant de créer les nouveaux. C’est un downtime assumé — à utiliser uniquement si deux versions de ton app ne peuvent pas coexister (migration de schéma de BDD, par exemple).

Commandes essentielles

Pour appliquer ton Deployment et vérifier que tout est en place :

kubectl apply -f api-deployment.yaml
kubectl get deploy,rs,pods -l app=api-backend

Tu verras les trois niveaux d’objets : Deployment → ReplicaSet → Pods.

Pour lancer une mise à jour d’image et suivre son déroulement :

kubectl set image deployment/api-backend api=registry.example.com/api:1.5.0
kubectl rollout status deployment/api-backend

Pour consulter l’historique et revenir en arrière si nécessaire :

kubectl rollout history deployment/api-backend
kubectl rollout undo deployment/api-backend

Pour scaler manuellement en cas de pic de charge :

kubectl scale deployment/api-backend --replicas=5

Et pour documenter tes déploiements dans l’historique (très utile en post-mortem) :

kubectl annotate deployment/api-backend kubernetes.io/change-cause="v1.5.0 - fix auth timeout"

🧠 À retenir : kubectl rollout undo revient à la révision précédente. Pour revenir à une version spécifique, utilise kubectl rollout undo deployment/api-backend --to-revision=2.

Cas concret : scaling automatique en entreprise

Imaginons une plateforme e-commerce. En temps normal, 3 répliques du service catalogue suffisent. Mais pendant les soldes, le trafic est multiplié par 10. Scaler manuellement, c’est du babysitting.

Le Horizontal Pod Autoscaler (HPA) ajuste automatiquement le nombre de répliques en fonction de métriques comme le CPU ou la mémoire :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-backend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-backend
  minReplicas: 3
  maxReplicas: 15
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Le HPA évalue les métriques toutes les 15 secondes. Il scale up rapidement (dès que le seuil est dépassé), mais scale down prudemment — il attend 5 minutes de stabilisation pour éviter le flapping (des Pods qui montent et descendent en boucle).

💡 Tip DevOps : Le HPA nécessite le Metrics Server dans ton cluster. Sans lui, le HPA ne reçoit aucune métrique et reste bloqué sur <unknown>. Vérifie avec kubectl top pods — si ça ne renvoie rien, installe le Metrics Server.

🔥 Cas réel : Chez un gros retailer, le HPA passe de 3 à 12 répliques pendant le Black Friday en quelques minutes, puis redescend automatiquement à 3 dans la nuit. Sans intervention humaine. Le coût infra suit la charge réelle au lieu d’être provisionné au pic permanent.

Pièges fréquents

Oublier les resources requests/limits. Sans requests, le scheduler place les Pods n’importe où. Sans limits, un Pod peut OOM-kill ses voisins. Résultat : des crashs en cascade impossibles à diagnostiquer.

Pas de readinessProbe. Kubernetes considère le Pod ready dès que le container démarre. Si ton app met 10 secondes à s’initialiser, tu as 10 secondes de 502 à chaque rolling update.

Utiliser le tag latest. Kubernetes ne redéploie pas si le tag d’image n’a pas changé. Avec latest, tu pousses une nouvelle image mais le Deployment ne bouge pas — parce que le tag est toujours le même. Utilise des tags versionnés (v1.4.0, v1.5.0).

⚠️ Attention : Un maxUnavailable: 25% (le défaut) sur un Deployment de 4 répliques = 1 Pod down pendant le rolling update. Si ta readinessProbe est mal configurée et que le nouveau Pod n’est jamais ready, tu restes bloqué avec 3 Pods pendant un temps indéfini. Mets maxUnavailable: 0 pour être safe.

Confondre livenessProbe et readinessProbe. La liveness redémarre un Pod bloqué. La readiness retire un Pod du trafic le temps qu’il soit prêt. Si tu mets une liveness trop agressive (timeout court, seuil bas), Kubernetes va kill-loop tes Pods au moindre pic de latence.

Exercice pratique

Crée un Deployment webapp avec 3 répliques qui utilise l’image nginx:1.27. Définis des resources requests (100m CPU, 128Mi mémoire) et une readinessProbe sur le port 80. Applique-le et vérifie que les 3 Pods tournent.

Ensuite, mets à jour l’image vers nginx:1.28 avec kubectl set image. Observe le rolling update avec kubectl rollout status. Vérifie l’historique avec kubectl rollout history, puis fais un rollback vers la version 1.27.

Pour aller plus loin : crée un HPA qui scale ton Deployment entre 2 et 8 répliques à 60 % de CPU.

🧠 À retenir :

• Un Deployment gère des ReplicaSets, qui gèrent des Pods — trois niveaux
• maxSurge: 1 + maxUnavailable: 0 = zero downtime
• Toujours définir resources, readinessProbe, et des tags d’image versionnés
• kubectl rollout undo est ton filet de sécurité — il fonctionne parce que les anciens ReplicaSets sont conservés
• Le HPA automatise le scaling mais nécessite le Metrics Server

➡️ La suite : Dans le prochain chapitre, on aborde les Services Kubernetes, Ingress et les NetworkPolicies. On continue ! 🚀