Architecture de Kubernetes

Sous le capot : dévoiler le fonctionnement interne de K8s

Après avoir exploré pourquoi l'orchestration est nécessaire et découvert les origines et objectifs de Kubernetes dans le chapitre précédent, il est temps de plonger plus profondément. Comment Kubernetes parvient-il concrètement à gérer des milliers de conteneurs sur un parc de machines ? Quelle est la machinerie interne qui lui permet d'automatiser, de scaler et de maintenir nos applications ? Ce chapitre est dédié à la dissection de l'architecture de Kubernetes.

Comprendre l'architecture d'un cluster K8s est fondamental. C'est la clé pour déployer des applications efficacement, diagnostiquer les problèmes, sécuriser le système et optimiser les performances. Sans cette compréhension, interagir avec Kubernetes revient à conduire une voiture sans savoir ce qu'il y a sous le capot – possible, mais limité et potentiellement risqué en cas de pépin.

Nous allons décomposer un cluster Kubernetes en ses deux principales parties : le Control Plane (le cerveau de l'opération) et les Noeuds Workers (là où les applications s'exécutent réellement). Cette distinction est la première étape pour appréhender la distribution des responsabilités au sein du système.

Les maîtres et les travailleurs : composants essentiels

Le Control Plane est le centre névralgique du cluster. C'est lui qui prend les décisions globales (comme le scheduling des conteneurs), détecte et répond aux événements du cluster, et stocke l'état global du système. Nous examinerons en détail ses composants vitaux :

• API Server : La porte d'entrée pour toutes les interactions, exposant l'API Kubernetes.
• etcd : La base de données clé-valeur distribuée et fiable où est stocké l'état complet du cluster (configuration, état désiré, état actuel...).
• Scheduler : Le composant qui observe les nouveaux Pods créés et leur assigne un Noeud Worker approprié pour leur exécution.
• Controller Manager(s) : Le cerveau qui exécute les boucles de contrôle pour faire correspondre l'état actuel à l'état désiré (par exemple, s'assurer qu'il y a le bon nombre de réplicas pour un déploiement). Il existe plusieurs contrôleurs, souvent regroupés en un seul processus (kube-controller-manager) et un spécifique au cloud (cloud-controller-manager).

Les Noeuds Workers, quant à eux, sont les machines (physiques ou virtuelles) où vos conteneurs applicatifs sont effectivement lancés et exécutés. Chaque noeud worker exécute des agents essentiels qui le maintiennent opérationnel et communiquent avec le Control Plane :

• Kubelet : L'agent principal sur chaque noeud, qui communique avec l'API Server et s'assure que les conteneurs décrits dans les PodSpecs sont en cours d'exécution et en bonne santé.
• Kube-proxy : Un proxy réseau qui s'exécute sur chaque noeud et maintient les règles réseau permettant la communication vers les Pods depuis l'intérieur ou l'extérieur du cluster (il implémente une partie du concept de Service Kubernetes).
• Container Runtime : Le logiciel responsable de l'exécution effective des conteneurs (par exemple, Docker, containerd, CRI-O). Kubernetes s'interface avec lui via la Container Runtime Interface (CRI).

Interconnexions : réseau, stockage et flux de communication

Au-delà des composants principaux du Control Plane et des Workers, l'architecture de Kubernetes repose sur des systèmes externes essentiels, notamment pour le réseau et le stockage. Nous introduirons le rôle crucial des interfaces standardisées :

• Container Network Interface (CNI) : Une spécification qui permet à différents plugins réseau de s'intégrer à Kubernetes pour fournir la connectivité entre les Pods et implémenter les politiques réseau.
• Container Storage Interface (CSI) : Une spécification similaire pour le stockage, permettant à divers systèmes de stockage (fournisseurs cloud, solutions on-premise) de s'intégrer pour fournir des volumes persistants aux conteneurs.

Enfin, nous aborderons la manière dont tous ces composants communiquent entre eux. Essentiellement, la plupart des communications transitent par l'API Server, qui agit comme un hub central. Le Kubelet communique avec l'API Server, le Scheduler communique avec l'API Server pour obtenir des informations et y inscrire ses décisions, les Contrôleurs surveillent l'état via l'API Server et y effectuent des changements, etc. Comprendre ces flux est vital pour le dépannage.

Ce chapitre vous fournira une carte détaillée de l'anatomie d'un cluster Kubernetes. Fort de cette connaissance, vous serez bien mieux équipé pour comprendre comment les objets Kubernetes que nous verrons plus tard (Pods, Services, Deployments...) prennent vie et interagissent au sein de cette infrastructure complexe mais élégante.