infra / kubernetes

Deployments

Leçon 41 exercice

Explication

Ce que vous allez apprendre

Expliquer pourquoi un Deployment résout le problème de résilience laissé ouvert par un Pod isolé
Décrire la hiérarchie Deployment → ReplicaSet → Pods et le rôle exact de chaque niveau
Utiliser cette hiérarchie pour diagnostiquer un problème (Pod qui ne se recrée pas, nombre de replicas incorrect)
Expliquer le mécanisme de labels/selector qui relie un Deployment à ses Pods
Repérer un décalage entre selector et labels comme cause d'un Deployment qui ne "voit" plus ses Pods

Dans quel contexte ?

Une équipe déploie une API en production avec replicas: 3 dans son Deployment. Un des trois Pods plante suite à une fuite mémoire. Sans même qu'un humain intervienne, le ReplicaSet détecte que seuls 2 Pods sur les 3 attendus sont en vie et en recrée immédiatement un troisième, souvent en quelques secondes. C'est exactement ce mécanisme, invisible en fonctionnement normal mais critique en cas de panne, qui distingue un déploiement fragile d'un déploiement réellement résilient.

Réparer ce qui manquait à la leçon précédente

D'abord, rappelle-toi : un Pod créé seul ne se répare pas tout seul. Le Deployment existe précisément pour combler ce manque.

Ce que dit vraiment un Deployment

C'est un objet de plus haut niveau qui dit à Kubernetes : "je veux toujours N copies identiques de ce Pod, quoi qu'il arrive". Si un Pod meurt, le Deployment en recrée un immédiatement.

Une chaîne à trois niveaux, pas deux

Le Deployment ne gère pas directement les Pods : il délègue ce travail à un objet intermédiaire, le ReplicaSet, dont le seul rôle est de maintenir un nombre exact de Pods identiques.

Niveau	Rôle
Deployment	Gère les versions, orchestre les mises à jour, délègue au ReplicaSet
ReplicaSet	Maintient un nombre exact de Pods identiques en vie
Pod	Unité d'exécution réelle, éphémère par nature

Ce que fait le Deployment en plus du ReplicaSet

Le Deployment, lui, gère les ReplicaSets et orchestre les changements de version, ce qu'on détaillera dans la leçon sur les rolling updates. Retiens la hiérarchie Deployment → ReplicaSet → Pods : elle sert à diagnostiquer les problèmes.

Comment utiliser cette hiérarchie pour déboguer

Si un Pod ne se recrée pas, regarde son ReplicaSet. Si le nombre de replicas semble incorrect, regarde le Deployment lui-même.

Astuce

Pour déboguer un Deployment qui se comporte mal, remontez la hiérarchie dans l'ordre : kubectl get pods (les Pods sont-ils là ?), puis kubectl get replicasets (le bon nombre est-il demandé ?), puis kubectl describe deployment (le Deployment lui-même a-t-il un problème ?).

Comment le Deployment reconnaît ses propres Pods

Il reste une question importante : comment le Deployment sait-il quels Pods lui appartiennent ? Il utilise un système d'étiquettes (labels) : les Pods créés portent une étiquette, et le selector du Deployment doit correspondre EXACTEMENT à cette étiquette.

Le piège du décalage entre selector et labels

Une erreur fréquente est un décalage entre le selector et les labels du template. Le Deployment ne "reconnaît" alors plus ses propres Pods, ce qui provoque des comportements déroutants.

Piège fréquent

Un décalage entre le selector du Deployment et les labels du template de Pod fait que le Deployment ne "reconnaît" plus ses propres Pods. Résultat possible : il en recrée d'autres à côté sans jamais nettoyer les anciens, ou au contraire ne recrée rien du tout. Vérifiez toujours que spec.selector.matchLabels correspond exactement à spec.template.metadata.labels.

Ce qui déclenche une nouvelle version

Toute modification du template (l'image, les variables d'environnement, les ports) déclenche la création d'un nouveau ReplicaSet, tandis que l'ancien est progressivement vidé de ses Pods.

Ce mécanisme est justement ce qui permettra, dans une leçon ultérieure, de faire des mises à jour sans interruption de service. La prochaine leçon s'attaque à un autre problème : comment donner une adresse stable à des Pods dont l'IP change à chaque recréation.

Commandes & code

Deployments

Un Deployment gère un ReplicaSet de Pods identiques : il assure le nombre de replicas désiré et gère les mises à jour.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myorg/api:1.4.2
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get replicasets
kubectl get pods -l app=api        # -l filtre par label

# Scaler manuellement
kubectl scale deployment/api-deployment --replicas=5

# Voir la hiérarchie complète : Deployment -> ReplicaSet -> Pods
kubectl describe deployment api-deployment

Deployment (api-deployment, replicas: 3)
   └── ReplicaSet (api-deployment-7d9f8b6c5)
          ├── Pod (api-deployment-7d9f8b6c5-abc12)
          ├── Pod (api-deployment-7d9f8b6c5-def34)
          └── Pod (api-deployment-7d9f8b6c5-ghi56)

# Changer l'image déclenche un nouveau ReplicaSet et un rolling update (voir leçon dédiée)
kubectl set image deployment/api-deployment api=myorg/api:1.5.0
kubectl rollout status deployment/api-deployment

Résumé

Deployment -> ReplicaSet -> Pods : trois niveaux, on manipule presque toujours le Deployment.
selector.matchLabels doit correspondre exactement aux labels du template.
kubectl scale change le nombre de replicas à chaud.
Toute modification de template crée un nouveau ReplicaSet (historique des versions).

Exercices pratiques

1 disponible

Mission : le Deployment qui ne reconnaît plus ses Pods

Objectif : Diagnostiquer un décalage entre selector et labels dans un Deployment, et utiliser la hiérarchie Deployment -> ReplicaSet -> Pods pour localiser la cause exacte.

Contexte

Un développeur a modifié à la main le manifeste deployment.yaml de l'API de paiement pour ajouter un label tier: backend sur le template de Pod, sans toucher au selector. Après un kubectl apply, kubectl get pods montre des Pods qui semblent tourner, mais kubectl get deployment api-deployment affiche 0/3 prêts en permanence, et de nouveaux Pods apparaissent sans que les anciens soient jamais nettoyés.

Résoudre l’exercice →