Déployer un seul conteneur est simple. En déployer dix est gérable. Mais une fois que vous gérez des centaines de conteneurs sur des dizaines de machines, la gestion manuelle cesse d'être difficile pour devenir impossible. Vous perdez la trace de l'emplacement de chaque conteneur. Un serveur tombe en panne, et votre application disparaît jusqu'à ce que quelqu'un se réveille pour la redémarrer. Les pics de trafic submergent votre configuration avant que vous ne puissiez lancer de nouvelles instances. C'est précisément là que Kubernetes entre en scène. Ce n'est pas seulement un outil DevOps de plus. C'est une couche d'orchestration qui traite la gestion des conteneurs comme un problème de contrôle plutôt que comme un simple exercice de scripting.
Pourquoi les scripts finissent par échouer
La plupart des équipes commencent par des scripts shell ou une automatisation de base. Elles écrivent des commandes pour récupérer des images, démarrer des conteneurs, surveiller les logs et redémarrer les processus défaillants. Cette approche fonctionne pour une preuve de concept. Elle s'effondre sous une charge réelle. Les microservices communiquent entre eux via différents hôtes, dépendent de variables d'environnement spécifiques, nécessitent un stockage persistant qui survit au redémarrage des conteneurs et attendent un réseau cohérent entre les versions. Un script ne peut pas replanifier automatiquement une charge de travail lorsqu'une machine virtuelle disparaît. Il ne peut pas répartir le trafic réseau entre les instances saines tout en contournant celles qui sont bloquées dans une boucle de crash (crash loop). Kubernetes résout ce problème en rendant le cluster lui-même responsable de ces décisions. Vous décrivez ce que vous voulez, et le système applique cet état en continu.
Les trois avantages qu'il vous apporte
Kubernetes offre trois capacités fondamentales qui remplacent la gestion manuelle des crises par une fiabilité automatisée.
La haute disponibilité signifie que vos applications restent en ligne même si des parties de votre infrastructure tombent en panne. Si un conteneur plante, Kubernetes le remplace en quelques secondes. Si un nœud de travail (worker node) entier s'éteint, l'ordonnanceur (scheduler) remarque l'absence de signal de vie (heartbeat) et déplace les charges de travail affectées vers des machines saines ailleurs dans le cluster. Le système surveille constamment l'état souhaité que vous avez défini, corrigeant les écarts sans intervention humaine.
La scalabilité signifie que vos applications évoluent en même temps que vos utilisateurs. Au lieu de provisionner vingt serveurs juste pour survivre à un pic de trafic de deux heures, vous définissez des métriques pertinentes, comme l'utilisation du CPU ou la latence des requêtes, et laissez le cluster ajouter davantage d'instances de conteneurs lorsque les seuils sont franchis. Lorsque la demande diminue, le nombre de réplicas diminue à nouveau. Vous payez pour ce dont vous avez besoin, au moment où vous en avez besoin.
La reprise après sinistre signifie que vos données et votre configuration reviennent après un crash. Kubernetes stocke l'état complet du cluster dans un magasin de clés-valeurs distribué. Si une défaillance catastrophique efface des nœuds de travail ou même une partie du plan de contrôle (control plane), cet état stocké permet au système de reconstruire vos charges de travail exactement telles qu'elles étaient configurées. Vos données reviennent parce que l'orchestrateur se souvient de ce à quoi elles étaient censées ressembler.
La configuration : le cerveau et les muscles
Un cluster Kubernetes possède deux rôles fondamentaux que l'on peut comparer au cerveau et aux muscles, et cette analogie tient bien la route en pratique.
Le Master Node est le cerveau. Il n'exécute pas vos applications orientées client. Au lieu de cela, il héberge les composants du plan de contrôle (control plane) qui planifient les tâches, gèrent l'état du cluster et répondent aux changements. Lorsque vous émettez une commande ou soumettez un fichier de configuration, le master node décide de l'endroit où la charge de travail doit résider, si elle est saine, et de ce qu'il faut faire lorsqu'elle ne l'est pas.
Les Worker Nodes sont les muscles. Chaque worker exécute un agent léger qui communique avec le master et utilise un runtime de conteneur pour exécuter les pods réels. Ce sont sur ces nœuds que votre code applicatif consomme du CPU et de la mémoire. Ajoutez plus de worker nodes, et votre cluster gagne en capacité brute. Ajoutez plus de master nodes configurés pour la redondance, et votre plan de contrôle devient résilient aux pannes matérielles individuelles.
Pods, conteneurs et services
Pour travailler avec Kubernetes, vous devez comprendre trois termes qui définissent la manière dont les logiciels sont emballés et rendus accessibles.
Les conteneurs sont les paquets qui regroupent votre application avec ses dépendances, ses bibliothèques et sa configuration. Ils isolent le logiciel de l'hôte sous-jacent afin qu'il s'exécute de la même manière en développement, en préproduction (staging) et en production.
Pods sont la plus petite unité déployable dans Kubernetes. Un pod enveloppe un ou plusieurs conteneurs qui doivent partager des ressources. Ils partagent le même espace de noms réseau et peuvent accéder aux mêmes volumes de stockage locaux. Ceci est important : vous ne déployez pas un conteneur nu directement. Vous déployez un pod qui le contient. Les pods sont également éphémères par conception. Ils sont créés, détruits et remplacés au gré des changements de conditions. Leur durée de vie est dynamique par nature.
Les Services existent parce que les pods sont transitoires. Chaque fois qu'un pod redémarre, il reçoit probablement une nouvelle adresse IP interne. Si d'autres parties de votre application tentaient de se connecter directement à ces adresses changeantes, elles tomberaient constamment en panne. Un service attribue à vos pods une adresse IP fixe et un nom DNS. Il agit comme une porte d'entrée stable, répartissant la charge des requêtes entrantes entre tous les pods sains qui correspondent à son sélecteur. Cela découple vos clients du chaos des cycles de vie individuels des conteneurs.
Kubernetes à grande échelle : l'exemple Netflix
Netflix utilise Kubernetes pour gérer son réseau de diffusion de contenu. Cette infrastructure diffuse des flux vidéo à des millions de spectateurs simultanément à travers le monde. Lorsqu'une série populaire sort et que la demande grimpe en flèche, le cluster augmente le nombre de nœuds de cache qui stockent les segments vidéo plus près des utilisateurs. Si un nœud régional tombe en panne, le trafic est réacheminé automatiquement. Le résultat est que les films continuent de fonctionner pour des millions de personnes sans qu'un ingénieur ne soit sollicité manuellement en urgence. L'orchestrateur gère l'échelle et les défaillances afin que le service se poursuive sans interruption.
Pour débuter : YAML, JSON et l'API Server
Débuter avec Kubernetes signifie abandonner le « click-ops » impératif pour adopter la configuration déclarative. Vous écrivez ce que vous voulez dans des fichiers YAML ou JSON. Ces manifestes décrivent tout, de l'image du conteneur au nombre de réplicas, en passant par les ports exposés, les variables d'environnement et les montages de stockage. Une fois votre fichier prêt, vous l'envoyez à l'API server sur le nœud maître. Le plan de contrôle ingère cette déclaration, la stocke dans la base de données de l'état du cluster, puis se met au travail pour que la réalité corresponde à votre description. Vous ne dites pas à Kubernetes exactement comment faire son travail. Vous lui dites quel doit être le résultat final, et il détermine les étapes à suivre.
L'essentiel à retenir
Kubernetes a une courbe d'apprentissage. La terminologie semble dense au début. Il y a de nombreux éléments mobiles, et le débogage d'un système distribué est intrinsèquement plus difficile que le débogage d'un serveur unique. Mais la récompense est un calme opérationnel. Vous arrêtez de surveiller chaque machine individuellement. Vous arrêtez de prier pour que vos scripts de démarrage fonctionnent lors d'une panne à 3 heures du matin. Vous commencez à concevoir pour la défaillance par défaut, en partant du principe que les nœuds mourront, et en faisant confiance à l'orchestrateur pour maintenir votre application intacte. Ce changement d'état d'esprit, passer de l'espoir que rien ne casse à la certitude que le système peut gérer les pannes, est ce qui justifie l'effort.
Source : What Is Kubernetes? Kubernetes Explained in 15 Mins
Communauté d'apprentissage optionnelle : GyaanSetu AI sur Telegram