Quels sont les principaux composants de l’architecture Kubernetes et à quoi chacun sert-il ?

Un cluster Kubernetes se compose 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 dans des Pods. Tout cluster a besoin d’au moins un nœud de travail pour exécuter des Pods.

Conceptuellement, Kubernetes est déclaratif : vous soumettez l’état souhaité au serveur API (stocké dans etcd), et des contrôleurs exécutent en continu des boucles de réconciliation qui surveillent les différences et agissent pour rapprocher l’état réel de l’état souhaité.

Composants du plan de contrôle

Le plan de contrôle prend les décisions globales concernant le cluster (comme la planification) et réagit aux événements du cluster. En production, il fonctionne généralement sur plusieurs machines pour assurer la haute disponibilité.

• kube-apiserver — le composant central qui expose l’API HTTP de Kubernetes. Il constitue le front-end du plan de contrôle et le point de contact unique : toute l’authentification, l’autorisation, la validation des requêtes et les lectures/écritures de l’état du cluster passent par lui. Il s’adapte horizontalement. Dans les déploiements normaux, c’est le seul composant Kubernetes qui lit et écrit directement l’état du cluster dans etcd ; tous les autres composants interagissent avec l’état via le serveur API.
• etcd — un magasin clé-valeur cohérent et hautement disponible utilisé comme stockage de base de Kubernetes pour toutes les données du cluster : configuration, état et métadonnées. etcd est obligatoire et constitue la source de vérité unique — le perdre signifie perdre tout l’état du cluster, il doit donc fonctionner avec quorum (un nombre impair de membres) et être sauvegardé régulièrement.
• kube-scheduler — surveille les Pods qui ne sont pas encore liés à un nœud et assigne chaque Pod à un nœud approprié, en tenant compte des ressources, des contraintes et des politiques.
• kube-controller-manager — exécute des contrôleurs qui implémentent le comportement de l’API Kubernetes (par exemple, Node controller, Job controller, EndpointSlice controller). Chaque contrôleur surveille l’état souhaité et rapproche l’état réel de celui-ci.
• cloud-controller-manager (facultatif) — s’intègre au fournisseur de cloud sous-jacent, en isolant la logique spécifique au cloud des composants centraux de Kubernetes.

Composants des nœuds

Ils s’exécutent sur chaque nœud, maintiennent les Pods en fonctionnement et fournissent l’environnement d’exécution.

• kubelet — l’agent qui s’assure que les Pods sont en cours d’exécution, y compris leurs conteneurs. Il surveille le serveur API pour les affectations de Pods, démarre les conteneurs via le runtime, monte les volumes, exécute les sondes de vivacité/de disponibilité et signale l’état du nœud.
• kube-proxy — met en œuvre le réseau des Services en programmant des règles iptables ou IPVS sur les nœuds afin que le trafic vers un Service soit transféré vers les bonnes adresses IP des Pods. Il est marqué comme facultatif parce que certains plugins CNI (par exemple Cilium en mode eBPF) prennent en charge cette tâche, mais dans un cluster standard il est requis.
• Runtime de conteneurs — le logiciel responsable de l’exécution des conteneurs (containerd, CRI-O, etc., via l’interface CRI).

Addons

Les addons étendent les fonctionnalités du cluster : DNS du cluster (CoreDNS par défaut), l’interface web Dashboard, la surveillance des ressources des conteneurs et la journalisation à l’échelle du cluster.

Suivi courant : toutes les communications passent par le serveur API — le scheduler, les contrôleurs et les kubelets ne font que le surveiller et réagir — ce qui fait du serveur API le hub critique du cluster.