Architecture du cluster

Un cluster Kubernetes est composé d'un plan de contrôle et d'un ensemble de machines de travail, appelées nœuds, qui exécutent des applications conteneurisées. Chaque cluster a besoin d'au moins un nœud de travail pour exécuter des Pods.

Les nœuds de travail hébergent les Pods qui sont les composants de la charge de travail de l'application. Le plan de contrôle gère les nœuds de travail et les Pods du cluster. Dans les environnements de production, le plan de contrôle s'exécute généralement sur plusieurs ordinateurs et un cluster exécute généralement plusieurs nœuds, offrant une tolérance aux pannes et une haute disponibilité.

Ce document décrit les différents composants nécessaires pour avoir un cluster Kubernetes complet et fonctionnel.

Composants du plan de contrôle

Les composants du plan de contrôle prennent des décisions globales sur le cluster (par exemple, la planification), ainsi que la détection et la réponse aux événements du cluster (par exemple, démarrer un nouveau pod lorsque le champ replicas d'un déploiement n'est pas satisfait).

Les composants du plan de contrôle peuvent s'exécuter sur n'importe quelle machine du cluster. Cependant, pour simplifier, les scripts d'installation démarrent généralement tous les composants du plan de contrôle sur la même machine et n'exécutent pas de conteneurs utilisateur sur cette machine. Consultez Création de clusters hautement disponibles avec kubeadm pour un exemple de configuration du plan de contrôle s'exécutant sur plusieurs machines.

kube-apiserver

Composant sur le master qui expose l'API Kubernetes. Il s'agit du front-end pour le plan de contrôle Kubernetes.

Il est conçu pour une mise à l'échelle horizontale, ce qui veut dire qu'il met à l'échelle en déployant des instances supplémentaires. Voir Construire des Clusters en Haute Disponibilité.

etcd

Base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster.

Si votre cluster Kubernetes utilise etcd comme mémoire de sauvegarde, assurez-vous d'avoir un plan de back up pour ces données.

Vous pouvez trouver plus d'informations à propos d'etcd dans la documentation officielle.

kube-scheduler

Composant sur le master qui surveille les pods nouvellement créés qui ne sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont s'exécuter.

Les facteurs pris en compte pour les décisions de planification (scheduling) comprennent les exigences individuelles et collectives en ressources, les contraintes matérielles/logicielles/politiques, les spécifications d'affinité et d'anti-affinité, la localité des données, les interférences entre charges de travail et les dates limites.

kube-controller-manager

Composant du master qui exécute les contrôleurs.

Logiquement, chaque contrôleur est un processus à part mais, pour réduire la complexité, les contrôleurs sont tous compilés dans un seul binaire et s'exécutent dans un seul processus.

Il existe de nombreux types de contrôleurs différents. Voici quelques exemples :

• Contrôleur de nœuds : Responsable de la détection et de la réponse lorsque les nœuds tombent en panne.
• Contrôleur de tâches : Surveille les objets Job qui représentent des tâches ponctuelles, puis crée des Pods pour exécuter ces tâches jusqu'à leur achèvement.
• Contrôleur EndpointSlice : Remplit les objets EndpointSlice (pour établir un lien entre les Services et les Pods).
• Contrôleur ServiceAccount : Crée des comptes de service par défaut pour les nouveaux espaces de noms.

Ce qui précède n'est pas une liste exhaustive.

cloud-controller-manager

Le Cloud Controller Manager est une fonctionnalité alpha de la version 1.8. Dans les prochaines versions, il deviendra le moyen privilégié pour l'intégration de Kubernetes à n'importe quel cloud.

Le cloud-controller-manager exécute uniquement des contrôleurs spécifiques à votre fournisseur de cloud. Si vous exécutez Kubernetes sur vos propres serveurs ou dans un environnement d'apprentissage sur votre propre PC, le cluster n'a pas de cloud-controller-manager.

Comme pour kube-controller-manager, cloud-controller-manager combine plusieurs boucles de contrôle logiquement indépendantes en un seul binaire que vous exécutez en tant que processus unique. Vous pouvez mettre à l'échelle horizontalement (exécuter plusieurs copies) pour améliorer les performances ou pour aider à tolérer les pannes.

Les contrôleurs suivants peuvent avoir des dépendances vis-à-vis du fournisseur de cloud :

• Contrôleur de nœuds : Pour vérifier auprès du fournisseur de cloud si un nœud a été supprimé dans le cloud après avoir cessé de répondre
• Contrôleur de routage : Pour configurer les routes dans l'infrastructure cloud sous-jacente
• Contrôleur de service : Pour créer, mettre à jour et supprimer des équilibreurs de charge du fournisseur de cloud

Composants du nœud

Les composants du nœud s'exécutent sur chaque nœud, maintenant les Pods en cours d'exécution et fournissant l'environnement d'exécution Kubernetes.

kubelet

Un agent qui s'exécute sur chaque nœud du cluster. Il s'assure que les conteneurs fonctionnent dans un pod.

Le kubelet prend un ensemble de PodSpecs fournis par divers mécanismes et s'assure du fonctionnement et de la santé des conteneurs décrits dans ces PodSpecs. Le kubelet ne gère que les conteneurs créés par Kubernetes.

kube-proxy (optionnel)

kube-proxy est un proxy réseau qui s'exécute sur chaque nœud du cluster et implémente une partie du concept Kubernetes de Service.

kube-proxy maintient les règles réseau sur les nœuds. Ces règles réseau permettent une communication réseau vers les Pods depuis des sessions réseau à l'intérieur ou à l'extérieur du cluster.

kube-proxy utilise la couche de filtrage de paquets du système d'exploitation s'il y en a une et qu'elle est disponible. Sinon, kube-proxy transmet le trafic lui-même.

Si vous utilisez un plugin réseau qui implémente le transfert de paquets pour les Services par lui-même, et fournissant un comportement équivalent à kube-proxy, alors vous n'avez pas besoin d'exécuter kube-proxy sur les nœuds de votre cluster.

Runtime de conteneur

L'environnement d'exécution de conteneurs est le logiciel responsable de l'exécution des conteneurs.

Kubernetes est compatible avec plusieurs environnements d'exécution de conteneur: Docker, containerd, cri-o, rktlet ainsi que toute implémentation de Kubernetes CRI (Container Runtime Interface).

Add-ons

Les add-ons utilisent des ressources Kubernetes (DaemonSet, Déploiement, etc.) pour implémenter des fonctionnalités de cluster. Étant donné qu'ils fournissent des fonctionnalités au niveau du cluster, les ressources des add-ons appartiennent au namespace kube-system.

Certains add-ons sélectionnés sont décrits ci-dessous ; pour une liste étendue d'add-ons disponibles, veuillez consulter Add-ons.

DNS

Bien que les autres add-ons ne soient pas strictement nécessaires, tous les clusters Kubernetes devraient avoir DNS du cluster, car de nombreux exemples en dépendent.

Le DNS du cluster est un serveur DNS, en plus des autres serveur(s) DNS de votre environnement, qui fournit des enregistrements DNS pour les services Kubernetes.

Les conteneurs démarrés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS.

Interface utilisateur Web (Dashboard)

Dashboard est une interface utilisateur basée sur le web, générale, pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de résoudre les problèmes des applications en cours d'exécution dans le cluster, ainsi que du cluster lui-même.

Surveillance des ressources des conteneurs

Surveillance des ressources des conteneurs enregistre des métriques génériques de séries chronologiques sur les conteneurs dans une base de données centrale et fournit une interface utilisateur pour parcourir ces données.

Journalisation au niveau du cluster

Un mécanisme de journalisation au niveau du cluster est responsable de l'enregistrement des journaux des conteneurs dans un magasin de journaux central avec une interface de recherche/parcours.

Plugins réseau

Les plugins réseau sont des composants logiciels qui implémentent la spécification de l'interface réseau de conteneur (CNI). Ils sont responsables de l'allocation des adresses IP aux pods et de leur permettre de communiquer entre eux au sein du cluster.

Variations de l'architecture

Bien que les composants principaux de Kubernetes restent cohérents, la manière dont ils sont déployés et gérés peut varier. Comprendre ces variations est crucial pour concevoir et maintenir des clusters Kubernetes répondant à des besoins opérationnels spécifiques.

Options de déploiement du plan de contrôle

Les composants du plan de contrôle peuvent être déployés de plusieurs manières :

Déploiement traditionnel

Les composants du plan de contrôle s'exécutent directement sur des machines dédiées ou des machines virtuelles, souvent gérées en tant que services systemd.

Pods statiques

Les composants du plan de contrôle sont déployés en tant que Pods statiques, gérés par le kubelet sur des nœuds spécifiques. Il s'agit d'une approche courante utilisée par des outils tels que kubeadm.

Auto-hébergé

Le plan de contrôle s'exécute en tant que Pods au sein du cluster Kubernetes lui-même, gérés par des déploiements et des StatefulSets ou d'autres primitives Kubernetes.

Services Kubernetes gérés

Les fournisseurs de cloud abstraient souvent le plan de contrôle, en gérant ses composants dans le cadre de leur offre de services.

Considérations pour le placement de la charge de travail

Le placement des charges de travail, y compris les composants du plan de contrôle, peut varier en fonction de la taille du cluster, des exigences de performance et des politiques opérationnelles :

• Dans les clusters plus petits ou de développement, les composants du plan de contrôle et les charges de travail des utilisateurs peuvent s'exécuter sur les mêmes nœuds.
• Les clusters de production plus importants dédient souvent des nœuds spécifiques aux composants du plan de contrôle, les séparant des charges de travail des utilisateurs.
• Certaines organisations exécutent des add-ons critiques ou des outils de surveillance sur les nœuds du plan de contrôle.

Outils de gestion de cluster

Des outils tels que kubeadm, kops et Kubespray offrent différentes approches pour le déploiement et la gestion des clusters, chacun avec sa propre méthode de disposition et de gestion des composants.

La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques, en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion.

Personnalisation et extensibilité

L'architecture de Kubernetes permet une personnalisation significative :

• Des ordonnanceurs personnalisés peuvent être déployés pour travailler aux côtés de l'ordonnanceur Kubernetes par défaut ou pour le remplacer entièrement.
• Les serveurs API peuvent être étendus avec des CustomResourceDefinitions et une agrégation d'API.
• Les fournisseurs de cloud peuvent s'intégrer profondément à Kubernetes en utilisant le cloud-controller-manager.

La flexibilité de l'architecture de Kubernetes permet aux organisations d'adapter leurs clusters à des besoins spécifiques, en équilibrant des facteurs tels que la complexité opérationnelle, les performances et la charge de gestion.

A suivre

En savoir plus sur les sujets suivants :

• Nœuds et leur communication avec le plan de contrôle.
• Les contrôleurs Kubernetes.
• kube-scheduler, qui est l'ordonnanceur par défaut de Kubernetes.
• La documentation officielle d'Etcd.
• Plusieurs runtimes de conteneurs dans Kubernetes.
• Intégration avec les fournisseurs de cloud en utilisant cloud-controller-manager.
• Commandes kubectl.