Cluster Kubernetes : architecture et composants de base

Photo of author
par KrustyHack
publié le
mis à jour le

Dans cette partie, nous allons rapidement voir à quoi ressemble un cluster Kubernetes et quels sont les éléments de base qui le compose. Sans rentrer dans les détails, nous allons analyser ses composants primordiaux.

Ci-dessous l’architecture simplifiée d’un cluster Kubernetes avec un nœud master aussi appelé Control Plane, et deux nœuds de travail également appelés workers :

Kubernetes Architecture

Kubernetes Architecture

Le Control Plane Kubernetes

Le Control Plane Kubernetes est l’élément central d’un cluster K8S. Sans lui (ou eux, car un Control Plane peut être formé de plusieurs nœuds) le cluster ne peut pas fonctionner. Il est l’élément le plus important d’un cluster.

Un Control Plane Kubernetes est une machine (ou plusieurs), virtuelle ou non, qui gère et commande le cluster dont il est responsable. Il peut y avoir un ou plusieurs noeuds Control Plane dans un cluster, sachant qu’en production il est conseillé d’en avoir plusieurs pour éviter le downtime lors de mises à jour ou d’incidents.

Kubernetes Control Plane

Kubernetes Control Plane

Les composants d’un Control Plane Kubernetes

Les composants du Control Plane ont la responsabilité de prendre des décisions, de détecter et de réagir aux évènements du cluster, comme par exemple d’instancier de nouveaux pods (nous verrons ce que sont les pods plus tard, mais pour faire court, ce sont des regroupements de un ou plusieurs containers).

Les composants du Control Plane peuvent être exécutés sur n’importe laquelle des machines du cluster MAIS pour la simplicité de mise en oeuvre en général on les rassemble tous sur une seule machine (ou plusieurs pour avoir de la HA) qu’on appelle donc Control Plane.

Il est également possible, et même recommandé en production, d’avoir des clusters multi Control Plane pour de la haute disponibilité. Car oui, si le Control Plane explose (ou à minima ne répond plus), le cluster n’est plus utilisable.

À LIRE  Kubernetes External Secrets : test rapide

Pour fonctionner, un Control Plane K8S utilise différents éléments tels que :

  • Le kube-apiserver 
  • Le kube-scheduler
  • Le kube-controller-manager
  • Le nœud ETCD
  •  Le cloud-controller-manager

Le kube-apiserver

L’API Server est un composant qui expose l’API Kubernetes. C’est l’élément « frontal » d’un Control Plane Kubernetes et c’est lui qui reçoit tous les appels et demandes, externes ou internes.

L’élément qui représente la mise en place de cette API est le kube-apiserver. Celui-ci est fait pour être scalable horizontalement (donc avoir plusieurs instances en parallèle). Il est donc possible de faire tourner plusieurs instances kube-apiserver et de load balancer le trafic entre les différentes instances.

Le kube-scheduler

Le kube-scheduler est le composant responsable de regarder si de nouveaux pods sont créés avec aucun nœud (de VM par exemple) d’assigné. Il choisit alors selon les contraintes qui lui sont imposées un nœud sur lequel les pods peuvent être démarrés et exécutés.

Plusieurs facteurs peuvent être pris en compte pour l’assignation des pods sur des nœuds : les prérequis type CPU et mémoire, les contraintes hardware/software/…, les affinités et anti-affinités, etc… Nous verrons ça plus tard.

Le kube-controller-manager

Le kube-controller-manager, comme son nom l’indique, exécute et fait tourner les processus de contrôle du cluster.

En théorie, chaque controller (il y en a plusieurs avec chacun un rôle spécifique) est un processus distinct, mais pour simplifier ils sont tous compilés en un seul binaire et tournent sous un seul processus.

On peut retrouver :

  • Node Controller : responsable de la gestion des nœuds du cluster et de leur lifecycle
  • Replication Controller : responsable du maintien du nombre de pods pour chaque objet de réplication dans le cluster (là aussi, nous verrons cela plus tard)
  • Endpoints Controller : fais en sorte de joindre correctement les services et les pods 
  • Service Account & Token Controllers : créent tout simplement les comptes et les tokens d’accès à l’API pour les nouveaux namespaces Kubernetes
À LIRE  ETCD : découverte et premiers pas

ETCD

ETCD est une base de données de type clé/valeur à haute disponibilité utilisée pour stocker les données du cluster. Si ETCD disparaît, le cluster est totalement perdu. C’est pour cela qu’il est fortement conseillé de sauvegarder ses données et d’avoir un cluster ETCD.

Le cloud-controller-manager

Composant spécifique avec une logique propre à chaque plateforme cloud, le Cloud Controller Manager permet d’interconnecter votre cluster Kubernetes avec l’API de votre provider cloud. Cet élément n’exécute que des contrôleurs spécifiques à votre provider. Si votre cluster Kubernetes est on-premise ou sur votre propre ordinateur, celui-ci n’aura pas de Cloud Controller Manager.

Tout comme le kube-controller-manager, le cloud-controller-manager est un ensemble d’éléments logiques imbriqués dans un seul binaire afin d’en simplifier l’utilisation et la maintenance. Il est également possible de le scaler horizontalement afin d’améliorer les performances ou d’éviter le downtime suite à des pannes.

Voici les controllers qui peuvent avoir des dépendances au Cloud Provider :

  • Node controller : contrôler si un nœud a été supprimé chez votre provider si celui-ci ne répondait plus
  • Route controller : pour mettre en place les routes
  • Service controller : pour créer, mettre à jour et supprimer les éléments de type load balancer

Le nœud de travail Kubernetes

Le nœud de travail Kubernetes, aussi appelé worker, est une machine qui accueille la charge de travail (comme son nom l’indique). Elle exécute donc les pods qui lui sont attribués par le Control Plane.

Kubernetes Worker

Kubernetes Worker

Les composants d’un nœud de travail

Les composants des nœuds tournent sur chaque nœuds du cluster et permettent donc l’exécution et le maintien des pods et des containers.

Pour fonctionner, un nœud de travail utilise différents éléments tels que :

  • Le kubelet
  • Le kube-proxy
  • Le container runtime

Le kubelet

Kubelet est un agent qui s’exécute sur chaque nœud du cluster et qui fait en sorte que les containers tournent bien dans les pods.

À LIRE  CI/CD Series : Installer Jenkins X sur Kubernetes

Kubelet examine les spécifications de chaque pod et fait en sorte que les containers définis dans ces PodSpecs tournent et sont en bonne santé. Par contre, le kubelet ne gère pas les containers qui n’ont pas été créés par Kubernetes.

Le kube-proxy

Le kube-proxy est un proxy (ah bon ?!) qui tourne sur chaque nœud du cluster. Il maintient les règles réseau sur les nœuds. Ces règles permettent la communication vers les pods depuis l’intérieur ou l’extérieur de votre cluster.

Si disponible, kube-proxy utilise la couche de filtrage des paquets du système d’exploitation, sinon il le fait lui-même.

Le container runtime

Le container runtime est un élément software responsable de l’exécution des containers. Pour rappel, Kubernetes définit un ensemble de 1 ou X containers avec l’élément pod (nous en reparlerons plus tard).

Kubernetes supporte plusieurs container runtimes tels que DockercontainerdCRI-O, et toute implémentation du Kubernetes Container Runtime Interface.

Voilà pour la présentation globale et basique d’un cluster Kubernetes et de son architecture. Nous verrons plus en détail chaque composants d’un cluster dans les prochains articles.

Mes vidéos sur Kubernetes

Laisser un commentaire