Rôle du Déploiement : maintenir l'état désiré (nombre de réplicas)

Le défi de la permanence dans un monde éphémère

Nous avons établi que les Pods sont les unités d'exécution fondamentales dans Kubernetes, mais qu'ils sont intrinsèquement éphémères. Un Pod peut s'arrêter pour diverses raisons : une erreur applicative, un problème sur le Noeud hôte, ou même une suppression manuelle. Si votre application repose sur un unique Pod créé manuellement (comme avec `kubectl run --restart=Never`), toute interruption de ce Pod entraîne une interruption de service. Pour des applications nécessitant une disponibilité continue, cette approche est inacceptable.

De plus, comment garantir qu'un certain niveau de performance est maintenu ? Souvent, une seule instance d'une application ne suffit pas à gérer la charge. Il faut pouvoir exécuter plusieurs copies identiques, ou réplicas, de votre Pod pour répartir le trafic et assurer la redondance. Gérer manuellement la création, la surveillance et le remplacement de multiples Pods serait fastidieux et source d'erreurs.

C'est précisément ici que le Déploiement (Deployment) démontre sa valeur fondamentale. Son rôle premier est d'agir comme un gestionnaire vigilant, s'assurant qu'un nombre spécifique de Pods identiques, que vous définissez, sont toujours en cours d'exécution et disponibles dans le cluster.

Le principe déclaratif : spécifier l'état désiré

Le Déploiement incarne parfaitement l'approche déclarative de Kubernetes. Au lieu de donner des instructions impératives étape par étape ("crée un Pod", "vérifie s'il tourne", "si non, recrée-le"), vous décrivez l'état final désiré dans un manifeste YAML. Concernant la réplication, la partie cruciale de cette déclaration est le champ `replicas`.

Dans la spécification (`spec`) d'un Déploiement, vous indiquez simplement combien de copies de votre Pod vous souhaitez exécuter. Par exemple :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app-deployment
spec:
  replicas: 3  # <-- Etat désiré : je veux 3 Pods identiques
  selector:
    matchLabels:
      app: mon-app
  template: # <-- Modèle pour créer les Pods
    metadata:
      labels:
        app: mon-app
    spec:
      containers:
      - name: mon-conteneur
        image: mon-image:latest
        ports:
        - containerPort: 8080

Une fois ce manifeste appliqué, le contrôleur de Déploiement de Kubernetes entre en jeu. Sa mission est de s'assurer en permanence que l'état actuel du système (le nombre de Pods correspondant au sélecteur `app: mon-app`) correspond à l'état désiré (`replicas: 3`).

Auto-réparation et maintien du nombre de réplicas

Le véritable pouvoir du Déploiement réside dans sa capacité d'auto-réparation (self-healing). Le contrôleur surveille constamment les Pods qu'il est censé gérer (ceux correspondant au `selector`). Imaginons que l'un des trois Pods `mon-app` tombe en panne ou soit supprimé accidentellement.

Le contrôleur de Déploiement détecte immédiatement cette divergence : l'état actuel (2 Pods) ne correspond plus à l'état désiré (3 Pods). Pour corriger la situation, il utilise le `template` de Pod défini dans le manifeste pour créer automatiquement un nouveau Pod. Ce nouveau Pod sera programmé sur un Noeud disponible, l'image sera téléchargée si nécessaire, et le conteneur sera démarré. L'état désiré de 3 réplicas est ainsi restauré sans intervention manuelle.

Ce mécanisme fonctionne également si un Noeud entier devient indisponible. Les Pods gérés par le Déploiement qui s'exécutaient sur ce Noeud seront marqués comme non fonctionnels, et le contrôleur créera de nouveaux Pods sur d'autres Noeuds sains pour compenser la perte et maintenir le nombre de `replicas` défini.

Cette gestion automatique des réplicas est essentielle pour construire des applications robustes et hautement disponibles sur Kubernetes. Elle vous libère de la surveillance constante et des interventions manuelles en cas d'incident, permettant à votre application de résister aux pannes courantes.

Faciliter la mise à l'échelle (Scaling)

Le même mécanisme qui assure l'auto-réparation facilite également la mise à l'échelle (scaling) de votre application. Si vous constatez que 3 réplicas ne suffisent plus à gérer la charge, il vous suffit de modifier la valeur du champ `replicas` dans votre manifeste de Déploiement (par exemple, passer à 5) et de réappliquer le manifeste avec `kubectl apply`.

Le contrôleur de Déploiement détectera ce changement dans l'état désiré. Constatant qu'il n'y a que 3 Pods alors que 5 sont maintenant requis, il créera automatiquement 2 nouveaux Pods basés sur le template.

Inversement, si vous souhaitez réduire le nombre de réplicas (par exemple, passer de 5 à 2 pour économiser des ressources pendant les heures creuses), vous modifiez à nouveau le champ `replicas` et appliquez le changement. Le contrôleur identifiera les Pods excédentaires (3 dans ce cas) et les terminera proprement pour atteindre le nouvel état désiré de 2 réplicas.

Cette capacité à ajuster facilement et automatiquement le nombre d'instances en cours d'exécution est un autre avantage fondamental des Déploiements pour adapter la capacité de votre application aux besoins fluctuants.