Composants des Noeuds Workers (Kubelet, Kube-proxy, Container Runtime)

Sur le terrain : les agents du Noeud Worker

Si le Control Plane est le cerveau, les Noeuds Workers sont les bras exécutants de Kubernetes. Ce sont les machines (physiques ou virtuelles) où les conteneurs de vos applications prennent vie. Pour qu'un noeud puisse participer au cluster et exécuter des charges de travail, il doit exécuter plusieurs agents essentiels qui communiquent avec le Control Plane et gèrent les ressources locales.

Ce chapitre se concentre sur les trois composants fondamentaux présents sur chaque Noeud Worker : le Kubelet, Kube-proxy et le Container Runtime. Comprendre leur rôle individuel et leur interaction est crucial pour appréhender comment les Pods sont effectivement lancés, mis en réseau et gérés au niveau de chaque machine du cluster.

Kubelet : l'agent principal du noeud

Le Kubelet est l'agent le plus important s'exécutant sur chaque noeud worker (et parfois même sur les noeuds master dans certaines configurations). Il agit comme le représentant local du Control Plane sur le noeud.

Ses responsabilités principales sont multiples :

• Enregistrement auprès de l'API Server : Au démarrage, le Kubelet s'enregistre auprès de l'API Server, se déclarant ainsi comme un nouveau noeud prêt à recevoir des tâches.
• Surveillance des Pods assignés : Il surveille l'API Server pour les Pods qui ont été assignés à son noeud par le Scheduler (`spec.nodeName` correspondant à son propre nom).
• Gestion du cycle de vie des Pods : Pour chaque Pod assigné, le Kubelet lit sa spécification (PodSpec) et demande au Container Runtime de télécharger les images nécessaires et de démarrer les conteneurs définis. Il s'assure ensuite que ces conteneurs restent en cours d'exécution et en bonne santé.
• Exécution des sondes (Probes) : Il est responsable de l'exécution des sondes de vivacité (liveness probes) et de disponibilité (readiness probes) configurées pour les conteneurs, afin de déterminer leur état de santé et de prendre des mesures si nécessaire (redémarrage, retrait du service).
• Gestion des volumes : Il monte les volumes (stockage) définis dans les PodSpecs à l'intérieur des conteneurs.
• Rapport d'état : Il rapporte régulièrement l'état du noeud (ressources disponibles, conditions) et l'état des Pods qu'il gère à l'API Server.

Le Kubelet ne gère que les Pods qui lui sont spécifiquement assignés par le Control Plane. Il n'intervient pas dans la décision de placement (rôle du Scheduler).

Kube-proxy : le magicien du réseau de services

Le Kube-proxy est un proxy réseau qui s'exécute sur chaque noeud du cluster. Son rôle principal est de rendre possible l'abstraction des Services Kubernetes. Un Service fournit une adresse IP et un nom DNS stables pour accéder à un ensemble de Pods (qui eux ont des IPs éphémères). Kube-proxy est ce qui permet au trafic destiné à l'IP d'un Service d'être correctement routé vers l'un des Pods backend sains associés à ce Service.

Comment fait-il ? Kube-proxy surveille l'API Server pour les changements concernant les objets Service et Endpoints (ou EndpointSlices, qui listent les IPs des Pods associés à un Service). En fonction de ces informations, il modifie les règles réseau sur le noeud hôte pour intercepter le trafic destiné aux IPs virtuelles des Services (ClusterIPs) ou aux ports ouverts sur le noeud (NodePorts) et le rediriger vers les bonnes adresses IP des Pods.

Kube-proxy peut opérer selon différents modes :

• iptables (le plus courant) : Il configure des règles `iptables` (le pare-feu Linux) pour capturer le trafic des Services et effectuer la redirection et l'équilibrage de charge (simple round-robin). C'est robuste mais peut devenir lent avec un très grand nombre de Services.
• IPVS (IP Virtual Server) : Utilise IPVS, une fonctionnalité du noyau Linux conçue pour l'équilibrage de charge. Offre de meilleures performances et plus d'algorithmes d'équilibrage de charge qu'iptables à grande échelle.
• Userspace (historique, non recommandé) : Un mode plus ancien où Kube-proxy agissait comme un vrai proxy en espace utilisateur. Moins performant.
• Kernelspace (via eBPF - émergent) : Certaines implémentations CNI (comme Cilium) peuvent prendre en charge les Services directement dans le noyau via eBPF, rendant Kube-proxy potentiellement superflu dans ces cas.

Il est important de noter que Kube-proxy ne fait généralement pas transiter le trafic applicatif lui-même (sauf en mode userspace). Il configure les règles du système d'exploitation pour que le noyau puisse effectuer le routage directement.

Container Runtime : le moteur d'exécution

Le Container Runtime (ou moteur de conteneurs) est le logiciel fondamental responsable de l'exécution effective des conteneurs. C'est lui qui télécharge les images, démarre, arrête les conteneurs et gère leurs ressources de bas niveau.

Kubernetes lui-même ne lance pas directement les conteneurs. Il délègue cette tâche au Container Runtime via une API standardisée appelée Container Runtime Interface (CRI). Le Kubelet communique avec le runtime via cette interface. L'avantage de la CRI est que Kubernetes n'est pas lié à un runtime spécifique ; il peut fonctionner avec n'importe quel runtime qui implémente l'interface CRI.

Les Container Runtimes les plus couramment utilisés avec Kubernetes incluent :

• containerd : Un runtime de conteneur standard de l'industrie, issu du projet Docker et maintenant un projet gradué de la CNCF. Il est souvent considéré comme un excellent choix pour Kubernetes en raison de sa performance et de sa faible empreinte.
• CRI-O : Un autre runtime léger spécifiquement créé pour Kubernetes et également projet de la CNCF. Il implémente uniquement la CRI.
• Docker Engine : Historiquement le runtime le plus utilisé, mais Kubernetes a déprécié le support direct via le "dockershim" (la couche de compatibilité CRI intégrée au Kubelet). Pour utiliser Docker Engine avec les versions récentes de Kubernetes, il faut passer par un adaptateur externe comme `cri-dockerd` qui traduit les appels CRI en appels à l'API Docker.

Le choix du runtime peut avoir des implications sur les performances, la sécurité et les fonctionnalités disponibles, mais grâce à la CRI, l'expérience utilisateur de Kubernetes reste largement cohérente quel que soit le runtime choisi.

Collaboration sur le noeud

Ensemble, Kubelet, Kube-proxy et le Container Runtime forment une équipe efficace sur chaque Noeud Worker. Le Kubelet reçoit les ordres du Control Plane via l'API Server, demande au Container Runtime d'exécuter les conteneurs, surveille leur santé, et Kube-proxy assure que ces conteneurs peuvent être atteints via les Services Kubernetes. Cette collaboration permet à chaque noeud de contribuer de manière fiable à la puissance de calcul et à la connectivité du cluster Kubernetes.