Comprendre l'architecture de clusters sur laquelle repose Kubernetes

Architecture d'un maître : les pods kube-system

Un maître héberge le plan de contrôle Kubernetes : un ensemble de services qui administrent et orchestrent l'ensemble du cluster. Ces services se trouvent sous la forme de pods dans l'espace de nommage (namespace) "kube-system".

Serveur API

Le serveur API est la partie centrale du plan de contrôle Kubernetes, c'est une API REST qui est le point d'entrée pour envoyer des commandes au cluster. Vous interagissez avec ce serveur lorsque vous écrivez des commandes kubectl. Il communique avec les différents composants des maîtres et des nœuds pour appliquer l'état souhaité par l'utilisateur.

ETCD

L’ETCD est une base de données à haute disponibilité où l'API stocke l'état du cluster. C'est également là que sont stockées les informations d'identification requises pour authentifier les requêtes que vous envoyez à l'API. Afin d'avoir un cluster Kubernetes résilient, il devrait y avoir au moins 3 instances ETCD.

Scheduler

Le scheduler surveille les ressources disponibles sur les différents nœuds; et planifie les pods et autres ressources Kubernetes vers les nœuds en tenant compte de cela. Le planificateur s'assure que la charge de travail est répartie uniformément sur l'ensemble du cluster.

Controller Manager

Le Controller Manager gère l'orchestration du cluster. Il supervise les nœuds qui quittent et rejoignent le cluster, et s'assure que l'état actuel du cluster est toujours en accord avec l'état souhaité stocké dans l’ETCD. En cas de défaillance d'un nœud, il instanciera de nouveaux pods sur les nœuds restants pour qu'ils aient toujours le nombre de répliques voulu.

Où tournent vos pods : les nœuds

Les nœuds forment une plateforme de déploiement unique pour les ressources Kubernetes du cluster. Ils hébergent plusieurs pods systèmes qui leur permettent de communiquer avec les maîtres, et d'exécuter des applications utilisateur dans des pods.

Container Runtime 

Le Container Runtime est le service qui gère les conteneurs. Dans la plupart des cas, il s'agit de docker, mais Kubernetes supporte également d'autres Container Runtimes tels que rkt ou containerd.

Kubelet

Kubelet est le service qui interagit avec l'API et applique la configuration des ressources stockées dans l’ETCD sur le nœud. Il communique également au maître l’état du nœud. Comme il est en charge de la gestion des pods, l'agent Kubelet est également présent sur les maîtres.

Interface réseau pour conteneurs

Le CNI (Container Network Interface) crée des réseaux virtuels sur l'ensemble du cluster. Cela permet aux conteneurs et aux pods de communiquer quel que soit le nœud sur lequel ils fonctionnent. Il fournit des interfaces réseau virtuelles et des adresses IP locales aux pods.

Kube DNS

Le service DNS de Kubernetes permet aux pods de communiquer entre eux en utilisant leur nom ou leur FQDN (Fully Qualified Domain Name) au lieu de leur IP locale.

Kube Proxy

Le service Proxy de Kubernetes agit comme un répartiteur de charge. Il achemine le trafic réseau et permet d’exposer les services à l'extérieur du cluster.

Que se passe-t-il lorsque vous déployez une application ?

Passons maintenant à une situation concrète et examinons ce qu’il se passe exactement lorsque vous déployez votre application conteneurisée sur un cluster Kubernetes. Vous envoyez la description de votre application et sa configuration à l'API du maître via la ligne de commande kubectl. L'API stocke cette configuration dans l'ETCD, et le Planificateur assigne vos pods d'application aux nœuds.

Sur les nœuds, Kubelet reçoit la description de ses pods programmés et le Conteneur Runtime les instancie. Kube proxy, l'interface réseau de conteneurs (CNI) et le DNS kube assurent alors que les pods créés ont un accès réseau et peuvent communiquer avec les pods du nœud et à travers le cluster.

Si un pod est en erreur, il peut être redéployé sur n'importe quel nœud du cluster en suivant la même procédure.

La structure des clusters présentée dans cet article est assez standard, mais n'est pas la seule possible. Il existe des clusters avec un seul nœud qui héberge à la fois les composants d’un nœud classique, et ceux du maître. Il existe également des clusters à haute disponibilité où les composants du plan de contrôle sont répartis sur différents nœuds, et répliqués pour la résilience. Dans tous les cas, tous les composants énumérés ici sont toujours présents et interagissent les uns avec les autres comme expliqué ci-dessus.

Si vous voulez en savoir plus sur Kubernetes et son utilisation dans un environnement de production, vous pouvez consulter nos autres articles et suivre Theodo Cloud sur X.