Contactez-nous

Deployments : Déploiement et mise à jour d'applications stateless

Apprenez à utiliser l'objet Deployment Kubernetes pour déployer, mettre à jour (rolling updates) et scaler vos applications stateless de manière fiable.

Le couteau suisse des applications stateless : le Deployment

Parmi les différents contrôleurs de Workloads, le Deployment est sans doute le plus fondamental et le plus fréquemment utilisé. Il constitue la méthode standard et recommandée pour exécuter des applications stateless (sans état local persistant qui doive survivre au redémarrage du Pod) sur Kubernetes. Pensez aux serveurs web, aux API REST, aux workers de traitement qui lisent dans une file d'attente, etc.

Un Deployment fournit une manière déclarative de gérer à la fois les Pods de votre application et les ReplicaSets sous-jacents qui garantissent leur nombre. Au lieu de gérer directement les ReplicaSets (qui eux-mêmes gèrent les Pods), vous interagissez principalement avec l'objet Deployment. Celui-ci orchestre la création, la mise à jour et la suppression des ReplicaSets et des Pods de manière contrôlée et automatisée.

L'objectif principal d'un Deployment est de s'assurer que le nombre désiré de Pods (basés sur un template que vous fournissez) est en cours d'exécution et disponible, et de faciliter les mises à jour de ces Pods vers de nouvelles versions de manière fluide et, idéalement, sans interruption de service.

Fonctionnalités clés des Deployments

Les Deployments offrent plusieurs fonctionnalités essentielles :

  • Création et gestion de réplicas : Vous spécifiez le nombre d'instances (`replicas`) de votre application que vous souhaitez, et le Deployment (via un ReplicaSet) s'assure que ce nombre est maintenu.
  • Mises à jour déclaratives (Rolling Updates) : Vous pouvez mettre à jour l'image du conteneur, les variables d'environnement, ou d'autres aspects du template de Pod. Le Deployment gère le processus de remplacement progressif des anciens Pods par les nouveaux, minimisant voire éliminant les temps d'arrêt.
  • Rollbacks faciles : Si une nouvelle version pose problème, le Deployment conserve l'historique des déploiements (via les anciens ReplicaSets) et vous permet de revenir rapidement et facilement à une version précédente stable.
  • Scaling : Vous pouvez augmenter ou diminuer le nombre de réplicas de votre application à la volée, manuellement ou automatiquement (via le Horizontal Pod Autoscaler, que nous verrons plus tard).
  • Pause et reprise : Vous pouvez mettre en pause un déploiement en cours pour effectuer plusieurs modifications au template, puis le reprendre pour appliquer tous les changements en une seule fois.
  • Auto-réparation : Héritée du ReplicaSet, si un Pod géré par le Deployment échoue ou disparaît, il est automatiquement remplacé.

Structure d'un manifeste de Deployment

Voici un exemple de fichier YAML pour un Deployment simple :

apiVersion: apps/v1 # API group pour Deployments
kind: Deployment
metadata:
  name: mon-app-deployment
  labels:
    app: mon-app
spec:
  replicas: 3         # Nombre désiré de Pods
  selector:           # Comment le Deployment trouve les Pods à gérer
    matchLabels:
      app: mon-app    # Doit correspondre aux labels du template
  template:           # Le template utilisé pour créer les Pods
    metadata:
      labels:         # Labels appliqués aux Pods créés
        app: mon-app
    spec:             # Spécification des Pods (conteneurs, volumes, etc.)
      containers:
      - name: mon-app-conteneur
        image: mon-image-app:v1.0
        ports:
        - containerPort: 8080
  strategy:
    type: RollingUpdate # Stratégie de mise à jour (par défaut)
    rollingUpdate:
      maxUnavailable: 25% # Max Pods indisponibles pendant la MàJ
      maxSurge: 25%       # Max Pods supplémentaires créés pendant la MàJ
  minReadySeconds: 5        # Temps min pour considérer un Pod prêt
  revisionHistoryLimit: 10  # Nombre d'anciens ReplicaSets à garder

Analysons les champs importants sous `spec` :

  • `replicas` : Le nombre exact de Pods que le Deployment doit essayer de maintenir en cours d'exécution et prêts.
  • `selector` (obligatoire) : Définit comment le Deployment identifie les Pods qu'il doit gérer. Le champ `matchLabels` est le plus courant et spécifie un ensemble de labels que les Pods doivent posséder. Crucial : ce sélecteur doit correspondre aux labels définis dans `spec.template.metadata.labels`, sinon le Deployment ne pourra pas gérer ses Pods.
  • `template` (obligatoire) : Contient la spécification du Pod (`metadata` et `spec`) que le Deployment utilisera pour créer de nouveaux Pods. Au minimum, `template.metadata.labels` doit être défini et correspondre au `spec.selector`. La partie `template.spec` contient la définition des conteneurs, volumes, etc., comme dans un manifeste de Pod standard.
  • `strategy` : Définit comment les anciens Pods sont remplacés par les nouveaux lors d'une mise à jour du `template`. Les options sont :
    • `RollingUpdate` (par défaut) : Met à jour les Pods progressivement. Des paramètres comme `maxUnavailable` (nombre ou pourcentage maximum de Pods qui peuvent être indisponibles pendant la mise à jour) et `maxSurge` (nombre ou pourcentage maximum de Pods qui peuvent être créés au-delà du nombre désiré de `replicas` pendant la mise à jour) permettent de contrôler finement le processus.
    • `Recreate` : Supprime tous les anciens Pods avant de créer les nouveaux. Entraîne une interruption de service mais peut être utile dans certains scénarios (par exemple, si l'application ne supporte pas d'avoir plusieurs versions actives en même temps).
  • `minReadySeconds` (optionnel) : Nombre de secondes pendant lesquelles un Pod nouvellement créé doit être prêt (passer ses readiness probes) sans aucun de ses conteneurs ne crashe, pour être considéré comme disponible. Utile pour ralentir le déploiement si les nouvelles instances mettent du temps à démarrer complètement.
  • `revisionHistoryLimit` (optionnel) : Nombre d'anciens ReplicaSets (correspondant aux révisions précédentes du Deployment) à conserver. Ces ReplicaSets sont nécessaires pour pouvoir effectuer des rollbacks. La valeur par défaut est 10. Mettre à 0 désactive la conservation de l'historique (et donc les rollbacks faciles).

Relation entre Deployment et ReplicaSet

Il est important de comprendre que le Deployment ne gère pas directement les Pods. Il délègue cette tâche aux ReplicaSets.

  1. Lorsque vous créez un Deployment, celui-ci crée un ReplicaSet basé sur le `template` actuel.
  2. Le ReplicaSet est alors responsable de créer et de maintenir le nombre désiré de Pods (`replicas`) correspondant à ce template.
  3. Lorsque vous mettez à jour le `template` dans le Deployment (par exemple, en changeant la version de l'image), le Deployment crée un nouveau ReplicaSet avec le nouveau template.
  4. Le Deployment orchestre ensuite la transition : il augmente progressivement le nombre de réplicas du nouveau ReplicaSet tout en diminuant celui de l'ancien ReplicaSet, en respectant la `strategy` définie (`RollingUpdate` ou `Recreate`).
  5. Une fois la mise à jour terminée, l'ancien ReplicaSet a généralement 0 réplicas (mais est conservé pour l'historique, selon `revisionHistoryLimit`), et le nouveau ReplicaSet gère tous les Pods actifs.

Vous pouvez voir les ReplicaSets gérés par un Deployment avec `kubectl get rs` et observer leurs relations avec `kubectl describe deployment mon-app-deployment`.

Gérer les Deployments avec `kubectl`

Voici les commandes essentielles :

  • Créer ou Mettre à Jour : `kubectl apply -f mon-deployment.yaml`
  • Lister les Deployments : `kubectl get deployments` (ou `kubectl get deploy`)
  • Inspecter un Deployment : `kubectl describe deployment mon-app-deployment` (affiche l'état, la stratégie, les événements, les ReplicaSets associés, etc.)
  • Vérifier l'état d'un déploiement en cours : `kubectl rollout status deployment/mon-app-deployment` (très utile pour suivre la progression d'une mise à jour).
  • Voir l'historique des révisions : `kubectl rollout history deployment/mon-app-deployment`
  • Inspecter une révision spécifique : `kubectl rollout history deployment/mon-app-deployment --revision=2`
  • Revenir à une version précédente : `kubectl rollout undo deployment/mon-app-deployment` (revient à la révision précédente). Vous pouvez revenir à une révision spécifique avec `--to-revision=N`.
  • Scaler un Deployment : `kubectl scale deployment mon-app-deployment --replicas=5`
  • Supprimer un Deployment : `kubectl delete deployment mon-app-deployment` (cela supprimera aussi les ReplicaSets et les Pods associés).

Conclusion : la fondation des applications modernes sur K8s

Le Deployment est l'un des objets les plus importants et les plus utilisés dans Kubernetes pour gérer les applications stateless. En fournissant une méthode déclarative pour gérer les réplicas, les mises à jour et les rollbacks, il simplifie considérablement le cycle de vie des applications conteneurisées.

Maîtriser la création et la gestion des Deployments est une compétence fondamentale pour tout utilisateur de Kubernetes souhaitant déployer des applications de manière fiable, scalable et facile à maintenir. C'est la base sur laquelle nous construirons pour exposer ces applications au monde extérieur dans le chapitre suivant.