Une application fonctionne. Puis arrive une mise à jour, un serveur tombe en panne ou plusieurs services ont besoin de plus de capacité en même temps. Kubernetes organise l’emplacement des conteneurs et le rétablissement de l’état de fonctionnement convenu. La fiabilité de l’application dépend de l’architecture dans son ensemble.
Prenons un portail interne de commandes : les employés saisissent les commandes, une interface les transmet au système de gestion des stocks et un traitement en arrière-plan crée les documents. Des conteneurs distincts peuvent assurer ces tâches. Les démarrer individuellement impose aussi de coordonner les mises à jour, les redémarrages et leur placement sur les machines. C’est le rôle de l’orchestration.
L’état souhaité devient la base de l’exploitation
Dans Kubernetes, on peut par exemple demander que deux instances d’une application web exécutent une version précise du logiciel. La plateforme compare en permanence cet état souhaité à l’état réel. Un Deployment décrit le déploiement de l’application et utilise un contrôleur ReplicaSet pour gérer ses Pods. Si une instance manque, le système de contrôle tente de la remplacer.
Cela sert aussi aux mises à jour : une nouvelle version peut être déployée progressivement. Les ressources, le comportement au démarrage et la stratégie de mise à jour doivent le permettre. Un déploiement techniquement réussi ne prouve pas qu’une commande a été traitée correctement. Cette vérification reste du ressort de l’application et de ses tests.
Les termes essentiels à travers le portail de commandes
- Image de conteneur
- La base empaquetée d’une application, avec les fichiers et les composants d’exécution nécessaires. Les conteneurs exécutables sont démarrés à partir de cette image.
- Pod
- La plus petite unité déployable dans Kubernetes. Elle contient généralement un conteneur applicatif ; des conteneurs étroitement liés peuvent partager un Pod et notamment son espace réseau. Deux copies de l’application web correspondent normalement à deux Pods.
- Nœud
- Une machine qui exécute des Pods. Un nœud peut être une machine virtuelle ou un serveur physique. Kubernetes peut donc compléter une couche de virtualisation sans nécessairement la remplacer.
- Cluster et plan de contrôle
- Le cluster associe le système de contrôle aux nœuds qui exécutent les charges de travail. Le plan de contrôle comprend le serveur API, la base de données d’état, l’ordonnanceur et les contrôleurs. Sur les nœuds, le kubelet et le moteur de conteneurs assurent l’exécution.
- Service
- Un point d’accès logique stable pour un groupe de Pods. Leurs adresses peuvent changer lorsqu’ils sont remplacés. Le Service dissocie l’accès des instances individuelles de courte durée.
Ce qui se passe réellement en cas de panne
Si un nœud tombe en panne, les Pods gérés peuvent être redéployés sur d’autres nœuds adaptés. Cela exige la détection de la panne, une capacité de réserve suffisante et l’accès aux données nécessaires. Une deuxième instance sur le même hôte physique ne protège pas contre la panne de cet hôte. Plusieurs serveurs dans le même domaine électrique ou réseau peuvent aussi partager un point de défaillance.
Pour notre portail, l’interface web peut ainsi être remplacée rapidement. En revanche, un traitement documentaire déjà lancé doit être conçu pour qu’une répétition ne crée pas de facture ou de commande en double. Le remplacement d’une instance ne doit pas entraîner une perte incontrôlée des sessions. Ces propriétés dépendent de l’architecture logicielle et des systèmes connectés.
Trois serveurs ne constituent donc pas à eux seuls un plan de disponibilité. Contrôle, applications, réseau, stockage et capacité restante après une panne doivent être considérés ensemble. Il en va de même dans le cloud ou avec un service Kubernetes managé : le périmètre réel du service détermine les responsabilités du fournisseur et celles qui restent à l’entreprise.
Les données persistantes nécessitent leur propre plan
Les Pods sont remplaçables. Les données métier ne doivent donc pas exister uniquement dans le système de fichiers inscriptible d’un conteneur. Kubernetes peut connecter du stockage persistant au moyen de Persistent Volumes et des demandes associées, les Persistent Volume Claims. Une StorageClass décrit comment fournir un stockage adapté.
Ces objets ne rendent pas automatiquement le stockage sous-jacent résilient. Un disque local reste lié à son infrastructure ; un service de stockage externe a ses propres caractéristiques de performance et de panne. Une base de données hors du cluster peut aussi être pertinente. La prise en charge de l’application, la cohérence des données, les chemins d’accès et la procédure de reprise convenue sont déterminants.
Pour le portail, nous définissons donc séparément la durée d’indisponibilité acceptable, la perte de données admissible et le test de restauration. Un cluster qui propage fidèlement une suppression accidentelle à toutes les instances ne remplace pas une sauvegarde. Pour en savoir plus : sauvegarde et restauration.
Quand l’effort supplémentaire se justifie
Kubernetes devient intéressant lorsque plusieurs applications sont mises à jour régulièrement, que les déploiements doivent être reproductibles ou que les charges et les machines disponibles doivent être réparties délibérément. Il crée aussi des tâches de mise à jour de la plateforme, de gestion des accès, de réseau, de stockage et de supervision.
Pour une application unique et stable, un serveur correctement maintenu avec Docker Compose ou une machine virtuelle classique peut être plus économique. La décision doit partir du fonctionnement attendu : quelles interruptions sont acceptables ? À quelle fréquence les changements surviennent-ils ? Qui comprend l’environnement et peut le rétablir en cas de problème ?
Un pilote utile a des objectifs vérifiables
- Tester un processus métier représentatif avec des volumes réalistes et sans données clients de production.
- Répéter une mise à jour avec le retour arrière prévu. Évaluer séparément les changements de schéma de base de données.
- Tester de manière contrôlée la perte d’une instance et d’un composant d’infrastructure prévu.
- Restaurer une sauvegarde dans un environnement de test distinct et l’ouvrir pour vérifier que les données métier sont utilisables.
- Nommer les responsables des alertes, de la maintenance de la plateforme et de l’application.
DAXS aide à évaluer l’application, à choisir une infrastructure adaptée et à assurer la mise en œuvre ainsi que l’exploitation convenue. Une première évaluation avec un cas d’usage concret et des critères d’acceptation clairs constitue un point de départ pratique.
Sources : Kubernetes : rôle et limites de la plateforme · Composants du cluster · Pods et cycle de vie · Deployments et mises à jour · Services · Stockage persistant · Planification des environnements de production
