Votre premier Deployment Kubernetes vraiment fiable

La plupart des premiers « Hello World » Kubernetes se terminent par un Pod créé à la main. Ça marche cinq minutes. Puis quelqu’un redémarre le nœud, ou vous voulez deux réplicas, ou l’image est mauvaise — et il n’y a plus rien.

Le Deployment existe pour une seule raison : déclarer l’état désiré d’une application, et laisser le cluster le maintenir. Tant que vous ne l’avez pas compris, Kubernetes reste une machine à créer des Pods fragiles.

Ce qu’un Pod ne peut pas faire seul

Un Pod est l’unité d’exécution. Il n’est pas l’unité de gestion.

Autrement dit : le Pod est ce qui tourne ; le Deployment est ce qui veille à ce que ça tourne.

Le manifeste minimal qui tient debout

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/exemple/api:1.2.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi

Trois détails qui séparent un labo d’un déploiement utilisable :

1. readinessProbe — sans elle, le Service envoie du trafic dès que le conteneur démarre, y compris pendant le warm-up.
2. resources.requests — sans elles, le scheduler place le Pod « où ça passe », et vous découvrez les OOM au pire moment.
3. Un tag d’image précis (1.2.0, pas latest) — latest rend les rollbacks impossibles à raisonner.

Le sélecteur : l’erreur qui casse tout

selector:
  matchLabels:
    app: api
template:
  metadata:
    labels:
      app: api

Ces deux blocs doivent correspondre. Le Deployment ne « possède » que les Pods dont les labels matchent le sélecteur. Si vous changez les labels du template sans mettre à jour le sélecteur, Kubernetes refuse l’update — et c’est une bonne nouvelle : autrement, vous orphelineriez des Pods.

Vérifier que ça tient vraiment

kubectl apply -f api-deployment.yaml
kubectl rollout status deployment/api
kubectl get pods -l app=api
kubectl describe deployment api

Puis le test qui compte : tuez un Pod.

kubectl delete pod -l app=api --field-selector=status.phase=Running
kubectl get pods -l app=api -w

Si le Deployment fait son travail, un nouveau Pod apparaît en quelques secondes. C’est la différence entre « ça tourne » et « ça se répare ».

Ce qu’il faut retenir

Un Deployment n’est pas « un Pod avec des options ». C’est le contrat entre vous et le cluster : voici combien d’instances, voici l’image, voici comment savoir qu’elles sont prêtes. Tant que ce contrat n’est pas écrit, vous administrez des processus. Dès qu’il l’est, vous déclarez un service.

Il lui manque encore deux choses pour être utilisable : une adresse par laquelle on le joint, et ses réglages. C’est le rôle du Service et du ConfigMap. Si la répartition des rôles entre Docker et Kubernetes est encore floue, la vue d’ensemble la reprend depuis le début.

Vient ensuite la deuxième vie d’un Deployment : le mettre à jour. Le remplacement progressif des Pods a une conséquence qu’on découvre souvent trop tard — pendant un rolling update, l’ancienne et la nouvelle version tournent en même temps, et la base doit convenir aux deux.