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

Analogie

Le Deployment est comme un chef d’équipe : il s’assure que le bon nombre de personnes travaille, les remplace si quelqu’un est absent, et gère les transitions quand l’équipe change.

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

Deployment = Stateless

Un Deployment est conçu pour des applications stateless (sans état). Pour des applications avec état (bases de données, files de messages), utilisez un StatefulSet.

Créer son premier Deployment

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.24 --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
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24
        ports:
        - containerPort: 80

Appliquez-le :

kubectl apply -f nginx-deployment.yaml

Selector et labels

Le selector.matchLabels doit correspondre aux template.metadata.labels. Si ce n’est pas le cas, Kubernetes rejette le manifest.

Observer et inspecter un Deployment

kubectl get deployment : vue d’ensemble

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.24   app=nginx

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

kubectl describe deployment nginx-demo

Sortie (extrait)

Name:                   nginx-demo
Replicas:               3 desired | 3 updated | 3 total | 3 available
StrategyType:           RollingUpdate
RollingUpdateStrategy:  25% max unavailable, 25% max surge
NewReplicaSet:          nginx-demo-64dd99d679 (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

Sortie

NAME                          READY   STATUS    RESTARTS   AGE
nginx-demo-64dd99d679-8tnt5   1/1     Running   0          2m
nginx-demo-64dd99d679-lrcnc   1/1     Running   0          2m
nginx-demo-64dd99d679-psz2g   1/1     Running   0          2m

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

Anatomie d’un Deployment

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                 # Doit correspondre aux labels du template
  template:                      # Template des Pods créés
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24

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

Conseil production

En production, définissez explicitement revisionHistoryLimit (5-10 suffit) et progressDeadlineSeconds selon la durée de démarrage de votre application.

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

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

Suivre la mise à jour

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.

En pratique, ce remplacement progressif fonctionne bien avec un Service Kubernetes, qui continue à diriger le trafic uniquement vers les Pods prêts pendant la mise à jour.

ReplicaSets

Le Deployment délègue la gestion des Pods à des ReplicaSets. Vous n’interagissez pas directement avec eux, mais ils sont visibles avec kubectl get rs.

Rollback : revenir en arrière

Voir l’historique des versions

kubectl rollout history deployment/nginx-demo

Sortie

REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

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

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

Revenir à la version précédente

kubectl rollout undo deployment/nginx-demo

Revenir à une version spécifique

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

Annoter les changements

Ajoutez une annotation pour documenter les changements :

kubectl annotate deployment/nginx-demo kubernetes.io/change-cause="Upgrade to nginx 1.25"

Cette annotation apparaîtra dans CHANGE-CAUSE de l’historique.

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.26
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

Rollback impossible

Vous ne pouvez pas rollback un Deployment en pause. Resumez-le d’abord.

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-percent=80

Cela crée un HorizontalPodAutoscaler.

Stratégies de déploiement

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	Interdit — un des deux doit être > 0

Glissez pour voir

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

Le rollout est bloqué

Symptôme : kubectl rollout status reste en attente.

# 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

kubectl get pods -l app=nginx
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

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

Prochaines étapes

ReplicaSets Comprendre le mécanisme sous-jacent qui gère les Pods

StatefulSets Déployer des applications avec état (bases de données)

HPA Scaling automatique basé sur les métriques

×

📖 Voir la documentation →