Composants de l'architecture Kubernetes
L'architecture Kubernetes suit un modèle maître-ouvrier, où le maître, connu sous le nom de plan de contrôle, gère les nœuds ouvriers. D'autre part, les conteneurs (encapsulés dans des pods) sont déployés et exécutés dans les nœuds de travail. Ces nœuds peuvent être des machines virtuelles (sur site ou dans le nuage) ou des serveurs physiques.
Décortiquons les composants essentiels de cette architecture :
Plan de contrôle (Control Plane)
Le plan de contrôle est responsable de l'orchestration des conteneurs et maintient l'état d'un cluster.
Composants du plan de contrôle de Kubernetes
Le plan de contrôle de Kubernetes est constitué de plusieurs composants, chacun étant responsable d'une tâche spécifique (comme expliqué ci-dessous). Ces composants travaillent ensemble pour s'assurer que l'état de chaque cluster Kubernetes correspond à l'état souhaité prédéfini.
kube-apiserver
Le serveur kube-API aide les utilisateurs et les autres composants à communiquer facilement avec le cluster. Certains systèmes de surveillance et services tiers peuvent également (très rarement) l'utiliser pour interagir avec le cluster. Lorsque vous utilisez un CLI comme kubectl pour gérer le cluster, vous utilisez les API HTTP REST pour communiquer avec le serveur API.
Les composants internes du cluster (tels que le planificateur et le contrôleur) utilisent cependant gRPC pour cette communication.
Le serveur API crypte ses communications avec les autres composants pour garantir la sécurité grâce à TLS. Sa fonction principale est de gérer les demandes d'API, de valider les données pour les objets API, d'authentifier et d'autoriser les utilisateurs, et de coordonner les processus entre le plan de contrôle et les composants des nœuds de travail.
Le serveur API fonctionne uniquement avec etcd et comprend un proxy bastion apiserver intégré, permettant un accès externe aux services ClusterIP.
etcd
etcd est un outil utile pour stocker des données clé-valeur dans une approche distribuée. Il est conçu pour stocker des données sur les clusters Kubernetes, telles que des informations sur les pods, leur état et les espaces de noms. etcd n'est accessible qu'à partir du serveur API pour maintenir la sécurité.
Kubernetes utilise etcd pour gérer son API clé-valeur via gRPC. Tous les objets sont stockés sous la clé du répertoire /registry au format clé-valeur.
Le serveur api de Kubernetes utilise la fonction watch d'etcd pour surveiller toute modification de l'état d'un objet. En tant que seul composant Statefulset dans le plan de contrôle, etcd est une excellente base de données pour Kubernetes.
kube-scheduler
Lors du déploiement d'un pod dans un cluster Kubernetes, le planificateur kube identifie le meilleur nœud ouvrier qui répond aux exigences du pod, telles que le CPU, la mémoire et l'affinité. Une fois identifié, il planifie le pod sur le bon nœud.
Ce processus est rendu possible grâce au rôle d'etcd qui stocke les informations vitales nécessaires au bon fonctionnement de Kubernetes. Les informations nécessaires sont stockées dans l'armoire à fichiers etcd chaque fois qu'une demande est adressée à Kubernetes.
Kubernetes planifie un pod à l'aide de plusieurs techniques.
Tout d'abord, il filtre tous les nœuds disponibles afin de trouver les meilleurs pour le module. Ensuite, il attribue à chaque nœud un score basé sur les plugins d'ordonnancement. L'ordonnanceur sélectionne le meilleur nœud et y associe le module. Ce processus garantit que les modules hautement prioritaires reçoivent la priorité qu'ils méritent et que des plugins personnalisés peuvent être facilement ajoutés au mélange. C'est une manière innovante et efficace de gérer les pods Kubernetes.
kube-controller-manager
Le kube-controller-manager gère différents contrôleurs qui permettent de créer des répliques de conteneurs et de s'assurer que le cluster reste dans l'état souhaité.
Par exemple, lorsque vous créez un fichier manifest YAML pour spécifier le déploiement (deux répliques, un montage de volume, une carte de configuration, etc.) Grâce au contrôleur de déploiement intégré, le déploiement restera toujours dans l'état souhaité.
Il existe plusieurs types de contrôleurs gérés par le kube-controller-manager :
- Les contrôleurs de déploiement gèrent le déploiement de plusieurs répliques d'une application fonctionnant dans des conteneurs.
- Les contrôleurs de réplication garantissent qu'un nombre spécifique de répliques de pods est toujours en cours d'exécution. Si un pod tombe en panne, le contrôleur de réplication en crée un nouveau pour le remplacer.
- Les contrôleurs StatefulSet offrent des fonctionnalités utiles telles que le stockage persistant, des identités réseau uniques et un moyen contrôlé de déployer et de faire évoluer l'application.
- Les contrôleurs DaemonSet garantissent qu'un module spécifique s'exécute sur chaque nœud du cluster ou uniquement sur des nœuds sélectionnés en fonction d'étiquettes particulières.
cloud-controller-manager (CCM)
Lors du déploiement de Kubernetes dans des environnements en nuage, il est essentiel de faire le lien entre les API de la plateforme en nuage et le cluster Kubernetes. Cela peut se faire à l'aide du gestionnaire de contrôleur cloud, qui permet aux composants principaux de Kubernetes de fonctionner indépendamment et aux fournisseurs de cloud de s'intégrer à Kubernetes à l'aide de modules d'extension (plugins).
Par exemple, si vous travaillez avec Azure, le gestionnaire de contrôleur cloud sert d'intermédiaire entre le plan de contrôle Kubernetes et l'API Azure. Il fournit des fonctionnalités supplémentaires et une intégration avec les services Azure, tels que Azure Virtual Machines, Azure Load Balancer et Azure Disk Storage.
De même, il peut s'intégrer à d'autres fournisseurs de cloud (Amazon Web Services, Google Cloud Platform, etc.), ce qui permet à Kubernetes de s'adapter à l'environnement de cloud choisi.
Worker nodes
Les nœuds de travail sont des composants critiques dans une architecture Kubernetes car ils aident à l'exécution des applications conteneurisées.
Composants des nœuds de travail Kubernetes
Les nœuds de travail sont les principales unités d'exécution d'un cluster Kubernetes, où s'exécutent les charges de travail réelles. Chaque nœud de travailleur peut héberger plusieurs pods, chacun contenant un ou plusieurs conteneurs s'exécutant à l'intérieur. Chaque nœud de travailleur est constitué de trois composants responsables de la planification et de la gestion de ces pods :
kubelet
Le kubelet est un composant essentiel qui s'exécute sur chaque nœud du cluster Kubernetes. Il agit en tant qu'agent responsable de l'enregistrement des nœuds ouvrier auprès du serveur API et du travail avec le podSpec principalement à partir du serveur API.
Le kubelet crée, modifie et supprime des conteneurs pour le pod. En outre, il gère les sondes de vivacité, de préparation et de démarrage. Il monte également des volumes en lisant la configuration du pod et en créant les répertoires.
Le kubelet peut accepter des podSpec provenant de diverses sources, notamment d'un fichier, d'un point d'extrémité HTTP et d'un serveur HTTP. Il utilise également le moteur d'exécution de conteneurs du nœud pour extraire des images, exécuter des conteneurs, etc.
Le Kubelet démarre l'api-serveur, le planificateur et le gestionnaire de contrôleur en tant que pods statiques tout en démarrant le plan de contrôle. Le kubelet est essentiel pour gérer les conteneurs et s'assurer que le pod est dans l'état souhaité.
kube-proxy
Pour comprendre Kube-proxy, vous devez connaître les objets Kubernetes Service et Endpoint. Les objets Service exposent les pods au trafic, et les objets Endpoint contiennent les adresses IP et les ports des pods. Kube-proxy est un composant qui met en œuvre des services pour les pods.
Lorsque vous utilisez un service pour exposer les modules, Kube-proxy crée des règles de réseau pour envoyer le trafic aux modules regroupés sous l'objet Service. Kube-proxy utilise les protocoles UDP, TCP et SCTP, mais pas HTTP, et s'exécute sur chaque nœud en tant que daemonset.
Kube-proxy communique avec le serveur API pour obtenir des détails sur les services et leurs IP et ports de pods respectifs. Il surveille les changements de service et les points de terminaison, puis utilise différents modes pour créer ou mettre à jour les règles de routage du trafic vers les pods derrière un service.
Ces modes sont les suivants : IPTables, IPVS, Userspace et Kernelspace. Lorsqu'il utilise le mode IPTables, Kube-proxy gère le trafic avec des règles IPtable et sélectionne aléatoirement un pod backend pour l'équilibrage de la charge.
Container runtime
Tout comme le Java Runtime (JRE) est nécessaire pour exécuter les programmes Java, le conteneur runtime est essentiel pour exécuter les conteneurs. L'exécution des conteneurs est responsable de diverses tâches, telles que l'extraction d'images des registres de conteneurs, l'allocation et l'isolation des ressources pour les conteneurs et la gestion de l'ensemble du cycle de vie d'un conteneur sur un hôte.
Kubernetes interagit avec les runtimes de conteneurs par le biais de l'interface Container Runtime Interface (CRI), qui définit l'API pour la création, le démarrage, l'arrêt et la suppression des conteneurs et la gestion des images et des réseaux de conteneurs.
L'Open Container Initiative (OCI) est un ensemble de normes pour les formats de conteneurs et les moteurs d'exécution. Kubernetes prend en charge plusieurs moteurs d'exécution de conteneurs conformes à l'OCI, tels que CRI-O, Docker Engine et containerd.
L'agent kubelet interagit avec l'exécution du conteneur à l'aide des API CRI pour gérer le cycle de vie d'un conteneur et fournit toutes les informations relatives au conteneur au plan de contrôle.
Composants complémentaires du cluster Kubernetes
Pour garantir la fonctionnalité complète de votre cluster Kubernetes, il est essentiel d'intégrer des composants complémentaires aux composants principaux. Le choix des composants complémentaires dépend en grande partie des exigences et des cas d'utilisation de votre projet.
Parmi les composants complémentaires les plus courants dont vous pourriez avoir besoin dans un cluster, citons CNI Plugin pour la mise en réseau, CoreDNS pour le serveur DNS, Metrics Server pour les mesures de ressources et Web UI pour la gestion des objets via l'interface Web.
En activant ces add-ons, vous pouvez considérablement améliorer les performances et les fonctionnalités de votre cluster Kubernetes.
Plugin CNI
Container Networking Interface (CNI) est un moyen de créer des connexions réseau pour les conteneurs, et il fonctionne avec de nombreux outils d'orchestration différents, pas seulement Kubernetes. Les organisations ont des besoins variés en ce qui concerne la mise en réseau des conteneurs, comme la sécurité et l'isolation.
De nombreuses entreprises ont créé des solutions pour répondre à ces besoins en utilisant CNI. Ces solutions sont appelées plugins CNI, et vous pouvez en choisir un en fonction de vos besoins.
Voici comment les choses fonctionnent lors de l’utilisation de plugins CNI avec Kubernetes : chaque pod (un conteneur ou un groupe de conteneurs) reçoit une adresse IP unique. Ensuite, le plug-in CNI connecte les pods ensemble, quel que soit l’endroit où ils se trouvent. Cela signifie que les pods peuvent communiquer entre eux même s’ils se trouvent sur des nœuds différents.
Il existe de nombreux plugins CNI différents, y compris des plus populaires comme Calico, Flannel et Weave Net. Il est essentiel de choisir celui qui convient à vos besoins spécifiques. La mise en réseau de conteneurs est une énorme responsabilité, mais les plug-ins CNI facilitent sa gestion.
