Architecture du control plane Kubernetes : composants et fonctionnement

L'architecture control plane Kubernetes constitue le cerveau de tout cluster. Chaque ingénieur infrastructure Kubernetes doit maîtriser ses composants pour diagnostiquer les pannes, optimiser les performances et garantir la haute disponibilité. Selon le rapport Spectro Cloud State of Kubernetes 2025, 80% des organisations exécutent Kubernetes en production avec une moyenne de 20+ clusters. Comprendre le fonctionnement cluster Kubernetes devient donc une compétence critique.

TL;DR : Le control plane Kubernetes orchestre l'ensemble du cluster via cinq composants clés : kube-apiserver (point d'entrée API), etcd (stockage d'état), kube-scheduler (placement des pods), kube-controller-manager (boucles de contrôle) et cloud-controller-manager (intégration cloud). La résilience du cluster dépend directement de leur configuration.

Cette compétence est au cœur de la formation LFS458 Administration Kubernetes.

Qu'est-ce que l'architecture control plane Kubernetes ?

Le control plane est l'ensemble des composants qui prennent les décisions globales sur le cluster. Il détecte et répond aux événements : création d'un Deployment, scaling d'un ReplicaSet, ou défaillance d'un nœud.

L'architecture se divise en deux plans distincts :

Plan	Rôle	Composants
Control plane	Décisions, état, orchestration	kube-apiserver, etcd, kube-scheduler, kube-controller-manager
Data plane	Exécution des workloads	kubelet, kube-proxy, container runtime

Le premier commit Kubernetes date du 6 juin 2014 : 250 fichiers et 47 501 lignes de code. Depuis, l'architecture a évolué tout en conservant ces principes fondamentaux.

Comment fonctionne kube-apiserver dans l'architecture control plane Kubernetes ?

Le kube-apiserver est le point d'entrée unique du cluster. Toute interaction passe par lui : kubectl, contrôleurs internes, composants externes.

Responsabilités du kube-apiserver

Validation : vérifie la syntaxe et la sémantique des requêtes
Authentification : identifie l'appelant (certificats, tokens, OIDC)
Autorisation : applique les politiques RBAC
Admission : exécute les webhooks de mutation et validation
Persistance : écrit l'état dans etcd

# Exemple de configuration kube-apiserver (kubeadm)
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.1.10
    - --etcd-servers=https://127.0.0.1:2379
    - --service-cluster-ip-range=10.96.0.0/12
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction

Pour approfondir la gestion des accès, consultez RBAC Kubernetes : comprendre et configurer la gestion des accès.

À retenir : Le kube-apiserver est le seul composant qui communique directement avec etcd. Cette isolation protège l'intégrité des données du cluster.

Quel rôle joue etcd dans le fonctionnement cluster Kubernetes ?

etcd est une base de données clé-valeur distribuée qui stocke l'intégralité de l'état du cluster : configurations, secrets, états des ressources.

Caractéristiques techniques d'etcd

Propriété	Valeur
Protocole de consensus	Raft
Cohérence	Forte (linearizable)
Stockage	Clé-valeur hiérarchique
Port par défaut	2379 (client), 2380 (peer)

# Vérifier la santé du cluster etcd
ETCDCTL_API=3 etcdctl endpoint health \
  --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

# Lister les clés Kubernetes
ETCDCTL_API=3 etcdctl get /registry --prefix --keys-only

La perte d'etcd signifie la perte de l'état du cluster. Configurez des sauvegardes automatiques :

# Sauvegarde etcd
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db \
  --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

Selon Cloud Native Now, les équipes IT passent 34 jours ouvrés par an à résoudre des problèmes Kubernetes. Une mauvaise gestion d'etcd représente une part significative de ce temps.

Comment kube-scheduler place les pods sur les nœuds ?

Le kube-scheduler surveille les pods sans nœud assigné et sélectionne le meilleur nœud selon des critères de filtrage et de scoring.

Phases de scheduling

Filtrage : élimine les nœuds inadéquats (ressources insuffisantes, taints incompatibles)
Scoring : classe les nœuds restants selon des priorités configurables
Binding : associe le pod au nœud sélectionné via l'API

# Pod avec contraintes d'affinité
apiVersion: v1
kind: Pod
metadata:
  name: app-with-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - eu-west-1a
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: backend
          topologyKey: kubernetes.io/hostname
  containers:
  - name: app
    image: myapp:v1

À retenir : Le scheduler prend des décisions optimales au moment t. Pour des workloads critiques, utilisez des PodDisruptionBudgets pour garantir la disponibilité lors des évictions.

Pour une installation complète intégrant ces concepts, suivez le Guide complet : installer un cluster Kubernetes multi-nœuds avec kubeadm.

Que gère kube-controller-manager ?

Le kube-controller-manager exécute les boucles de contrôle qui maintiennent l'état souhaité du cluster. Chaque contrôleur surveille l'état actuel via l'API et effectue les corrections nécessaires.

Contrôleurs principaux

Contrôleur	Fonction
Node Controller	Détecte les nœuds défaillants
Replication Controller	Maintient le nombre de réplicas
Endpoints Controller	Associe Services et Pods
ServiceAccount Controller	Crée les comptes de service par défaut
Namespace Controller	Gère le cycle de vie des namespaces

# Vérifier les contrôleurs actifs (méthode moderne)
kubectl get --raw='/healthz?verbose'

# Note : kubectl get componentstatuses est deprecated depuis v1.19

Le pattern de réconciliation est fondamental. Cette flexibilité vient directement de l'architecture déclarative des contrôleurs.

Comment intégrer le cloud-controller-manager ?

Le cloud-controller-manager isole la logique spécifique au provider cloud. Il permet à Kubernetes de provisionner des ressources cloud natives : load balancers, volumes, routes.

Responsabilités par provider

# Service LoadBalancer provisionné via cloud-controller-manager
apiVersion: v1
kind: Service
metadata:
  name: frontend
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
spec:
  type: LoadBalancer
  selector:
    app: frontend
  ports:
  - port: 443
    targetPort: 8443

Cette séparation facilite les migrations entre providers. Pour une comparaison détaillée, consultez Administration cluster Kubernetes.

À retenir : Sur les clusters auto-hébergés (bare-metal), le cloud-controller-manager n'est pas nécessaire. Utilisez MetalLB pour les Services LoadBalancer.

Quelles sont les bonnes pratiques pour sécuriser les composants kube-apiserver etcd Kubernetes ?

La sécurité du control plane est non-négociable. Une compromission expose l'intégralité du cluster.

Mesures essentielles

Pour kube-apiserver :

Activez l'audit logging pour tracer toutes les requêtes
Configurez des admission controllers (PodSecurity, OPA Gatekeeper)
Limitez l'accès réseau au port 6443

Pour etcd :

Chiffrez les données au repos avec --encryption-provider-config
Isolez etcd sur des nœuds dédiés
Utilisez mTLS pour toutes les communications

# Configuration du chiffrement etcd
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-secret>
      - identity: {}

Pour approfondir ces aspects, consultez Sécuriser un cluster Kubernetes : les bonnes pratiques.

Comment configurer un control plane hautement disponible ?

Un control plane mono-nœud représente un Single Point of Failure. En production, déployez au minimum 3 nœuds control plane.

Architecture HA

                    ┌─────────────────┐
                    │  Load Balancer  │
                    │  (TCP 6443)     │
                    └────────┬────────┘
           ┌─────────────────┼─────────────────┐
           │                 │                 │
    ┌──────▼──────┐   ┌──────▼──────┐   ┌──────▼──────┐
    │ Control     │   │ Control     │   │ Control     │
    │ Plane 1     │   │ Plane 2     │   │ Plane 3     │
    │ ─────────── │   │ ─────────── │   │ ─────────── │
    │ apiserver   │   │ apiserver   │   │ apiserver   │
    │ scheduler   │   │ scheduler   │   │ scheduler   │
    │ controller  │   │ controller  │   │ controller  │
    │ etcd        │   │ etcd        │   │ etcd        │
    └─────────────┘   └─────────────┘   └─────────────┘

# Initialiser le premier control plane avec kubeadm
kubeadm init \
  --control-plane-endpoint "loadbalancer.example.com:6443" \
  --upload-certs

# Joindre les control planes additionnels
kubeadm join loadbalancer.example.com:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <key>

Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Cette adoption massive exige des architectures résilientes.

Pour les mises à jour sans interruption, consultez Mettre à jour un cluster Kubernetes sans interruption.

À retenir : etcd requiert un quorum de n/2+1 nœuds. Avec 3 nœuds, vous tolérez 1 défaillance. Avec 5 nœuds, vous tolérez 2 défaillances.

Passez à la pratique avec SFEIR Institute

Maîtriser l'architecture control plane Kubernetes nécessite une pratique encadrée. 71 % des entreprises Fortune 100 exécutent Kubernetes en production. Rejoignez-les avec les compétences adéquates.

Les formations SFEIR Institute vous préparent aux certifications officielles :

LFS458 Administration Kubernetes : 4 jours pour maîtriser le déploiement, la configuration et la maintenance des clusters. Prépare à la certification CKA.
Kubernetes, les fondamentaux : 1 journée pour découvrir les concepts essentiels avant d'approfondir l'administration.

L'examen CKA exige un score de 66% en 2 heures sur des scénarios pratiques (Linux Foundation). Nos formateurs, praticiens en production, vous préparent à ces défis réels.

Pour aller plus loin :

Contactez nos conseillers pour construire votre parcours de certification.

Points clés