Passer au contenu principal

Introduction (Kubernetes)

Architecture et composants

Un cluster Kubernetes est constitué de deux types de noeuds : le control plane, qui prend les décisions, et les noeuds worker, qui exécutent les charges de travail. Comprendre le rôle de chaque composant est essentiel pour diagnostiquer les pannes et dimensionner correctement l'infrastructure.

Control Plane

Le control plane peut tourner sur un ou plusieurs noeuds dédiés. En production, on vise 3 noeuds control plane pour la haute disponibilité.

kube-apiserver

Point d'entrée unique du cluster. Toutes les communications passent par lui : kubectl, les controllers, les kubelets, les webhooks. Il expose une API REST, valide les objets et les persiste dans etcd. En v1.35, l'API server supporte nativement le watch bookmarks et les field selectors sur les listes de ressources.

etcd

Base de données distribuée clé-valeur, source de vérité unique du cluster. Tout l'état Kubernetes est dans etcd : specs, status, secrets, RBAC... La latence etcd est critique pour les performances du cluster. Recommandé : SSD NVMe dédié, latence fsync sous 10ms.

# Inspecter etcd directement (avec etcdctl)
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379   --cacert=/etc/kubernetes/pki/etcd/ca.crt   --cert=/etc/kubernetes/pki/etcd/server.crt   --key=/etc/kubernetes/pki/etcd/server.key   endpoint health

kube-scheduler

Décide sur quel noeud placer les pods non schedulés. Il prend en compte : ressources disponibles (CPU/mémoire), taints et tolerations, affinités, topologie (zones de disponibilité), priorités. Un pod reste en statut Pending si aucun noeud ne satisfait ses contraintes.

kube-controller-manager

Ensemble de boucles de contrôle qui font converger l'état réel vers l'état désiré. Chaque controller surveille un type d'objet. Les principaux :

  • ReplicaSet controller : maintient le nombre de replicas demandé
  • Deployment controller : gère les mises à jour rolling
  • Node controller : détecte les noeuds unreachable, evict les pods
  • Service Account controller : crée les SA et leurs tokens dans les nouveaux namespaces

cloud-controller-manager

Composant optionnel qui délègue les intégrations cloud (création de LoadBalancers, volumes, routes réseau) aux APIs du provider. Présent sur EKS, GKE, AKS. Absent en on-premise pur.

Noeuds worker

kubelet

Agent Kubernetes sur chaque noeud. Reçoit les PodSpecs du kube-apiserver, les passe au runtime de conteneurs (containerd), surveille l'état des pods et remonte le status. Il gère également les volumes montés sur le noeud et les health checks.

kube-proxy

Configure les règles réseau (iptables ou ipvs) pour implémenter les Services. En 1.35, ipvs est recommandé pour les clusters à forte charge (meilleure performance que iptables au-delà de quelques milliers de règles). Sur les clusters utilisant Cilium, kube-proxy peut être désactivé complètement.

Container runtime

Interface CRI (Container Runtime Interface) entre kubelet et le runtime. containerd est le runtime par défaut depuis Kubernetes 1.20 (remplacement de dockershim, supprimé en 1.24). CRI-O est une alternative légère, courant sur OpenShift.

Flux de création d'un pod

Quand on crée un Deployment :

  1. kubectl envoie la spec à kube-apiserver
  2. kube-apiserver valide, persiste dans etcd
  3. Deployment controller détecte le nouveau Deployment, crée un ReplicaSet
  4. ReplicaSet controller crée les pods (statut : Pending)
  5. kube-scheduler détecte les pods Pending, assigne un noeud
  6. kubelet du noeud cible détecte le pod assigné, le pull et le démarre via containerd
  7. kubelet remonte le statut Running à kube-apiserver

Sources