Les Pods sont jetables, et un Pod isolé qui meurt reste mort. Un Deployment résout ce problème : vous déclarez combien de copies vous voulez et quelle image exécuter, et Kubernetes maintient ce nombre en fonctionnement et gère les mises à jour à votre place. Ce guide couvre la création d’un Deployment, sa mise à l’échelle, sa mise à jour sans interruption et son retour en arrière.

Pourquoi on crée rarement des Pods isolés

Si un nœud tombe en panne ou si un Pod est supprimé, rien ne recrée un Pod autonome. En pratique, on ne crée presque jamais de Pods directement. On crée un Deployment, qui crée un ReplicaSet, qui à son tour crée et maintient les Pods. Le Deployment apporte ce qui manque au ReplicaSet : des mises à jour contrôlées et un historique des versions.

Écrire un Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

Il y a deux sections metadata, et il est utile de bien les distinguer. Celle du haut décrit le Deployment. Celle située sous template décrit les Pods qu’il crée, et le template n’est autre qu’un manifeste de Pod sans nom. Le selector indique au Deployment quels Pods lui appartiennent ; il doit donc correspondre aux labels du template, sinon Kubernetes rejettera le manifeste.

kubectl apply -f deployment.yaml
kubectl get deployment,replicaset,pods

Vous verrez un Deployment, un ReplicaSet portant son nom suivi d’un hash, et trois Pods portant le nom du ReplicaSet.

Labels et sélecteurs : comment les objets se trouvent

Les labels sont des paires clé-valeur que vous pouvez attacher à n’importe quel objet. Les sélecteurs les interrogent, et c’est ainsi que Kubernetes relie les choses : un Deployment trouve ses Pods, un Service trouve ses backends, et une network policy trouve les Pods qu’elle régit.

kubectl get pods --show-labels
kubectl get pods -l app=web

Pour mesurer l’importance d’un sélecteur, retirez le label d’un Pod :

kubectl label pod POD_NAME app-
kubectl get pods --show-labels

Le ReplicaSet ne considère plus ce Pod comme le sien et en démarre donc un de remplacement pour revenir à trois. Le Pod dont on a retiré le label continue de tourner, mais plus rien ne le gère. Supprimez-le avec kubectl delete pod POD_NAME pour qu’il ne traîne pas.

Mettre à l’échelle et observer l’auto-réparation

kubectl scale deployment web --replicas=5
kubectl get pods -w

Dans un autre terminal, supprimez un Pod et regardez un remplaçant apparaître en quelques instants. Pour modifier durablement le nombre de réplicas, éditez replicas dans le manifeste et réappliquez-le, car kubectl scale seul laisse votre fichier obsolète. Vous ne pouvez pas vous débarrasser des Pods d’un Deployment en les supprimant, puisqu’ils reviennent toujours. Supprimez le Deployment lui-même, ou ramenez-le à zéro réplica.

Déployer une nouvelle version

Modifier quoi que ce soit dans le template du Pod, comme l’image, déclenche une mise à jour progressive :

kubectl set image deployment/web nginx=nginx:1.26
kubectl rollout status deployment/web

Le Deployment crée un second ReplicaSet pour la nouvelle version, puis le monte progressivement en charge tout en réduisant l’ancien, de sorte que des Pods servent toujours le trafic. Par défaut, il autorise jusqu’à 25 % de Pods supplémentaires (maxSurge) et jusqu’à 25 % d’indisponibles (maxUnavailable) pendant le changement. Vous pouvez ajuster cela dans la spec :

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Avec maxUnavailable: 0, un ancien Pod n’est retiré qu’une fois qu’un nouveau est prêt. Ce que signifie « prêt » est déterminé par les readiness probes, abordées dans un prochain guide. Modifier le nombre de réplicas n’est pas un déploiement, car cela ne touche pas au template du Pod.

Revenir en arrière

Kubernetes conserve les anciens ReplicaSets, ce qui rend le retour en arrière rapide :

kubectl rollout history deployment/web
kubectl rollout undo deployment/web
kubectl rollout undo deployment/web --to-revision=1

undo revient à la révision précédente, et --to-revision en choisit une précise. Le nombre d’anciennes révisions conservées est défini par revisionHistoryLimit, 10 par défaut. Une précaution : si vos manifestes vivent dans Git et qu’un outil comme Argo CD les applique, préférez annuler le commit plutôt que rollout undo. L’annulation modifie le cluster mais pas Git, et les deux divergent donc jusqu’à ce que quelqu’un les réconcilie.