Comprendre le fonctionnement interne de Kubernetes nécessite une immersion dans son code source, principalement écrit en Go. L'architecture repose sur plusieurs compsoants clés qui interagissent pour maintenir l'état souhaité du cluster.

Analyse du composant API Server

L'API Server agit comme le hub central du plan de contrôle. Toute interaction avec le cluster passe par ce composant. Pour explorer son point d'entrée, il faut se diriger vers le fichier suivant :

cmd/kube-apiserver/apiserver.go

Ce fichier initialise le serveur, configure les protocoles de stockage (généralement via etcd) et expose les points de terminaison RESTful qui permettent aux autres composants de communiquer.

Mécanismes internes du Scheduler

Le rôle du kube-scheduler est de surveiller les nouveaux pods sans nœud assigné et de leur choisir un hôte optimal. La structure du répertoire de l'ordonnanceur révèle son organisation logique :

• cmd/ : Contient le point d'entrée principal de l'exécutable.
• pkg/scheduler/algorithm/ : Regroupe les algorithmes de filtrage (predicates) et de priorité (priorities).
• pkg/scheduler/api/ : Définit les structures de données internes utilisées pour la planification.

L'implémentation de la logique de sélection est orchestrée par la fonction scheduleOne. Contrairement à d'autres systèmes d'orchestration comme OpenStack qui s'appuient fortement sur RPC, Kubernetes utilise principalement des serveurs HTTP pour l'exposition des métriques et du profilage (Profiling).

L'objet Binding

Une fois qu'un nœud est sélectionné pour un Pod, le scheduler crée un objet Binding. Cet objet fait le pont entre le Pod et l'infrastructure physique ou virtuelle. Voici une représentation simplifiée de sa structure en Go :

type TargetBinding struct {
   metav1.TypeMeta   `json:",inline"`
   metav1.ObjectMeta `json:"metadata,omitempty"`

   // NodeReference définit la cible vers laquelle le pod est lié
   NodeReference ObjectReference `json:"target"`
}

Le cycle de vie dans le Kubelet

Le Kubelet est l'agent qui s'exécute sur chaque nœud du cluster. Il est responsable de la gestion effective des conteneurs. Son point d'entrée se situe dans :

cmd/kubelet/kubelet.go

Le démarrage du Kubelet implique la configuration de la gestion des volumes, du réseau (CNI) et de l'interface d'exécution des conteneurs (CRI). Il maintient une boucle de contrôle qui synchronise l'état local du nœud avec les spécifications fournies par l'API Server.

Gestion de l'élection du leader

Pour assurer la haute disponibilité, les composants comme le Scheduler et le Controller Manager utilisent un mécanisme de LeaderElection. Cela permet à plusieurs instances de fonctionner simultanément, tout en garantissant qu'une seule instance active traite les données à un instant T, évitant ainsi les conflits d'état dans etcd.