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
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
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.
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
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
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.
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 Docker, containerd, CRI-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
