Une carte visuelle d’un déploiement Kubernetes

Lorsque vous travaillez avec des conteneurs sur Kubernetes, vous regroupez souvent des applications dans un pod. Lorsque vous lancez un conteneur ou un pod en production, cela s’appelle un déploiement. Si vous utilisez Kubernetes quotidiennement ou même juste une fois par semaine, vous l’avez probablement fait des centaines de fois, mais avez-vous pensé à ce qui se passe exactement lorsque vous créez un pod ou un déploiement ?

Je trouve utile d’avoir une compréhension de la chaîne des événements à un niveau élevé. Vous n’avez pas à le comprendre, bien sûr. Cela fonctionne toujours même si vous ne savez pas pourquoi. Je n’ai pas l’intention d’énumérer chaque petite chose qui se passe, mais je vise à couvrir toutes les plus importantes.

Voici une carte visuelle de la façon dont les différents composants de Kubernetes interagissent :

Vous remarquerez peut-être dans le diagramme ci-dessus que je n’ai pas inclus etcd. Le serveur API est le seul composant qui peut communiquer directement avec etcd, et lui seul peut y apporter des modifications. Vous pouvez donc supposer qu’etcd existe (caché) derrière le serveur d’API dans ce diagramme.

De plus, je ne parle que de deux contrôleurs principaux (Déploiement et ReplicaSet) ici. D’autres fonctionneraient également de la même manière.

Les étapes ci-dessous décrivent ce qui se passe lorsque vous exécutez le kubectl create commander:

Étape 1: Lorsque vous utilisez le kubectl create commande, une requête HTTP POST est envoyée au serveur d’API, qui contient le manifeste de déploiement. Le serveur d’API stocke cela dans le magasin de données etcd et renvoie une réponse au kubectl.

Étapes 2 et 3 : Le serveur API dispose d’un mécanisme de surveillance et tous les clients qui le surveillent sont avertis. Un client surveille les modifications en ouvrant une connexion HTTP au serveur API, qui diffuse les notifications. L’un de ces clients est le contrôleur de déploiement. Le contrôleur de déploiement détecte un objet de déploiement et crée un ReplicaSet avec la spécification actuelle du déploiement. Cette ressource est renvoyée au serveur d’API, qui la stocke dans le magasin de données etcd.

Étapes 4 et 5 : Semblable à l’étape précédente, tous les observateurs sont informés de la modification apportée au serveur d’API. Cette fois, le contrôleur ReplicaSet récupère la modification. Le contrôleur comprend le nombre de répliques souhaité et les sélecteurs de pod définis dans la spécification d’objet, crée les ressources de pod et renvoie ces informations au serveur d’API, en les stockant dans le magasin de données etcd.

Étapes 6 et 7 : Kubernetes dispose désormais de toutes les informations dont il a besoin pour exécuter le pod, mais sur quel nœud les pods doivent-ils s’exécuter ? Le planificateur surveille les pods auxquels aucun nœud n’a encore été attribué et démarre son processus de filtrage et de classement de tous les nœuds pour choisir le meilleur nœud sur lequel exécuter le pod. Une fois le nœud sélectionné, ces informations sont ajoutées à la spécification du pod. Et il est renvoyé au serveur API et stocké dans le magasin de données etcd.

Étapes 8, 9 et 10 : Toutes les étapes jusqu’à présent se produisent dans le plan de contrôle lui-même. Le nœud de travail n’a pas encore effectué de travail. La création du pod n’est cependant pas gérée par le plan de contrôle. Au lieu de cela, le service kubelet exécuté sur tous les nœuds surveille la spécification du pod dans le serveur d’API pour déterminer s’il doit créer des pods. Le service kubelet s’exécutant sur le nœud sélectionné par le planificateur obtient la spécification du pod et demande au runtime du conteneur dans le nœud de travail de créer le conteneur. C’est à ce moment qu’une image de conteneur est téléchargée (si elle n’est pas déjà présente) et que le conteneur commence réellement à s’exécuter.

Comprendre les déploiements Kubernetes

Comprendre ce flux général peut vous aider à comprendre de nombreux événements dans Kubernetes. Envisagez un DemonSet ou un StatefulSet dans Kubernetes. Outre l’utilisation de différents contrôleurs, le processus de création de pod reste le même.

Posez-vous la question : si le déploiement est modifié pour avoir trois répliques d’une application, à quoi ressemblerait la chaîne d’événements menant à la création des pods ? Vous pouvez vous référer au diagramme ou aux étapes répertoriées, mais vous avez certainement les connaissances nécessaires pour le comprendre. Savoir, c’est pouvoir, et vous disposez désormais d’un élément important pour comprendre Kubernetes.