IT Toolbox AI
Kubernetes · Deployments

Deployments

Déployez, mettez à jour, redimensionnez et restaurez une application stateless de manière déclarative.

Leçon disponible
20 min

Objectifs

  • Relier Deployment, ReplicaSet et Pods.
  • Comprendre replicas, état désiré et self-healing.
  • Suivre une rolling update et consulter son historique.
  • Effectuer un rollback ou un changement d’échelle contrôlé.

Gérer les applications avec des Deployments

Un Deployment gère un ensemble de Pods interchangeables, généralement pour une application stateless. Il déclare un template et un nombre de replicas que ses contrôleurs cherchent continuellement à maintenir.

Le Deployment crée et pilote des ReplicaSets. Chaque ReplicaSet assure à son tour l’existence du nombre attendu de Pods pour une version donnée du template.

Deployment → ReplicaSet → Pods

Le Deployment orchestre les versions et mises à jour. Un ReplicaSet correspond à une révision du template et maintient ses Pods. Si un Pod disparaît, le ReplicaSet en crée un autre pour restaurer l’état désiré.

Relation entre les ressources
Deployment → ReplicaSet → Pods

Manifeste d’un Deployment nginx

Le selector du Deployment doit correspondre aux labels du template. Le tag explicite améliore la reproductibilité par rapport à latest, même si une stratégie de mise à jour des images reste nécessaire.

deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
Appliquer et observer les ressources créées
kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get replicasets
kubectl get pods

Rolling update et rollback

Lorsqu’un template change, le Deployment crée progressivement un nouveau ReplicaSet et réduit l’ancien selon sa stratégie. rollout status suit l’opération, history liste les révisions et undo demande un retour à une révision antérieure.

Suivre et restaurer un rollout
kubectl rollout status deployment/nginx
kubectl rollout history deployment/nginx
kubectl rollout undo deployment/nginx

Un rollback restaure le template Kubernetes d’une révision, mais ne restaure pas automatiquement une base de données ou une dépendance externe.

Changer le nombre de replicas

scale modifie le nombre désiré de Pods. Cette commande impérative est utile ponctuellement, mais un manifeste ou un outil GitOps peut ensuite réappliquer une autre valeur déclarée.

Passer temporairement à cinq replicas
kubectl scale deployment nginx --replicas=5

Bonnes pratiques

Versionnez les manifests, utilisez des tags ou digests maîtrisés, configurez readiness probes et ressources, puis observez le rollout avant de considérer le déploiement terminé.

  • Ne pas modifier directement les Pods gérés : changez le template du Deployment.
  • Conserver un historique exploitable et documenter les changements.
  • Tester la compatibilité applicative avant un rollback de production.

Mini résumé

  • Un Deployment pilote des ReplicaSets qui maintiennent les Pods.
  • L’état désiré permet le remplacement automatique des Pods perdus.
  • Les rolling updates changent progressivement le template exécuté.
  • rollout et scale permettent de suivre, restaurer et dimensionner le workload.

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Quel objet maintient concrètement le nombre de Pods d’une révision ?
2. Un Pod géré disparaît alors que replicas vaut 3. Que se passe-t-il normalement ?
3. Que restaure kubectl rollout undo deployment/nginx ?