Fonctionnement du control plan Kubernetes

Mise à jour : 17/02/2025

Dans l’introduction sur l’architecture de Kubernetes, vous avez appris qu’un cluster Kubernetes repose sur une architecture bien huilée. Mais alors, qu’est-ce qui orchestre tout cela en coulisses ? C’est là qu’intervient le control plan (controle plane), le cerveau du cluster.

Pour rappel, le control plan gère tout ce qui se passe dans Kubernetes : il décide où déployer vos applications, surveille leur état, et s’assure que tout fonctionne comme prévu. C’est un peu comme le chef d’orchestre d’une symphonie : il ne joue pas les instruments lui-même, mais sans lui, rien ne serait harmonieux.

Mais qu’est-ce que cela signifie concrètement ? Quelles sont ses responsabilités exactes, et pourquoi est-il si indispensable pour le fonctionnement d’un cluster Kubernetes ?

Le rôle central du control plan

Le control plan est responsable de tout ce qui touche à la gestion et à l’orchestration des ressources dans Kubernetes. Concrètement, il remplit trois grandes missions :

Décision : où et comment les applications doivent être déployées dans le cluster ?
Gestion de l’état : s’assurer que les applications tournent comme prévu et corriger les écarts si nécessaire.
Exposition : fournir aux utilisateurs et aux outils une interface pour interagir avec le cluster.

Ces trois fonctions sont assurées par plusieurs composants clés qui collaborent pour maintenir le cluster opérationnel.

Les composants du control plan

Le control plan de Kubernetes est l’élément central de tout cluster. Il orchestre la gestion des applications, la surveillance de l’état des ressources, et les décisions automatisées. Pour bien comprendre son fonctionnement, il est essentiel de connaître ses composants clés. Voici un schéma simplifié et une explication détaillée de chaque composant :

architecture kubernetes high level

API Server : le point d’entrée

L’API Server est au cœur du control plan. C’est lui qui reçoit toutes les requêtes provenant des utilisateurs, des outils comme kubectl et même des composants internes. Il agit comme une interface centrale qui :

Valide les requêtes : vérifie que les demandes sont correctement formatées et que les utilisateurs sont autorisés à les exécuter.
Exécute les actions : après validation, il envoie les requêtes aux autres composants pour qu’ils prennent les mesures nécessaires.
Expose l’état du cluster : les utilisateurs peuvent interroger l’API pour obtenir des informations sur les objets Kubernetes (Pods, Services, etc.).

En résumé, l’API Server est le gardien du cluster. Sans lui, aucune interaction avec Kubernetes ne serait possible.

ETCD : la mémoire du cluster

etcd est une base de données clé-valeur distribuée qui stocke toutes les informations critiques du cluster. C’est dans etcd que réside la vérité sur :

La configuration du cluster.
L’état des ressources (comme les Pods, les nœuds, etc…).
Les secrets et autres données sensibles.

Pourquoi etcd est-il si important ? Parce qu’il garantit que le cluster est toujours synchronisé. Si un composant a besoin de savoir quelle est la configuration actuelle, il interroge etcd.

Scheduler : le stratège

Le scheduler est le composant chargé de décider où déployer chaque Pod. Pour cela, il analyse :

Les besoins des Pods (mémoire, CPU, stockage, etc.).
Les ressources disponibles sur chaque nœud.

Le scheduler ne fait qu’une chose, mais il la fait bien : il trouve le nœud idéal pour chaque Pod. Son rôle est essentiel pour garantir une utilisation optimale des ressources et éviter les surcharges.

Controller Manager : le chef d’orchestre

Le controller manager regroupe plusieurs controllers, chacun ayant un rôle précis. Ces controllers surveillent en permanence l’état du cluster et prennent des décisions correctives si nécessaire. Voici quelques exemples :

Node Controller : détecte quand un nœud est hors ligne et met à jour l’état du cluster en conséquence.
Replication Controller : s’assure que le bon nombre de réplicas est actif pour chaque déploiement.
Endpoints Controller : met à jour les endpoints des Services en fonction des Pods disponibles.

Chaque controller est comme une petite tâche automatisée qui veille à ce que tout se passe bien dans son domaine.

Cloud Controller Manager : l’intégrateur cloud

Ce composant est facultatif et uniquement utilisé si le cluster est déployé sur un cloud provider. Il permet de gérer les fonctionnalités spécifiques au cloud, comme :

La création automatique de load balancers.
La gestion des volumes de stockage cloud.
L’intégration des services réseau natifs du provider.

Le cloud controller manager facilite l’intégration entre Kubernetes et les infrastructures cloud.

Interaction entre les Composants du Control Plane Kubernetes

Le control plane de Kubernetes est un système complexe où plusieurs composants travaillent ensemble pour assurer le bon fonctionnement du cluster. Chaque composant a un rôle bien défini, mais c’est leur interaction qui permet à Kubernetes d’assurer l’orchestration efficace des conteneurs. Je vais détailler comment ces composants communiquent entre eux et assurent la cohérence du système.

1. Le Rôle Central de l’API Server

L’API Server est le cœur du control plane : c’est lui qui sert de point d’entrée unique pour toutes les interactions entre les composants internes et externes du cluster.

Interaction avec les autres composants :

etcd : L’API Server stocke et récupère l’état du cluster dans etcd, qui est la base de données centrale de Kubernetes.
Scheduler : L’API Server informe le scheduler lorsqu’un nouveau Pod doit être planifié.
Controller Manager : Les différents controllers surveillent les changements via l’API Server et déclenchent des actions correctives si nécessaire.
Cloud Controller Manager : Interagit avec l’API Server pour gérer les ressources cloud.

Exemple de flux de communication :

Un utilisateur crée un déploiement avec kubectl :
Terminal window
```
kubectl apply -f my-deployment.yaml
```
kubectl envoie la requête à l’API Server, qui la valide et l’enregistre dans etcd.
L’API Server informe ensuite le scheduler qu’un nouveau Pod doit être assigné à un nœud.
Une fois que le scheduler a trouvé un nœud approprié, il met à jour etcd avec cette information via l’API Server.
Le Controller Manager détecte cette mise à jour et s’assure que le Pod est bien démarré en envoyant les instructions nécessaires aux kubelets (agents sur les nœuds).

2. etcd : La Mémoire du Cluster

etcd est une base de données clé-valeur distribuée qui stocke l’état global du cluster. Tous les composants du control plane s’appuient sur etcd pour :

Lire les informations actuelles du cluster.
Sauvegarder les modifications apportées aux ressources Kubernetes.

Interaction avec les autres composants :

API Server : L’API Server est le seul composant qui communique directement avec etcd. Il y lit et écrit toutes les informations.
Scheduler et Controller Manager : Ces composants ne se connectent pas directement à etcd mais passent par l’API Server.

Exemple de flux de communication :

L’API Server enregistre une nouvelle configuration de Service dans etcd.
Le Controller Manager détecte cette mise à jour via l’API Server et ajuste la configuration des pods concernés.
Si un nœud tombe en panne, l’API Server met à jour etcd pour refléter cette perte, et le Node Controller (dans le Controller Manager) prend les actions correctives.

3. Scheduler : L’Assignateur de Pods

Le Scheduler est responsable de l’affectation des Pods aux nœuds du cluster. Il prend des décisions basées sur les contraintes de ressources et d’affinité définies.

Interaction avec les autres composants :

API Server : Le Scheduler reçoit la liste des Pods en attente d’assignation via l’API Server.
etcd : Indirectement, car l’API Server stocke l’affectation des Pods dans etcd.
Nodes : Une fois qu’un Pod est assigné à un nœud, le kubelet de ce nœud récupère les informations et démarre le conteneur.

Exemple de flux de communication :

Un nouvel objet Pod est créé et envoyé à l’API Server.
L’API Server sauvegarde cette nouvelle ressource dans etcd.
Le Scheduler interroge l’API Server pour obtenir la liste des Pods non assignés.
Après calcul, il choisit un nœud et met à jour la ressource Pod via l’API Server.
L’API Server enregistre la modification dans etcd, et le kubelet du nœud sélectionné récupère cette mise à jour pour lancer le conteneur.

4. Controller Manager : L’Automatisation du Cluster

Le Controller Manager contient plusieurs controllers qui s’assurent que l’état réel du cluster correspond à l’état désiré.

Interaction avec les autres composants :

API Server : Les controllers surveillent les changements d’état via l’API Server.
etcd : Les mises à jour sont enregistrées dans etcd par l’API Server.
Nodes : Certains controllers, comme le Node Controller, surveillent directement les nœuds et réagissent aux pannes.

Exemple de flux de communication :

Un Deployment spécifie qu’il doit y avoir trois réplicas d’un Pod.
Le Replication Controller détecte via l’API Server qu’il n’y a que deux Pods en cours d’exécution.
Il crée un nouveau Pod, que l’API Server enregistre dans etcd.
Le Scheduler assigne ce Pod à un nœud, et le kubelet démarre le conteneur.

5. Cloud Controller Manager : L’Intégration avec le Cloud

Si Kubernetes est déployé sur un Cloud Provider (AWS, GCP, Azure, etc.), le Cloud Controller Manager gère les interactions avec les services cloud.

Interaction avec les autres composants :

API Server : Il reçoit les requêtes pour créer des ressources cloud (ex: Load Balancers).
Cloud Provider : Il envoie les commandes à l’infrastructure cloud pour allouer des ressources.

Exemple de flux de communication :

Un utilisateur crée un Service de type LoadBalancer.
L’API Server enregistre cette demande dans etcd.
Le Cloud Controller Manager détecte cette mise à jour et demande au Cloud Provider de créer un Load Balancer.
Une fois créé, il met à jour l’API Server avec l’IP du Load Balancer.

Mise en place de notre Lab Kubernetes

Pour bien comprendre le fonctionnement d’un cluster Kubernetes, rien de tel que de mettre les mains dans le cambouis en créant votre propre environnement de test. Je vous propose de configurer un cluster à deux nœuds en utilisant Minikube avec le pilote KVM. Cela vous permettra d’expérimenter et de vous familiariser avec les commandes essentielles de Kubernetes.

Prérequis

Avant de commencer, assurez-vous d’avoir les éléments suivants installés sur votre machine :

Minikube : outil permettant de créer des clusters Kubernetes locaux.
kubectl : interface en ligne de commande pour interagir avec Kubernetes.
KVM/libvirt (Kernel-based Virtual Machine) : solution de virtualisation pour Linux.

Étapes d’installation

Vérification de l’installation de KVM et Libvirt Assurez-vous que KVM et Libvirt sont correctement installés et configurés sur votre système. Vous pouvez vérifier leur présence avec les commandes suivantes :
Terminal window
```
kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used
```
Terminal window
```
virsh list --all
Id   Name   State
--------------------
```
Si ces commandes renvoient des erreurs, il vous faudra installer ou reconfigurer KVM et Libvirt.
Démarrage du cluster Minikube avec le pilote KVM Une fois les prérequis en place, vous pouvez lancer un cluster Minikube avec deux nœuds en spécifiant le pilote KVM :
Terminal window
```
minikube start --driver=kvm2 --nodes=2 -p multinode-demo
```
- --driver=kvm2 : spécifie l’utilisation de KVM comme pilote de virtualisation.
- --nodes=2 : indique que le cluster doit comporter deux nœuds.
- -p multinode-demo : définit le nom du profil Minikube pour ce cluster.
Cette commande initialise un cluster avec un nœud de contrôle et un nœud de travail, tous deux virtualisés via KVM.

Vérification de l’état du cluster Après le démarrage, il est important de s’assurer que les nœuds sont opérationnels :

kubectl get nodes
NAME                 STATUS     ROLES           AGE   VERSION
multinode-demo       NotReady   control-plane   58d   v1.31.0
multinode-demo-m02   NotReady   <none>          2s    v1.31.0

Vous devriez voir une liste de nœuds avec leur statut indiquant qu’ils sont prêts à recevoir des charges de travail.

Explorer le Control Plane Kubernetes

Maintenant que vous avez mis en place un cluster Kubernetes, il est temps de lever le rideau sur son control plane. Comme évoqué dans l’introduction, le control plan est le cerveau de Kubernetes : il décide, surveille et ajuste tout ce qui se passe dans votre cluster.

1. Observer l’État du Control Plane

Avant d’explorer en détail chaque composant, commençons par une vue d’ensemble du control plane et des nœuds du cluster.

Vérifier l’état des nœuds du cluster :

La commande suivante liste tous les nœuds du cluster, y compris le nœud de contrôle (où s’exécute le control plane) et les nœuds de travail :

kubectl get nodes -o wide

Vous devriez voir une sortie similaire à celle-ci :

NAME                 STATUS   ROLES           AGE    VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE              KERNEL-VERSION   CONTAINER-RUNTIME
multinode-demo       Ready    control-plane   58d    v1.31.0   192.168.50.141   <none>        Buildroot 2023.02.9   5.10.207         docker://27.2.0
multinode-demo-m02   Ready    <none>          3m1s   v1.31.0   192.168.50.38    <none>        Buildroot 2023.02.9   5.10.207         docker://27.2.0

Vérifier les composants du control plane :

Le control plane est composé de plusieurs pods qui tournent dans le namespace kube-system. Pour les voir, utilisez :

kubectl get pods -n kube-system -l tier=control-plane

Exemple de sortie :

NAME                                     READY   STATUS    RESTARTS       AGE
etcd-multinode-demo                      1/1     Running   1 (4m9s ago)   58d
kube-apiserver-multinode-demo            1/1     Running   1 (4m9s ago)   58d
kube-controller-manager-multinode-demo   1/1     Running   1 (4m9s ago)   58d
kube-scheduler-multinode-demo            1/1     Running   1 (4m9s ago)   58d

Chaque composant a son propre pod, et nous allons maintenant voir comment les interroger individuellement.

2. Explorer l’API Server

L’API Server est le point d’entrée principal du cluster. Toutes les interactions passent par lui.

Vérifier l’état de l’API Server :

Utilisez cette commande pour voir si l’API Server fonctionne correctement :

kubectl get pod -n kube-system -l component=kube-apiserver
NAME                            READY   STATUS    RESTARTS        AGE
kube-apiserver-multinode-demo   1/1     Running   1 (4m44s ago)   58d

Vous pouvez aussi interroger directement l’état de santé de l’API Server :

curl -k https://192.168.50.141:8443/healthz

Si tout fonctionne bien, la réponse sera :

ok

Lister les ressources disponibles via l’API :

Pour voir toutes les ressources que l’API Server expose :

kubectl api-resources

Exemple de sortie :

NAME                                SHORTNAMES   APIVERSION                        NAMESPACED   KIND
bindings                                         v1                                true         Binding
componentstatuses                   cs           v1                                false        ComponentStatus
configmaps                          cm           v1                                true         ConfigMap

Cela montre toutes les ressources manipulables dans Kubernetes.

3. Observer les Données Stockées dans etcd

Comme vu précédemment, etcd est la base de données distribuée qui stocke toutes les informations sur l’état du cluster.

** Vérifier que etcd fonctionne** :

Pour voir si le pod etcd est bien démarré :

kubectl get pod -n kube-system -l component=etcd -o wide
NAME                  READY   STATUS    RESTARTS      AGE   IP               NODE             NOMINATED NODE   READINESS GATES
etcd-multinode-demo   1/1     Running   1 (16m ago)   58d   192.168.50.141   multinode-demo   <none>

Explorer les données stockées dans etcd :

On peut interroger etcd pour voir les clés qu’il stocke :

kubectl exec etcd-multinode-demo -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl \
    --endpoints=https://192.168.50.141:2379 \
    --cacert=/var/lib/minikube/certs/etcd/ca.crt \
    --key=/var/lib/minikube/certs/etcd/server.key \
    --cert=/var/lib/minikube/certs/etcd/server.crt \
    get / --prefix --keys-only"

Exemple de sortie :

/registry/apiregistration.k8s.io/apiservices/v1.
/registry/apiregistration.k8s.io/apiservices/v1.admissionregistration.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.apiextensions.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.apps

...

Chaque ligne représente une ressource Kubernetes stockée dans etcd.

4. Comprendre le Fonctionnement du Scheduler

Le scheduler assigne les nouveaux Pods aux nœuds disponibles.

Vérifier que le scheduler fonctionne :

kubectl get pod -n kube-system -l component=kube-scheduler
NAME                            READY   STATUS    RESTARTS      AGE
kube-scheduler-multinode-demo   1/1     Running   1 (11m ago)   58d

Observer comment un Pod est planifié :

Lançons un pod sans spécifier de nœud :

apiVersion: v1
kind: Pod
metadata:
  name: test-scheduler
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]

Appliquez-le :

kubectl apply -f test-pod.yaml

Maintenant, observez le scheduler en action :

kubectl describe pod test-scheduler

Vous verrez une ligne comme celle-ci :

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  10s   default-scheduler  Successfully assigned default/test-scheduler to worker-node-1

Cela montre que le scheduler a trouvé un nœud disponible et y a assigné le Pod.

5. Explorer le Controller Manager

Le Controller Manager surveille et corrige les écarts entre l’état désiré et l’état actuel du cluster.

Vérifier que le Controller Manager fonctionne :

kubectl get pod -n kube-system -l component=kube-controller-manager

Tester l’action d’un contrôleur :

Créons un Deployment avec 3 réplicas :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-controller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test-controller
  template:
    metadata:
      labels:
        app: test-controller
    spec:
      containers:
      - name: nginx
        image: nginx

Appliquez-le :

kubectl apply -f test-deployment.yaml

Maintenant, supprimons un des pods manuellement :

kubectl delete pod -l app=test-controller

Quelques secondes plus tard, exécutez :

kubectl get pods -l app=test-controller

Vous verrez que Kubernetes a automatiquement recréé un Pod pour respecter le nombre de réplicas défini.

Plus d’infos

Kubernetes est un écosystème vaste et en constante évolution. Pour aller plus loin et approfondir la compréhension du control plane, voici une sélection de ressources officielles, articles techniques, outils pratiques et formations qui vous aideront à maîtriser ses subtilités.

La documentation officielle est toujours la meilleure source pour comprendre le fonctionnement interne de Kubernetes. Elle est régulièrement mise à jour et couvre tous les composants du control plane : Architecture du control plane ↗

Conclusion

Voila qui conclut notre exploration du control plane Kubernetes. Vous avez découvert les composants clés qui orchestrent le fonctionnement de votre cluster et comment ils interagissent pour garantir son bon fonctionnement. En comprenant le rôle de chaque composant, vous serez mieux armé pour diagnostiquer et corriger les problèmes qui peuvent survenir dans votre cluster.

Dans le prochain chapitre, nous plongerons dans le monde des workers nodes.