Kubernetes (souvent abrégé K8s) est une plateforme open source pour exécuter et gérer des applications conteneurisées sur de nombreuses machines. Il a été créé chez Google et est aujourd’hui un projet de la Cloud Native Computing Foundation. Ce guide explique les problèmes qu’il existe pour résoudre et les quelques termes sur lesquels s’appuie le reste de cette série.

Les conteneurs, c’est la partie facile

Un conteneur empaquette une application avec les bibliothèques dont elle a besoin, de sorte qu’elle s’exécute de la même façon sur un ordinateur portable, un serveur de test et en production. Les conteneurs démarrent vite, sont peu coûteux à remplacer, et on les met à l’échelle en exécutant davantage de copies. Cela convient bien aux architectures de microservices, où une application est découpée en de nombreux petits services, chacun dans son propre conteneur.

Ce qui casse sans orchestration

Maintenant, exécutez vous-même ces conteneurs sur une seule machine virtuelle et regardez ce qui se passe :

• L’hôte se remplit. Quand la machine n’a plus de CPU ou de mémoire disponibles, vous devez démarrer les nouveaux conteneurs ailleurs et les connecter au reste à la main.
• Des conteneurs meurent et personne ne le remarque. Les conteneurs sont jetables par conception. Redémarrer un conteneur planté, c’est à vous de le scripter ou de le faire manuellement.
• L’hôte lui-même tombe en panne. Tous les conteneurs qu’il héberge tombent ensemble, et rien ne les remet en route.

Vous pouvez écrire des scripts pour chacun de ces cas, mais quand une application compte des centaines de conteneurs répartis sur plusieurs environnements, cet outillage maison devient un projet à part entière.

Ce qu’apporte un orchestrateur

Kubernetes prend en charge ces tâches :

• Haute disponibilité. Exécutez plusieurs copies d’une charge de travail sur des machines différentes pour que les utilisateurs ne remarquent pas la défaillance de l’une d’elles.
• Mise à l’échelle. Augmentez ou diminuez le nombre de copies selon la charge, manuellement ou automatiquement.
• Auto-réparation. Redémarrez les conteneurs défaillants et replanifiez les charges de travail des machines en panne vers des machines saines.
• État récupérable. La configuration et l’état du cluster résident dans un datastore (etcd) que vous pouvez sauvegarder et restaurer.

Les briques de base : pods, nœuds et clusters

Trois termes couvrent l’essentiel du vocabulaire :

• Un Pod est la plus petite chose que Kubernetes exécute. Il enveloppe un ou plusieurs conteneurs qui partagent réseau et stockage. La plupart des Pods contiennent un conteneur principal, parfois accompagné d’un assistant. Kubernetes gère des Pods, pas des conteneurs isolés.
• Un nœud est une machine, virtuelle ou physique, qui exécute des Pods.
• Un cluster est un ensemble de nœuds gérés comme un seul pool de CPU et de mémoire. Certains nœuds forment le plan de contrôle qui gère le cluster, et les autres sont des nœuds de travail qui exécutent vos applications. Le guide suivant explique leur fonctionnement.

Le modèle déclaratif

Vous ne dites pas à Kubernetes quelles étapes suivre. Vous décrivez l’état que vous voulez, généralement en YAML (« trois réplicas de cette image, exposés sur ce port »), et vous l’envoyez à l’API du cluster. Des controllers internes à Kubernetes comparent ensuite en continu ce qui existe avec ce que vous avez demandé et agissent sur la différence. C’est pourquoi un Pod que vous supprimez revient quand un Deployment indique que trois doivent exister, et c’est le fondement de tout le reste de cette série.

Ce que Kubernetes ne fait pas pour vous

Kubernetes est une plateforme, pas une solution complète :

• Il ne construit pas vos images et ne teste pas votre code. Cela reste le travail de la CI.
• Il ne sauvegarde pas les données de votre application. Le stockage persistant et les sauvegardes sont de votre responsabilité.
• Il ne chiffre pas les Secrets par défaut, et ses paramètres par défaut ne sont pas durcis pour la production.
• C’est un système vaste avec une vraie courbe d’apprentissage : entraînez-vous donc d’abord sur un cluster local, ce que font les prochains guides.