Un controller est un programme qui exécute en continu une boucle de contrôle infinie (control loop). Il observe l’état actuel et l’état désiré des objets Kubernetes. Si une différence est détectée, le controller agit pour rapprocher l’état actuel de l’état désiré.

Concept clé

Dans Kubernetes, les controllers sont des boucles de contrôle qui surveillent l’état de votre cluster et effectuent, ou demandent, les modifications nécessaires. Chaque controller tente de rapprocher l’état actuel du cluster de l’état désiré.

545f7b37-7778-4dd0-baf2-afce6025b315.png

Exemple concret

Vous déclarez un Deployment avec un manifeste YAML indiquant l’état désiré (exemple : 2 réplicas, montage d’un volume, configmap, etc.).

  • Le Deployment Controller intégré s’assure que cet état est maintenu constamment.
  • Si vous modifiez le déploiement à 5 réplicas, ce controller détecte le changement et agit pour qu’il y ait effectivement 5 réplicas.
  • Auto-réparation : si un pod meurt ou qu’un nœud part en panne, le controller crée automatiquement de nouveaux pods pour garantir la disponibilité voulue.
ComposantRôle dans la création des pods
kube-controller-managerGère les contrôleurs qui créent/modifient les ressources Pod en respectant l’état désiré
kube-schedulerAssigne un pod à un nœud adapté
kubeletSur le nœud worker, démarre effectivement les conteneurs du pod

Le kube-controller-manager ne “crée pas” les pods dans le sens d’exécution, mais il crée les objets pods dans l’API Kubernetes pour que le système les prenne en charge et les maintienne.

Rôle du Kube Controller Manager

FonctionDescription
Gestionnaire centralGère tous les controllers Kubernetes (comme Deployment, ReplicaSet, Job, Namespace, Node, etc.).
Contrôleurs multiplesChaque controller est responsable d’un type spécifique d’objet Kubernetes.
Intégration avec le SchedulerLe scheduler est aussi un controller géré par le Kube Controller Manager (mais le kube-scheduler ne fait pas partie du kube-controller-manager).
ExtensibilitéSupporte les controllers personnalisés associés à des définitions de ressources personnalisées (CRD).

Liste des principaux controllers intégrés

ControllerFonction principale
Deployment ControllerGère le cycle de vie des Deployments : s’assure que le bon nombre de pods est en cours d’exécution
ReplicaSet ControllerMaintient le nombre souhaité de pods identiques pour l’échelle et la disponibilité
DaemonSet ControllerGarantit qu’un pod spécifique s’exécute sur chaque nœud (ou certains nœuds sélectionnés)
StatefulSet ControllerGère les applications nécessitant des identifiants, du stockage persistant et un ordonnancement strict
Job ControllerLance des tâches batch devant s’exécuter jusqu’à leur complétion
CronJob ControllerPlanifie des jobs à exécuter périodiquement selon un cron
Endpoints ControllerMet à jour la liste des endpoints attachés à chaque service
Service ControllerCrée et gère les services virtuels réseau (ClusterIP, NodePort, LoadBalancer)
Namespace ControllerGère la création, la suppression et la finalisation des namespaces
ServiceAccount ControllerAdministre la création de comptes de service associés à chaque namespace
Node ControllerSurveille et met à jour l’état des nœuds du cluster
Horizontal Pod Autoscaler (HPA) ControllerAjuste automatiquement le nombre de pods via autoscaling horizontal (CPU, mémoire, custom metrics). Voir mécanisme de KEDA.
Volume ControllerGère l’attachement et le détachement des volumes persistants (PV/PVC)
PersistentVolumeClaim (PVC) ControllerAttribution automatique des volumes aux pods qui le requièrent
Ingress ControllerGère l’accès HTTP/S externe vers les services internes (peut être natif ou tiers, selon le choix d’implémentation)

Schéma simplifié du fonctionnement des Controllers

ÉtapeDescription
SurveillanceBoucle infinie qui observe les ressources via l’API server.
Détection d’écartCompare état actuel avec état désiré.
Actions correctivesCrée, modifie ou supprime des ressources pour aligner les états.
Mise à jour de l’étatRapport de l’état actuel corrigé à l’API server.

Notes complémentaires

  • Les controllers ne manipulent pas directement les ressources, mais envoient des requêtes à l’API server pour appliquer les changements.
  • Les contrôleurs sont conçus pour être simples et indépendants, ce qui améliore la robustesse du cluster (si un controller échoue, un autre peut prendre le relais).
  • Vous pouvez créer vos propres controllers personnalisés pour gérer des ressources spécifiques via des Custom Resource Definitions (CRD).