Comment fonctionne Kubernetes? –
Kubernetes est une plateforme d’orchestration de conteneurs qui automatise le déploiement et la mise à l’échelle des charges de travail conteneurisées. Kubernetes a acquis la réputation d’être complexe et peu maniable. Voici comment les composants individuels se combinent pour former un cluster.
Sommaire
Définition du cluster
Une seule installation Kubernetes est appelée un «cluster». Au sein du cluster, un ou plusieurs nœuds sont disponibles pour exécuter vos conteneurs. Un nœud est une représentation d’une machine physique qui a été jointe au cluster.
Kubernetes dispose également d’une surface de plan de contrôle. Cela fonctionne indépendamment des nœuds de travail. Le plan de contrôle est ce avec quoi vous interagissez. Il expose l’API Kubernetes et est responsable de la gestion des nœuds de travail. Vous ne manipulez généralement pas directement les nœuds et leurs charges de travail.
Demander à Kubernetes de créer une charge de travail commence par un appel d’API au plan de contrôle. Le plan de contrôle détermine ensuite le ou les nœuds sur lesquels vos conteneurs doivent être planifiés. Quel que soit le nombre de nœuds que vous avez, il n’y aura jamais qu’un seul plan de contrôle dans votre cluster.
Rôle de l’avion de contrôle
Plus largement, le Control Plane est responsable de la gestion globale de votre cluster. Toute opération susceptible d’affecter plusieurs nœuds ou l’infrastructure du cluster sera gérée par le plan de contrôle.
Le plan de contrôle se compose de plusieurs composants indépendants. Ensemble, ils sont responsables de la gestion de la configuration du cluster, de l’exécution et de la mise à l’échelle des charges de travail et de la réaction aux événements au sein du cluster (comme un nœud manquant de mémoire).
Le cœur du plan de contrôle est kube-apiserver. Ce composant fournit l’API HTTP Kubernetes que vous utilisez via des outils tels que Kubectl et Helm. L’API est la façon dont vous interagissez avec votre cluster. Il est également utilisé par d’autres composants de cluster, tels que les processus de travail Node, pour relayer les informations vers le plan de contrôle.
Les ressources de votre cluster, telles que les pods, les services et les tâches, sont gérées par des «contrôleurs» individuels. Les contrôleurs surveillent leurs ressources en termes de salubrité et de préparation. Ils identifient également les modifications qui ont été demandées, puis prennent des mesures pour migrer l’état actuel vers l’état nouvellement souhaité.
Les contrôleurs sont gérés globalement par gestionnaire-contrôleur-kube. Ce composant Control Plane démarre et exécute les contrôleurs individuels. Ce processus sera toujours en cours d’exécution. S’il s’arrêtait un jour, les modifications effectuées via le serveur API ne seraient pas identifiées et aucun changement d’état ne se produirait.
Un autre composant critique du plan de contrôle est planificateur de kube. Le planificateur est responsable de l’attribution des pods aux nœuds. La planification nécessite généralement la prise en compte de plusieurs paramètres différents, tels que l’utilisation actuelle des ressources de chaque nœud et les contraintes que vous avez appliquées dans votre manifeste.
Le planificateur évaluera l’adéquation de chaque nœud, puis déléguera le pod pour qu’il s’exécute sur le nœud le plus approprié. Si la disponibilité du nœud change ou si plusieurs répliques d’un pod sont demandées, le planificateur prendra des mesures pour replanifier la charge de travail en conséquence.
L’ensemble du plan de contrôle s’exécute généralement sur un seul nœud au sein du cluster. Il est techniquement possible d’étendre le plan de contrôle sur plusieurs nœuds. Cela permet de maximiser sa disponibilité.
Habituellement, la perte du plan de contrôle vous empêche de gérer votre cluster, car l’API et les fonctions de planification sont hors ligne. Les pods sur les nœuds de travail continueront cependant de fonctionner – ils tenteront périodiquement de se reconnecter au plan de contrôle.
Communication entre les nœuds et le plan de contrôle
Kubernetes maintient un canal de communication bidirectionnel entre les nœuds et le plan de contrôle.
La communication est nécessaire pour que le plan de contrôle puisse demander aux nœuds de créer de nouveaux conteneurs. Dans la direction opposée, les nœuds doivent renvoyer les données sur leur disponibilité (telles que les statistiques d’utilisation des ressources) au plan de contrôle. Cela garantit que Kubernetes peut prendre des décisions éclairées lors de la planification des conteneurs.
Tous les nœuds worker exécutent une instance de kubelet. Il s’agit d’un utilitaire d’agent chargé de maintenir la communication avec le plan de contrôle Kubernetes. Kubelet surveille également en permanence les conteneurs exécutés par le nœud. Il notifiera le plan de contrôle si un conteneur tombe dans un état malsain.
Lorsqu’un nœud a besoin d’envoyer des données au plan de contrôle, Kubelet se connecte au serveur API du plan de contrôle. Cela utilise la même interface HTTPS à laquelle vous vous connectez via des outils tels que kubectl. Kubelet est préconfiguré avec des informations d’identification qui lui permettent de s’authentifier auprès de Kubernetes.
Le trafic du plan de contrôle vers les nœuds est à nouveau géré à l’aide de kubelet. Kubelet expose son propre point de terminaison HTTPS auquel le plan de contrôle peut accéder. Ce point de terminaison accepte de nouveaux manifestes de conteneur, que kubelet utilise ensuite pour ajuster les conteneurs en cours d’exécution.
Quels autres nœuds fonctionnent-ils?
Kubelet n’est pas le seul binaire qu’un nœud Kubernetes doit exécuter. Vous trouverez également une instance de kube-proxy sur chaque nœud. Il est responsable de la configuration du système de mise en réseau du nœud pour répondre aux exigences de vos charges de travail de conteneur.
Kubernetes a le concept de «services», qui exposent plusieurs pods comme une seule identité réseau. C’est kube-proxy qui convertit les définitions de service en règles de mise en réseau qui fournissent l’accès que vous avez demandé.
kube-proxy configure l’infrastructure réseau du système d’exploitation pour exposer les services créés par kubelet. Le transfert du trafic est géré soit par la couche de filtrage des paquets au niveau du système d’exploitation, soit par le proxy kube lui-même.
Outre kubelet et kube-proxy, les nœuds doivent également disposer d’un environnement d’exécution de conteneur. Le runtime du conteneur est responsable de l’extraction des images et de l’exécution réelle de vos conteneurs. Kubernetes prend en charge tout moteur d’exécution implémentant sa spécification Container Runtime Interface. Les exemples incluent containerd et CRI-O.
Conclusion
Kubernetes implique beaucoup de terminologie. La décomposition des clusters en leurs parties constituantes peut vous aider à apprécier comment les composants individuels sont liés.
Le plan de contrôle se trouve au-dessus de tous les nœuds et est responsable de la gestion des opérations du cluster. Les nœuds sont mieux considérés comme égaux directement sous le plan de contrôle. Il existe une communication continue entre les nœuds et le plan de contrôle. En tant qu’utilisateur, vous n’interagissez avec le plan de contrôle que via le serveur API.
Le plan de contrôle est donc le hub de votre cluster. Vous n’interagissez généralement pas directement avec les nœuds. Au lieu de cela, vous envoyez des instructions au plan de contrôle, qui crée ensuite des horaires appropriés pour répondre à votre demande. Les charges de travail ne sont planifiées pour les nœuds que lorsque le plan de contrôle envoie un manifeste de conteneur à l’une des instances de kubelet disponibles.
Lorsqu’un nœud reçoit un nouveau manifeste, il utilise son environnement d’exécution de conteneur pour extraire l’image appropriée et démarrer une nouvelle instance de conteneur. kube-proxy modifiera ensuite la configuration du réseau pour configurer les services et rendre votre charge de travail accessible. Kubelet relaie les données sur la santé du nœud vers Kubernetes, ce qui lui permet de prendre des mesures pour replanifier les pods si les ressources du nœud sont limitées.
