Deployments Kubernetes : déployer et mettre à jour vos applications

Un Deployment Kubernetes gère le déploiement et les mises à jour de vos applications. Il crée automatiquement les Pods, assure leur disponibilité et permet de mettre à jour ou revenir en arrière sans interruption de service. Ce guide vous montre comment créer des Deployments, maîtriser les rolling updates et configurer les paramètres essentiels en production.

Prérequis : un cluster Kubernetes fonctionnel avec kubectl configuré.

Ce que vous allez apprendre

• Créer un Deployment avec kubectl et YAML
• Mettre à jour une application sans interruption (rolling update)
• Revenir en arrière en cas de problème (rollback)
• Configurer les paramètres de production (maxSurge, progressDeadlineSeconds...)
• Choisir entre RollingUpdate et Recreate

Ce qu'est un Deployment

Un Deployment est une ressource Kubernetes qui gère un ensemble de Pods identiques. Il garantit que le nombre de Pods voulus est toujours en cours d'exécution et orchestre les mises à jour de version.

Pour un débutant, retenez :

• Le Deployment crée et surveille vos Pods automatiquement
• Si un Pod tombe, le Deployment en recrée un
• Pour une mise à jour, le Deployment remplace progressivement les anciens Pods

Pourquoi utiliser des Deployments

Créer des Pods manuellement pose plusieurs problèmes :

• Pas de redémarrage automatique si un Pod crash
• Mises à jour manuelles, risquées et longues
• Pas de rollback facile en cas de problème

Les Deployments résolvent ces problèmes :

Fonctionnalité	Description
Auto-healing	Maintient l'état souhaité via un ReplicaSet, qui recrée les Pods manquants
Rolling Update	Mise à jour sans interruption
Rollback	Retour à une version précédente en une commande
Scaling	Ajustement du nombre de Pods à la demande

Glissez pour voir

Une limite à connaître dès maintenant : le Deployment est conçu pour des applications sans état. Ses Pods sont interchangeables, il les nomme au hasard et les remplace dans n'importe quel ordre. Une base de données ou une file de messages a besoin de l'inverse, une identité et un disque stables : c'est le rôle du StatefulSet.

Créer son premier Deployment

Comme pour les autres objets, deux chemins mènent au même résultat. La méthode impérative tient en une commande et sert à démarrer vite ou à produire un squelette. La méthode déclarative passe par un fichier YAML versionné, seule forme tenable dès qu'une équipe travaille sur le même cluster.

Méthode impérative : kubectl create

La façon la plus rapide de créer un Deployment :

kubectl create deployment nginx-demo \
  --image=nginx:1.29-alpine@sha256:5616878291a2eed594aee8db4dade5878cf7edcb475e59193904b198d9b830de \
  --replicas=3

Vérifiez sa création :

kubectl get deployment nginx-demo

Sortie

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx-demo   3/3     3            3           10s

Méthode déclarative : fichier YAML

Pour un contrôle total, créez un fichier manifest :

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.26@sha256:41b194461e4bae16f9b25d68b0976ed4735b89ca625c89aad88e1c1c3b7e8860
        ports:
        - containerPort: 80

Appliquez-le :

kubectl apply -f nginx-deployment.yaml

Deux blocs de ce manifeste doivent impérativement s'accorder : selector.matchLabels et template.metadata.labels. Le premier dit quels Pods le Deployment pilote, le second étiquette ceux qu'il crée. S'ils divergent, Kubernetes rejette le manifeste au lieu de créer un Deployment qui ne piloterait rien.

Observer et inspecter un Deployment

Trois commandes suffisent à savoir où en est un déploiement, et elles vont du général au précis : l'état d'ensemble, le détail de la stratégie, puis les Pods réellement créés.

kubectl get deployment : vue d'ensemble

C'est la première commande à lancer pour savoir si un déploiement va bien. La colonne à surveiller est READY : tant que le premier chiffre est inférieur au second (par exemple 0/3), aucun Pod n'est prêt à recevoir du trafic, souvent parce que l'image ne se télécharge pas. Le drapeau -o wide ajoute les colonnes IMAGES et SELECTOR, indispensables pour vérifier d'un coup d'oeil quelle version tourne réellement et quels Pods le Deployment pilote.

kubectl get deployment -o wide

Sortie

NAME         READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES       SELECTOR
nginx-demo   3/3     3            3           2m    nginx        nginx:1.26   app=nginx-demo

Colonne	Signification
READY	Pods prêts / Pods souhaités
UP-TO-DATE	Pods avec la dernière version du template
AVAILABLE	Pods accessibles aux utilisateurs

Glissez pour voir

kubectl describe : détails complets

C'est ici que se lisent les valeurs que vous n'avez pas écrites : Kubernetes remplit les champs manquants avec ses défauts, et describe les affiche tels qu'ils s'appliquent réellement.

kubectl describe deployment nginx-demo

Sortie (extrait)

Name:                   nginx-demo
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
RollingUpdateStrategy:  25% max unavailable, 25% max surge
NewReplicaSet:          nginx-demo-75984c689f (3/3 replicas created)

Les informations clés :

• StrategyType : RollingUpdate ou Recreate
• RollingUpdateStrategy : paramètres de mise à jour progressive
• NewReplicaSet : le ReplicaSet actif qui gère les Pods

Voir les Pods créés

kubectl get pods -l app=nginx-demo

Sortie

NAME                          READY   STATUS    RESTARTS   AGE
nginx-demo-75984c689f-6zw4w   1/1     Running   0          2m
nginx-demo-75984c689f-ln2zn   1/1     Running   0          2m
nginx-demo-75984c689f-wzs4s   1/1     Running   0          2m

Le nom du Pod suit le format <deployment>-<replicaset-hash>-<pod-hash>.

Anatomie d'un Deployment

Maintenant que vous avez vu un Deployment vivre, voici sa structure complète. La plupart de ces champs ont un défaut raisonnable : le manifeste minimal n'en porte que trois, replicas, selector et template. Les autres sont montrés ici parce qu'ils décident du comportement en production.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 3                    # Nombre de Pods souhaités
  revisionHistoryLimit: 5        # Nombre d'anciennes versions conservées
  progressDeadlineSeconds: 300   # Timeout pour une mise à jour
  minReadySeconds: 10            # Temps avant de considérer un Pod disponible
  strategy:
    type: RollingUpdate          # ou Recreate
    rollingUpdate:
      maxUnavailable: 1          # Pods indisponibles max pendant update
      maxSurge: 1                # Pods supplémentaires max pendant update
  selector:
    matchLabels:
      app: nginx-demo                 # Doit correspondre aux labels du template
  template:                      # Template des Pods créés
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.26@sha256:41b194461e4bae16f9b25d68b0976ed4735b89ca625c89aad88e1c1c3b7e8860

Les 5 champs de production à connaître

Champ	Par défaut	Description
replicas	1	Nombre de Pods souhaités
revisionHistoryLimit	10	Nombre de ReplicaSets conservés pour rollback
progressDeadlineSeconds	600	Secondes avant timeout d'une mise à jour
minReadySeconds	0	Temps minimal pendant lequel un Pod doit rester prêt avant d'être considéré disponible
maxUnavailable	25%	Pods indisponibles max pendant rolling update
maxSurge	25%	Pods supplémentaires max pendant rolling update

Glissez pour voir

Deux de ces champs méritent d'être écrits explicitement en production, plutôt que laissés au défaut. revisionHistoryLimit conserve dix anciens ReplicaSets, ce qui encombre le cluster sans servir : cinq suffisent pour revenir en arrière. Et progressDeadlineSeconds, fixé à dix minutes par défaut, doit refléter le temps de démarrage réel de votre application, sans quoi un déploiement bloqué met dix minutes à se signaler.

Déploiement sûr : ne négligez pas les probes

Un rolling update n'est réellement fiable que si Kubernetes sait quand un Pod est prêt à recevoir du trafic. En pratique, cela repose sur une readinessProbe correctement configurée. Sans elle, Kubernetes peut envoyer du trafic vers des Pods encore en phase d'initialisation.

Combinez avec minReadySeconds pour ajouter un délai de stabilité avant de considérer le Pod comme disponible.

Pour aller plus loin, consultez le guide sur les Probes Kubernetes.

Mettre à jour un Deployment (Rolling Update)

Un Deployment ne met à jour les Pods que si le template change (image, variables, resources...). Un scaling ne déclenche pas de rolling update.

Changer l'image

La commande set image modifie le champ image du template de Pod, ce qui suffit à déclencher un rolling update. La syntaxe attend <nom-du-conteneur>=<nouvelle-image> : ici nginx est le nom du conteneur dans le manifest, pas celui du Deployment. Une erreur sur ce nom fait échouer la commande sans rien modifier :

error: unable to find container named "mauvais-nom"

kubectl set image deployment/nginx-demo nginx=nginx:1.27

Suivre la mise à jour

rollout status bloque le terminal et affiche l'avancement du remplacement jusqu'à ce que tous les nouveaux Pods soient disponibles, ou jusqu'au dépassement de progressDeadlineSeconds. C'est la commande à mettre dans un script de déploiement : elle renvoie un code de sortie non nul si la mise à jour échoue, ce qui permet d'enchaîner un rollback automatique en CI.

kubectl rollout status deployment/nginx-demo

Sortie

Waiting for deployment "nginx-demo" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-demo" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-demo" successfully rolled out

Comment fonctionne le Rolling Update

Kubernetes crée un nouveau ReplicaSet et ajuste progressivement les replicas :

L'ancien ReplicaSet est conservé (avec 0 replicas) pour permettre un rollback.

Ce remplacement progressif ne prend tout son sens qu'avec un Service : pendant toute la mise à jour, le Service ne dirige le trafic que vers les Pods prêts, et jamais vers ceux qui démarrent encore.

Le Deployment ne crée jamais de Pod lui-même : il délègue à un ReplicaSet, qu'il crée à neuf à chaque changement de template. Vous n'interagissez pratiquement jamais avec eux, mais kubectl get rs les montre, et c'est là qu'on voit combien d'anciennes versions restent disponibles pour un rollback.

Rollback : revenir en arrière

Chaque changement de template crée une révision numérotée, et l'ancien ReplicaSet est conservé avec zéro Pod. Revenir en arrière consiste donc à le réactiver, ce qui se fait en une commande et sans interruption.

Voir l'historique des versions

kubectl rollout history deployment/nginx-demo

Sortie

deployment.apps/nginx-demo
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

Les trois révisions affichent <none> parce que rien n'a renseigné CHANGE-CAUSE. Un historique dans cet état dit qu'il y a eu trois changements, jamais lesquels.

Pour voir les détails d'une révision :

kubectl rollout history deployment/nginx-demo --revision=2

Revenir à la version précédente

Sans argument, rollout undo revient à la révision immédiatement précédente, ce qui est le geste réflexe quand une mise à jour vient de mal tourner. Le rollback est lui-même un rolling update : Kubernetes réactive l'ancien ReplicaSet (conservé avec 0 replica) et remonte progressivement ses Pods, sans interruption.

kubectl rollout undo deployment/nginx-demo

Revenir à une version spécifique

--to-revision vise un numéro précis de l'historique, ce qui sert quand la révision précédente était elle aussi mauvaise. Le numéro se lit dans rollout history.

kubectl rollout undo deployment/nginx-demo --to-revision=1

Documenter ses révisions, et le piège de l'annotation

Un historique de révisions sans CHANGE-CAUSE ne sert à rien : il dit qu'il y a eu un changement, jamais lequel. L'annotation kubernetes.io/change-cause remplit cette colonne.

kubectl annotate deployment/nginx-demo \
  kubernetes.io/change-cause="Passage en nginx 1.28" --overwrite

Historique après l'annotation

REVISION  CHANGE-CAUSE
1         <none>
2         Passage en nginx 1.28

Le piège tient en une phrase : cette annotation PERSISTE. Elle vit sur le Deployment, pas sur la révision. Le déploiement suivant la recopie telle quelle, et l'historique se met à mentir :

Après un passage en 1.29, sans retoucher l'annotation

REVISION  CHANGE-CAUSE
2         Passage en nginx 1.28
3         Passage en nginx 1.28

La révision 3 porte nginx 1.29 et affirme être un passage en 1.28. Un collègue qui lit cet historique pendant un incident sera induit en erreur.

La règle qui en découle : réécrire l'annotation à chaque déploiement, juste avant ou juste après, et jamais une seule fois. En pratique, cela se place dans le script de déploiement, à côté du set image.

Pause et Resume

Pour appliquer plusieurs modifications sans déclencher de rollout intermédiaire :

# Mettre en pause
kubectl rollout pause deployment/nginx-demo

# Appliquer plusieurs changements
kubectl set image deployment/nginx-demo nginx=nginx:1.28
kubectl set resources deployment/nginx-demo -c=nginx --limits=cpu=200m,memory=256Mi

# Reprendre (un seul rollout pour tous les changements)
kubectl rollout resume deployment/nginx-demo

Un Deployment en pause refuse le rollback

Tant que le Deployment est en pause, kubectl rollout undo échoue, avec ce message :

error: you cannot rollback a paused deployment; resume it first with 'kubectl rollout resume' and try again

Reprenez-le avant toute tentative de retour arrière.

Scaling : ajuster le nombre de Pods

kubectl scale deployment/nginx-demo --replicas=5

Le scaling est instantané et ne crée pas de nouvelle révision.

Pour un scaling automatique basé sur la charge :

kubectl autoscale deployment/nginx-demo --min=3 --max=10 --cpu=80%

Cela crée un HorizontalPodAutoscaler.

Stratégies de déploiement

Kubernetes n'en propose que deux, et le choix se résume à une question : vos deux versions peuvent-elles tourner en même temps ? Si oui, le remplacement progressif s'impose ; si non, il faut accepter une coupure.

RollingUpdate (par défaut)

Remplace progressivement les Pods sans interruption.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # ou "25%"
      maxSurge: 1         # ou "25%"

Paramètre	Effet
maxUnavailable: 0	Toujours au moins N replicas disponibles (plus lent)
maxSurge: 0	Jamais plus de N replicas (économise les ressources)
Les deux à 0	Refusé à l'application par l'API, voir le message ci-dessous

Glissez pour voir

Mettre les deux à zéro demanderait à Kubernetes de remplacer des Pods sans jamais en retirer ni en ajouter : la demande n'a pas de solution, et l'API la refuse explicitement.

The Deployment "demo" is invalid: spec.strategy.rollingUpdate.maxUnavailable:
Invalid value: 0: may not be 0 when `maxSurge` is 0

Cas d'usage : la majorité des applications web, APIs, microservices.

Recreate

Supprime tous les anciens Pods avant de créer les nouveaux. Provoque une interruption.

spec:
  strategy:
    type: Recreate

Cas d'usage :

• Application qui ne peut pas coexister en plusieurs versions (schéma de BDD incompatible)
• Environnements de dev/test où l'interruption n'est pas critique

Blue-Green et Canary

Pas natifs

Blue-Green et Canary ne sont pas des stratégies natives du Deployment. Ils nécessitent une gestion manuelle avec plusieurs Deployments et Services, ou un service mesh / Ingress controller avancé.

Blue-Green : deux Deployments (blue et green), on bascule le Service.

Canary : nouveau Deployment avec peu de replicas, on ajuste progressivement le trafic.

Ces patterns sont décrits en détail dans le guide Stratégies de déploiement avancées.

Deployment ou StatefulSet ?

Critère	Deployment	StatefulSet
Application	Stateless	Stateful
Identité des Pods	Aléatoire	Stable et ordonnée
Stockage	Éphémère (ou PVC partagé)	PVC persistant par Pod
Exemples	API, frontend, workers	Bases de données, Kafka, Elasticsearch

Glissez pour voir

Règle simple : si votre application stocke des données locales ou a besoin d'identités réseau stables, utilisez un StatefulSet.

Debug : diagnostiquer un Deployment

Un déploiement qui ne finit pas a presque toujours sa cause dans les Pods, pas dans le Deployment. La démarche consiste donc à descendre : constater le blocage au niveau du Deployment, puis chercher la raison au niveau du Pod.

Le rollout est bloqué

Symptôme : kubectl rollout status ne rend pas la main. C'est le comportement normal de la commande tant que le déploiement progresse ; elle devient un signal d'alerte quand rien ne bouge pendant plusieurs minutes.

# Vérifier les conditions
kubectl describe deployment nginx-demo | grep -A5 Conditions

# Voir les événements
kubectl get events --sort-by=.lastTimestamp

Causes fréquentes :

• Image introuvable (ImagePullBackOff)
• Ressources insuffisantes (Pending)
• Readiness probe qui échoue

Les Pods ne démarrent pas

Ces trois commandes s'enchaînent du général au précis. get pods donne le statut (ImagePullBackOff, CrashLoopBackOff, Pending), describe pod remonte les événements du planificateur et du kubelet, qui expliquent pourquoi le Pod est coincé, et logs montre la sortie du conteneur lui-même quand il démarre mais s'arrête aussitôt. Un ImagePullBackOff se diagnostique dans describe ; une erreur applicative se lit dans logs.

kubectl get pods -l app=nginx-demo
kubectl describe pod <nom-du-pod>
kubectl logs <nom-du-pod>

Timeout de mise à jour

Si progressDeadlineSeconds est dépassé, le Deployment passe en condition Progressing: False avec raison ProgressDeadlineExceeded.

kubectl describe deployment nginx-demo | grep ProgressDeadlineExceeded

Le déploiement n'est pas automatiquement rollback. Vous devez le faire manuellement :

kubectl rollout undo deployment/nginx-demo

Testez vos connaissances

Ce court quiz reprend les points qui posent le plus souvent problème en pratique : la différence entre RollingUpdate et Recreate, le rôle du ReplicaSet, et le comportement du retour arrière. Répondez sans revenir en arrière : ce qui bloque désigne précisément le passage à relire.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Un Deployment gère des Pods stateless avec auto-healing et rolling updates
2. RollingUpdate (défaut) remplace progressivement les Pods sans interruption
3. Recreate supprime tout avant de recréer (interruption de service)
4. maxUnavailable et maxSurge contrôlent la vitesse du rolling update
5. Rollback : kubectl rollout undo pour revenir en arrière
6. Pause/Resume : appliquer plusieurs changements en un seul rollout
7. L'ancien ReplicaSet est conservé, revisionHistoryLimit contrôle combien
8. Pour du stateful, utilisez StatefulSet, pas Deployment

FAQ : questions fréquentes sur les Deployments

Ces questions reviennent régulièrement quand on débute avec les Deployments Kubernetes. Les réponses ci-dessous synthétisent les points développés dans ce guide, différence avec un Pod, mise à jour, rollback, choix du nombre de replicas.

Quelle est la différence entre un Pod et un Deployment ?

Un Pod est une instance unique et éphémère de conteneurs. Un Deployment gère un ensemble de Pods identiques : il les recrée s'ils tombent et orchestre les mises à jour sans interruption de service.

Quelle est la différence entre un Deployment et un ReplicaSet ?

Un ReplicaSet maintient seulement un nombre fixe de Pods. Un Deployment pilote des ReplicaSets : chaque version d'image correspond à un ReplicaSet, ce qui lui permet d'assurer rolling updates et rollbacks.

Comment mettre à jour une application gérée par un Deployment ?

Modifiez l'image avec kubectl set image ou éditez le YAML puis kubectl apply. Kubernetes lance un rolling update qui remplace les Pods progressivement, sans coupure, selon maxSurge et maxUnavailable.

Comment revenir à la version précédente d'un Deployment ?

Utilisez kubectl rollout undo deployment/nom pour revenir à la révision précédente, ou ajoutez --to-revision=N pour cibler une version exacte. L'historique se consulte avec kubectl rollout history.

Deployment ou StatefulSet : lequel choisir ?

Choisissez un Deployment pour les applications sans état, dont les Pods sont interchangeables. Choisissez un StatefulSet pour les applications avec état qui ont besoin d'une identité stable et d'un stockage persistant.

Combien de replicas faut-il pour un Deployment en production ?

Prévoyez au moins deux ou trois replicas pour tolérer la perte d'un Pod ou d'un nœud. Ajustez ensuite selon la charge, et automatisez avec un HorizontalPodAutoscaler plutôt que de figer un nombre.

Pourquoi un rollout de Deployment reste-t-il bloqué ?

Un rollout bloqué dépasse le délai progressDeadlineSeconds : le plus souvent une image introuvable ou des probes qui échouent. Diagnostiquez avec kubectl rollout status et kubectl describe deployment.

Comment ajuster le nombre de Pods d'un Deployment ?

Pour un ajustement manuel, lancez kubectl scale deployment/nom --replicas=N. Pour un ajustement automatique selon la charge CPU ou mémoire, utilisez un HorizontalPodAutoscaler.

Mettre en pratique

Ce lab porte sur la vie d'un Deployment après sa première livraison. Il vous fait revenir sur la révision qui marchait puis livrer la bonne image, et la validation lit les ReplicaSets avec leurs numéros de révision : ils racontent ce qui s'est passé, là où un Deployment recréé de zéro ne raconte rien.

Lab pratique

Revenir en arrière sur un déploiement bloqué, puis livrer la bonne version

$ dsoxlab run cka-deployment-rollout-rollback

Environnement : VM·Durée : ~15 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run cka-deployment-rollout-rollback
dsoxlab check cka-deployment-rollout-rollback

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Décliner ce Deployment en plusieurs environnements sans le dupliquer relève de Kustomize, qui porte son propre lab.

La livraison complète d'une application, donnée comme un cahier des charges et non comme un mode d'emploi, est le capstone des exercices CKAD.

Pour aller plus loin

• Les Services : L'adresse stable qui rend joignables les Pods créés par votre Deployment.
• Rolling Updates et Rollbacks : Le détail des paramètres maxSurge et maxUnavailable pendant une mise à jour.
• Les StatefulSets : Le contrôleur à choisir quand vos Pods ont besoin d'une identité et d'un disque stables.
• Horizontal Pod Autoscaler : L'ajustement automatique du nombre de réplicas selon la charge mesurée.

×

📖 Voir la documentation →