Ce qu'est vraiment Kubernetes, sans le jargon

En une phrase

Kubernetes est un programme qui maintient une flotte de conteneurs dans l'état que vous avez demandé, même quand les machines en dessous tombent en panne, sont surchargées, ou doivent être remplacées. Vous décrivez l'état final voulu — « je veux 3 copies de ce conteneur, en permanence » — et Kubernetes passe chaque seconde suivante à comparer cette promesse à la réalité pour combler l'écart.

Le problème qu'il résout réellement

Avant Kubernetes, faire tourner des conteneurs à grande échelle voulait dire se connecter en SSH sur un serveur et les démarrer à la main. Si ce serveur plantait à 3h du matin, le conteneur restait mort jusqu'à ce qu'un humain le remarque et le relance ailleurs. C'est gérable avec trois conteneurs sur une machine. Ça cesse de l'être avec trois cents conteneurs répartis sur quarante machines — personne ne peut surveiller autant de pannes en temps réel. Le vrai travail de Kubernetes, c'est d'être ce surveillant infatigable : il repère les pannes en quelques secondes et réagit sans attendre qu'un humain se réveille.

Les quatre notions qui comptent vraiment

Oubliez un instant le vocabulaire tentaculaire — presque tout ce que fait Kubernetes se résume à quatre objets :

• Pod — la plus petite unité que Kubernetes planifie. Un ou plusieurs conteneurs qui démarrent, s'arrêtent et se déplacent toujours ensemble.
• Node — une machine physique ou virtuelle qui a de la place pour faire tourner des pods.
• Deployment — une promesse permanente : « je veux toujours N copies de ce pod ». Kubernetes vérifie cette promesse en continu, pas seulement à la création.
• Service — une adresse réseau stable qui pointe toujours vers les pods actuellement vivants, même quand les pods réels derrière elle sont remplacés.

Tout le reste — ConfigMaps, Ingress, StatefulSets, Operators — est construit sur ces quatre idées, pas un remplacement.

Ce que « auto-réparation » veut dire, mécaniquement

C'est la partie que la plupart des explications survolent. Kubernetes fait tourner une boucle constante : le controller manager compare ce que vous avez demandé (3 réplicas) à ce qui existe réellement (lu depuis l'API server, alimenté par chaque nœud). Dès que ces deux nombres divergent — un nœud plante et emporte un pod avec lui — le controller manager crée un objet pod de remplacement. Le scheduler choisit ensuite un nœud avec assez de CPU et de mémoire libres, et l'agent local de ce nœud (le kubelet) démarre réellement le conteneur. Rien de tout ça ne demande qu'un humain remarque quoi que ce soit. Le cycle complet, de la panne du nœud au pod de remplacement en cours d'exécution ailleurs, prend typiquement quelques secondes.

Ce qu'on se trompe souvent : « Kubernetes fait tourner mon code »

Non, pas directement. Kubernetes ne fait tourner que des images de conteneurs — il ignore complètement ce qu'est Python, Node.js ou Go. Vous construisez toujours votre propre image Docker, vous la poussez quelque part où Kubernetes peut la récupérer, et c'est seulement à ce moment-là que Kubernetes prend le relais pour maintenir des instances de cette image en vie. Il ne remplace pas non plus votre CI/CD (il faut toujours quelque chose pour construire et pousser cette image), et il ne fait pas grossir automatiquement une base de données juste parce que vous lui avez demandé de scaler un pod web sans état — les systèmes avec état demandent une gestion délibérée et séparée, pour laquelle Kubernetes fournit des briques, pas un laissez-passer gratuit.

Quand vous n'en avez vraiment pas besoin

Si toute votre application tient confortablement sur un seul serveur et que quelques minutes d'indisponibilité pendant un redémarrage ne sont pas un drame, un simple Docker Compose fait le travail avec une fraction de la complexité opérationnelle. Kubernetes justifie sa complexité quand vous avez besoin de résilience sur plusieurs machines, de déploiements progressifs sans coupure, ou d'une échelle qu'une seule machine ne peut pas absorber — ce qui décrit, en pratique, la plupart des équipes d'ingénierie de taille moyenne ou grande, et c'est justement pour ça que ça vaut le coup de l'apprendre avant même d'en avoir besoin personnellement.