Communication au sein du cluster

Le réseau de neurones du cluster : l'API Server comme hub central

Un cluster Kubernetes est un système distribué par nature, avec des composants répartis sur plusieurs machines (Control Plane et Noeuds Workers). Pour fonctionner comme un tout cohérent, ces composants doivent communiquer de manière fiable et sécurisée. Comprendre ces flux de communication est essentiel pour le dépannage et la sécurisation du cluster.

Au coeur de cette communication se trouve le kube-apiserver. Il agit comme le hub central par lequel transitent la grande majorité des interactions. Les autres composants du Control Plane (Scheduler, Controller Manager) et les agents sur les noeuds workers (Kubelet, Kube-proxy) interagissent principalement avec l'API Server pour obtenir des informations, signaler leur état ou demander des actions.

Cette architecture centralisée autour de l'API Server simplifie le modèle de communication et permet d'appliquer de manière cohérente l'authentification, l'autorisation et l'audit pour toutes les opérations du cluster.

Flux de communication principaux

Examinons les principaux chemins de communication au sein d'un cluster Kubernetes :

• Autres composants du Control Plane vers l'API Server :
  - Le Scheduler interroge l'API Server pour trouver des Pods non assignés et écrit ses décisions (assignation d'un noeud) via l'API Server.
  - Les Controller Managers (kube-controller-manager, cloud-controller-manager) utilisent l'API Server pour surveiller ("watch") l'état des ressources (Deployments, Services, Nodes, etc.) et envoient des requêtes à l'API Server pour créer, mettre à jour ou supprimer des objets afin de faire converger l'état réel vers l'état désiré.
  - L'API Server vers etcd : C'est la seule communication directe avec la base de données etcd. L'API Server lit et écrit l'état du cluster dans etcd pour persister toutes les configurations et états. Cette communication est critique et doit être sécurisée (généralement via mTLS).
• Control Plane vers Noeuds Workers (API Server vers Kubelet) :
  Historiquement, l'API Server pouvait initier des connexions vers le Kubelet pour récupérer des logs, exécuter des commandes (`kubectl exec`) ou transférer des fichiers (`kubectl cp`). Cependant, pour des raisons de sécurité (éviter d'exposer l'API du Kubelet directement), les modèles plus récents favorisent des mécanismes comme le "Konnectivity service" (anciennement `apiserver-network-proxy`) où l'API Server agit comme un proxy, et c'est le Kubelet (ou un agent Konnectivity sur le noeud) qui initie une connexion sortante persistante vers le Control Plane. L'API Server utilise ensuite ce tunnel pour atteindre le Kubelet.
• Noeuds Workers vers Control Plane (Kubelet/Kube-proxy vers API Server) :
  - Le Kubelet communique constamment avec l'API Server pour : s'enregistrer, envoyer l'état du noeud (heartbeats, conditions, capacité), rapporter l'état des Pods qu'il gère, et surveiller les Pods qui lui sont assignés.
  - Le Kube-proxy surveille l'API Server pour détecter les changements dans les objets Services et Endpoints/EndpointSlices afin de mettre à jour les règles réseau locales.
  Ces communications sont initiées par les composants du noeud worker vers l'API Server, ce qui est généralement plus facile à gérer du point de vue des pare-feux.
• Kubelet vers Container Runtime : Le Kubelet communique avec le Container Runtime (containerd, CRI-O) via une socket UNIX locale en utilisant le protocole CRI pour demander la création, le démarrage, l'arrêt et la suppression de conteneurs.
• Kubelet vers Conteneurs : Le Kubelet interagit directement avec les conteneurs en cours d'exécution pour réaliser les sondes de santé (liveness, readiness, startup probes) via HTTP, TCP ou en exécutant une commande à l'intérieur du conteneur.

Sécurité des communications

La sécurité est primordiale dans ces échanges. La plupart des communications, en particulier celles impliquant l'API Server, sont sécurisées à l'aide de TLS (Transport Layer Security) pour garantir le chiffrement et l'authenticité.

L'authentification est également cruciale :

• L'API Server authentifie ses clients. Les Kubelets s'authentifient généralement via des certificats clients TLS. Les autres composants du Control Plane et Kube-proxy utilisent également des certificats ou des tokens ServiceAccount.
• Le Kubelet peut également avoir une API HTTPS, et l'API Server doit s'authentifier auprès du Kubelet (généralement via un certificat client) lorsqu'il initie une connexion (ou via le tunnel Konnectivity).

Une configuration correcte des certificats TLS et des mécanismes d'authentification/autorisation (comme RBAC) est indispensable pour protéger le cluster contre les accès non autorisés et les attaques.

En conclusion, bien que l'API Server soit le hub principal, la communication dans Kubernetes implique un réseau complexe d'interactions entre les différents composants. Ces communications sont conçues pour être robustes et sécurisées, permettant au cluster de fonctionner de manière coordonnée pour gérer efficacement les applications conteneurisées. La compréhension de ces flux est une étape clé pour diagnostiquer les problèmes de connectivité ou de performance au sein du cluster.