Architecture de cluster et objets de base
Décomposer un cluster Kubernetes en control plane et data plane, et connaître les objets API essentiels.
À retenir
- Le control plane (API server, etcd, scheduler, controller-manager) porte l'état et les décisions du cluster.
- etcd utilise un consensus Raft et exige un nombre impair de membres pour maintenir le quorum.
- Deployment, StatefulSet et Service sont les objets de base pour exposer des charges stateless et stateful.
- Un control plane répliqué sur au moins trois nœuds est nécessaire pour la haute disponibilité en production.
Control plane et data plane
Un cluster Kubernetes se divise en deux ensembles de composants. Le control plane porte l'intelligence : l'API server (point d'entrée unique de toutes les requêtes), etcd (base clé-valeur distribuée stockant l'état du cluster), le scheduler (placement des pods) et le controller-manager (boucles de réconciliation). Les nœuds worker exécutent les charges via le kubelet (agent qui fait dialoguer le nœud avec l'API server), le kube-proxy (règles réseau) et le runtime conteneur (containerd le plus souvent depuis l'abandon du support direct de Docker).
| Composant | Rôle | Impact d'une panne |
|---|---|---|
| API server | Point d'entrée API, validation | Cluster inaccessible en écriture |
| etcd | Stockage d'état distribué | Perte de données de configuration si non répliqué |
| Scheduler | Placement des pods | Nouveaux pods restent Pending |
| kubelet | Exécution locale des pods | Nœud marqué NotReady |
Point clé
etcd est un système de consensus (Raft) qui exige un nombre impair de membres (3 ou 5 typiquement) ; une latence disque supérieure à quelques millisecondes dégrade directement les performances de l'ensemble du cluster.
Les objets API fondamentaux
- Pod : plus petite unité déployable, un ou plusieurs conteneurs partageant réseau et stockage.
- Deployment : gère un jeu de réplicas de pods sans état, avec mises à jour progressives (rolling update).
- StatefulSet : pour les charges avec état nécessitant une identité réseau stable et un ordre de démarrage (bases de données).
- Service : abstraction réseau stable (ClusterIP, NodePort, LoadBalancer) pointant vers un ensemble de pods via des sélecteurs de labels.
- ConfigMap / Secret : externalisation de la configuration et des données sensibles.
- Namespace : partitionnement logique multi-équipe d'un même cluster.
Sur le terrain
un Service qui ne route vers aucun pod est presque toujours dû à un décalage entre les labels du sélecteur du Service et les labels réellement posés sur les pods — la première commande à lancer est kubectl get endpoints.
Haute disponibilité du control plane
En production, le control plane doit être répliqué sur au moins trois nœuds pour tolérer la perte d'un membre etcd sans perte de quorum. Les offres managées (EKS, GKE, AKS) prennent cette charge à leur compte moyennant un coût mensuel fixe par cluster, ce qui déplace l'effort d'exploitation vers la couche applicative.
Attention
un cluster avec un seul nœud control plane n'a aucune tolérance de panne : toute maintenance ou incident sur ce nœud rend le cluster indisponible en écriture, même si les pods déjà déployés continuent de fonctionner.
Astuce
pour diagnostiquer rapidement l'état de santé, commencez toujours par kubectl get componentstatuses (ou l'équivalent via les métriques du control plane managé) avant de creuser au niveau des pods applicatifs.