Haute disponibilité du Control Plane Kubernetes

Un cluster Kubernetes à un seul control plane est un SPOF (Single Point of Failure). Si le nœud master tombe, plus personne ne peut déployer, scaler ou gérer les workloads, même si les applications continuent de tourner. La haute disponibilité (HA) du control plane élimine ce risque en répartissant les composants critiques sur plusieurs nœuds.

Ce guide couvre l'architecture HA pour la certification CKA et les environnements de production.

Ce que vous allez apprendre

• Pourquoi un control plane unique est un risque
• Les deux topologies HA : stacked etcd vs external etcd
• Comment configurer un cluster HA avec kubeadm
• Le rôle du load balancer devant l'API Server
• Les scénarios de failover et leur gestion

Pourquoi la haute disponibilité ?

Le control plane ne fait pas tourner vos applications : il décide de ce qui tourne et où. Tant qu'il fonctionne, ses décisions sont réappliquées en permanence. Quand il disparaît, le cluster se fige dans son dernier état connu, sans que rien ne le signale aux utilisateurs des applications. Comprendre ce qui s'arrête exactement est le préalable au choix d'une topologie HA.

Le problème d'un control plane unique

Dans un cluster standard, le control plane (un seul nœud) héberge :

Composant	Rôle	Impact si indisponible
kube-apiserver	Point d'entrée de toutes les requêtes	Aucune commande kubectl ne fonctionne
etcd	Stocke l'état du cluster	Perte de configuration, impossible de créer des ressources
kube-scheduler	Place les Pods sur les nœuds	Les nouveaux Pods restent Pending
kube-controller-manager	Gère les Deployments, ReplicaSets...	Pas de réconciliation, pas d'autoscaling

Glissez pour voir

Une nuance qui change la façon de vivre l'incident : si le control plane tombe, les Pods existants continuent de tourner sur les workers, et vos applications restent en ligne. Ce que vous perdez, c'est la capacité à agir : plus de création, plus de modification, plus de diagnostic par l'API. Autrement dit, la panne ne se voit pas des utilisateurs jusqu'au moment où quelque chose d'autre casse, et où vous n'avez plus aucun moyen d'intervenir.

Ce qu'apporte la HA

La haute disponibilité ne rend pas le cluster plus rapide ni plus puissant : elle lui permet de survivre à la perte d'une machine. Le tableau ci-dessous met en regard ce qu'on perd sans elle et ce qu'on conserve avec, ligne par ligne.

Avec 3 control planes (minimum recommandé) :

• Tolérance aux pannes : 1 nœud peut tomber sans impact
• Continuité des opérations : kubectl fonctionne toujours
• Maintenance sans interruption : upgrade un nœud à la fois
• Résilience etcd : quorum maintenu avec 2 nœuds sur 3

Les deux topologies HA

Kubernetes supporte deux architectures pour la haute disponibilité :

Topologie Stacked etcd (recommandée pour la CKA)

Chaque control plane héberge à la fois les composants Kubernetes et etcd :

Avantages :

• Plus simple à déployer et maintenir
• Moins de nœuds nécessaires
• Configuration kubeadm standard

Inconvénients :

• Perte d'un control plane = perte d'un membre etcd
• Couplage fort entre composants

Topologie External etcd

Le cluster etcd est séparé des control planes Kubernetes :

Avantages :

• Isolation des pannes (etcd indépendant)
• Plus de flexibilité pour le scaling

Inconvénients :

• Plus complexe à déployer
• Plus de nœuds à gérer (6 minimum)

Pour l'examen CKA, concentrez-vous sur la topologie stacked etcd : c'est celle que kubeadm déploie par défaut en mode haute disponibilité, et donc celle sur laquelle porteront les questions.

Prérequis

Le montage demande plus qu'un cluster de test : il faut une adresse virtuelle stable devant les serveurs d'API, et un nombre impair de nœuds de contrôle pour que le quorum etcd puisse se départager.

Infrastructure

Trois nœuds sont le minimum : avec deux, la perte d'un seul casse le quorum d'etcd et le cluster devient incapable d'enregistrer le moindre changement.

• 3 nœuds control plane (2 CPU, 2 Go RAM, minimum de lab, pas sizing production)
• 1 load balancer redondant devant les API Servers (HAProxy + keepalived, Nginx, ou cloud LB)
• Connectivité réseau entre tous les nœuds
• Ports ouverts : 6443 (API), 2379-2380 (etcd), 10250-10259 (kubelet/components)

Ce guide s'adresse aux clusters kubeadm auto-gérés, sur machines virtuelles ou physiques. Sur un cluster managé, EKS, GKE ou AKS, la question ne se pose pas : la haute disponibilité du control plane fait partie de ce que vous achetez, et vous n'y avez pas la main.

Logiciels

Les versions doivent être alignées avant l'initialisation : les vérifications préalables de kubeadm échouent si le kubelet du nœud est plus récent que la version du control plane visée.

• kubeadm, kubelet, kubectl installés sur tous les nœuds
• Container runtime (containerd recommandé)
• Même version Kubernetes sur tous les nœuds

Configurer le Load Balancer

Le load balancer est indispensable pour distribuer les requêtes vers les API Servers.

Avec HAProxy

Créez /etc/haproxy/haproxy.cfg sur le nœud load balancer :

global
    log /dev/log local0
    maxconn 2000
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode tcp
    option tcplog
    option dontlognull
    timeout connect 5s
    timeout client 50s
    timeout server 50s

frontend kubernetes-api
    bind *:6443
    default_backend kubernetes-masters

backend kubernetes-masters
    balance roundrobin
    option tcp-check
    server master1 192.168.1.10:6443 check fall 3 rise 2
    server master2 192.168.1.11:6443 check fall 3 rise 2
    server master3 192.168.1.12:6443 check fall 3 rise 2

Démarrez HAProxy :

sudo systemctl enable --now haproxy

Vérification :

# Testez la connexion au load balancer
nc -zv <LOAD_BALANCER_IP> 6443

Attention à ne pas déplacer le problème sans le résoudre. Un HAProxy unique, sans adresse virtuelle ni redondance, devient à son tour un point de défaillance unique : trois control planes derrière un répartiteur qui tombe, cela reste un cluster injoignable. En production, associez HAProxy à keepalived pour disposer d'une adresse virtuelle flottante, ou confiez le rôle à un répartiteur managé de votre fournisseur.

Vérification avancée :

# Tester que l'API Kubernetes répond vraiment
curl -k https://<LB_IP>:6443/readyz

Initialiser le premier Control Plane

Le premier nœud est particulier : c'est lui qui crée la CA du cluster, la base etcd et le Secret contenant les certificats partagés. Deux paramètres de cette étape sont irréversibles ou à durée limitée : controlPlaneEndpoint, qui fige l'adresse par laquelle tout le monde joindra l'API, et la certificate-key produite par --upload-certs, valable deux heures.

1. Préparez le fichier de configuration kubeadm

   Créez kubeadm-config.yaml :

   apiVersion: kubeadm.k8s.io/v1beta4
   kind: ClusterConfiguration
   kubernetesVersion: v1.37.0
   controlPlaneEndpoint: "LOAD_BALANCER_IP:6443"
   networking:
     podSubnet: "10.244.0.0/16"
   ---
   apiVersion: kubeadm.k8s.io/v1beta4
   kind: InitConfiguration
   localAPIEndpoint:
     advertiseAddress: "192.168.1.10"
     bindPort: 6443

   L'option controlPlaneEndpoint est obligatoire en haute disponibilité, et elle pointe vers le répartiteur de charge. Retenez surtout ceci : une fois le cluster initialisé, elle ne se modifie plus. C'est la raison pour laquelle il faut la renseigner même sur un cluster à un seul control plane, sous peine de devoir tout reconstruire le jour où la haute disponibilité devient nécessaire.

2. Initialisez le cluster

   sudo kubeadm init --config=kubeadm-config.yaml --upload-certs

   L'option --upload-certs chiffre et stocke les certificats dans un Secret Kubernetes pour que les autres control planes puissent les récupérer.

3. Notez les commandes de join

   La sortie affiche deux commandes :

   • Une pour joindre d'autres control planes
   • Une pour joindre des workers

   # Pour les control planes
   kubeadm join LOAD_BALANCER_IP:6443 --token <token> \
     --discovery-token-ca-cert-hash sha256:<hash> \
     --control-plane --certificate-key <key>
   
   # Pour les workers
   kubeadm join LOAD_BALANCER_IP:6443 --token <token> \
     --discovery-token-ca-cert-hash sha256:<hash>

4. Configurez kubectl

   mkdir -p $HOME/.kube
   sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
   sudo chown $(id -u):$(id -g) $HOME/.kube/config

5. Installez un CNI

   Flannel est une option simple pour commencer. Vous pouvez aussi choisir Calico, Cilium ou un autre CNI selon vos besoins :

   # Exemple avec Flannel
   kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Joindre les autres Control Planes

Le premier control plane a produit une commande de jointure particulière, qui diffère de celle des workers par --control-plane et une clé de certificats. C'est elle qui permet aux nœuds suivants de récupérer les certificats du cluster et de devenir membres d'etcd, et non simples clients.

Sur chaque control plane additionnel (master2, master3) :

sudo kubeadm join LOAD_BALANCER_IP:6443 --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane --certificate-key <key>

Vérification :

kubectl get nodes

NAME      STATUS   ROLES           AGE     VERSION
master1   Ready    control-plane   10m     v1.37.0
master2   Ready    control-plane   5m      v1.37.0
master3   Ready    control-plane   2m      v1.37.0

Vérifier l'état du cluster HA

Trois vérifications sont à faire dans cet ordre, car elles portent sur des couches différentes : les nœuds vus par Kubernetes, les membres etcd vus par etcd lui-même, et la santé interne de l'API Server. Un cluster peut afficher trois nœuds Ready alors qu'un membre etcd est sorti du cluster.

État des nœuds

La colonne ROLES doit indiquer control-plane pour les trois nœuds, et kubectl get nodes -o wide révèle en plus les adresses IP annoncées, utiles pour vérifier qu'elles correspondent aux backends du load balancer.

kubectl get nodes -o wide

État d'etcd

kubectl ne voit pas etcd : il faut interroger le cluster etcd directement, en présentant les certificats déposés par kubeadm dans /etc/kubernetes/pki/etcd/. Les trois membres doivent apparaître avec le statut started.

etcdctl n'est pas installé sur un nœud kubeadm. C'est le premier obstacle, et il surprend : which etcdctl sort en 1. Le binaire vit dans le conteneur etcd, une image distroless registry.k8s.io/etcd:3.7.0-0, et on l'atteint par un exec :

kubectl -n kube-system exec etcd-<nom-du-noeud> -- 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 \
  member list --write-out=table

Sortie, relevée sur un cluster à trois control planes

┌──────────────────┬─────────┬────────┬─────────────────────────────┬─────────────────────────────┬────────────┐
│        ID        │ STATUS  │  NAME  │         PEER ADDRS          │        CLIENT ADDRS         │ IS LEARNER │
├──────────────────┼─────────┼────────┼─────────────────────────────┼─────────────────────────────┼────────────┤
│ 3b6a9969c03c53c7 │ started │ ha-cp1 │ https://192.168.122.40:2380 │ https://192.168.122.40:2379 │      false │
│ 4511773aba6df6c3 │ started │ ha-cp2 │ https://192.168.122.41:2380 │ https://192.168.122.41:2379 │      false │
│ c5f3530aa9a1f7da │ started │ ha-cp3 │ https://192.168.122.42:2380 │ https://192.168.122.42:2379 │      false │
└──────────────────┴─────────┴────────┴─────────────────────────────┴─────────────────────────────┴────────────┘

La colonne IS LEARNER vaut false pour un membre votant. Un membre à true est en cours de rattrapage et ne compte pas dans le quorum, ce qui explique qu'un cluster à quatre lignes puisse n'en avoir que trois qui votent.

Vérifier la santé de chaque membre

member list dit qui est déclaré, pas qui répond. La distinction compte, et c'est endpoint health --cluster qui la fait :

kubectl -n kube-system exec etcd-<nom-du-noeud> -- 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 --cluster --write-out=table

Sortie, un membre arrêté sur trois

│ https://192.168.122.40:2379 │   true │   3.458728ms │                           │
│ https://192.168.122.41:2379 │   true │    9.71893ms │                           │
│ https://192.168.122.42:2379 │  false │ 5.004566097s │ context deadline exceeded │
Error: unhealthy cluster

La commande sort en 1 dès qu'un seul membre manque, alors que le cluster fonctionne parfaitement. Ne branchez donc pas une alerte sur ce seul code de retour : il signale une dégradation, pas une panne.

Santé des composants

kubectl get componentstatuses est déprécié et renvoie des informations incomplètes. Les points d'entrée /readyz et /livez, interrogés en --raw, listent chaque vérification interne de l'API Server une par une, dont etcd.

# Endpoints modernes (componentstatuses est déprécié)
kubectl get --raw='/readyz?verbose'
kubectl get --raw='/livez?verbose'

Scénarios de failover

La haute disponibilité ne se déclare pas, elle se vérifie. Le test consiste à couper volontairement un control plane et à confirmer que les opérations d'écriture passent toujours. Le tableau qui suit généralise le résultat à toutes les combinaisons de pannes.

Test de panne d'un control plane

Arrêter le kubelet suffit : les composants du control plane sont des static pods pilotés par le kubelet, ils s'arrêtent avec lui.

1. Arrêtez un control plane

   # Sur master2
   sudo systemctl stop kubelet

2. Vérifiez que le cluster fonctionne toujours

   kubectl get nodes
   kubectl create deployment test --image=nginx:1.28
   kubectl get pods

3. Redémarrez le nœud

   sudo systemctl start kubelet

Comportement du cluster selon les pannes

Le seuil se joue entre une et deux pannes simultanées sur trois nœuds. La bascule est brutale : tant que le quorum tient, rien ne change pour l'utilisateur ; dès qu'il est perdu, plus aucune écriture n'aboutit.

Pannes	etcd	API Server	Impact observé
0 sur 3	quorum	sert	fonctionnement normal
1 sur 3	quorum à 2 sur 3	sert	aucun changement pour l'utilisateur
2 sur 3	quorum perdu	ne répond plus	Unable to connect to the server: unexpected EOF
3 sur 3	arrêté	arrêté	cluster inutilisable

Glissez pour voir

Les deux lignes en gras ont été mesurées sur un cluster à trois control planes. À une panne, un kubectl run aboutit pendant que la machine est encore éteinte : le cluster ne se contente pas de répondre, il accepte des écritures. À deux pannes, la connexion est coupée net, sans message intermédiaire ni mode dégradé.

La perte de quorum etcd n'est pas une dégradation progressive, c'est un arrêt : le cluster ne peut plus accepter aucun changement d'état. Ne comptez pas sur un hypothétique mode « lecture seule », l'API peut devenir franchement indisponible selon la nature de la panne. C'est le scénario qu'un nombre impair de membres est précisément conçu pour rendre improbable.

etcd exige une majorité de membres en état de marche, ce qui donne trois cas usuels : sur 3 nœuds il en faut 2, sur 5 il en faut 3, sur 7 il en faut 4. D'où la règle du nombre impair : passer de 3 à 4 membres ne change pas le nombre de pannes tolérées, qui reste de une, tout en ajoutant une machine à maintenir et un membre de plus susceptible de tomber.

Maintenance d'un cluster HA

Un cluster HA se maintient sans interruption de service, à condition de ne jamais toucher deux nœuds en même temps : le quorum etcd doit rester acquis pendant toute l'opération. Les deux procédures ci-dessous couvrent la mise à jour planifiée et le remplacement d'un nœud définitivement perdu.

Upgrade d'un control plane

Procédez un nœud à la fois :

# 1. Drain le nœud
kubectl drain master1 --ignore-daemonsets --delete-emptydir-data

# 2. Upgrade kubeadm (remplacez X.Y.Z par la version cible)
sudo apt-get update && sudo apt-get install -y kubeadm=X.Y.Z-*

# 3. Appliquez l'upgrade
sudo kubeadm upgrade apply vX.Y.Z  # Premier control plane uniquement
# ou
sudo kubeadm upgrade node           # Autres control planes

# 4. Upgrade kubelet et kubectl
sudo apt-get install -y kubelet=X.Y.Z-* kubectl=X.Y.Z-*
sudo systemctl daemon-reload && sudo systemctl restart kubelet

# 5. Uncordon le nœud
kubectl uncordon master1

Avant toute montée de version, vérifiez la version stable courante sur kubernetes.io/releases : c'est la seule source qui fasse foi, et elle change toutes les quelques semaines.

Remplacement d'un control plane défaillant

Remplacer un control plane mort ne consiste pas à en rajouter un : il faut d'abord retirer l'ancien membre d'etcd, sans quoi le cluster continue de l'attendre pour compter son quorum. L'ordre des opérations compte donc plus que les commandes elles-mêmes.

Si un control plane est définitivement perdu :

1. Retirez le membre etcd

   # Trouvez l'ID du membre
   sudo etcdctl member list
   
   # Supprimez-le
   sudo etcdctl member remove <MEMBER_ID>

2. Supprimez le nœud du cluster

   kubectl delete node <failed-node>

3. Configurez un nouveau nœud

   Générez un nouveau token et rejoignez :

   kubeadm token create --print-join-command
   kubeadm init phase upload-certs --upload-certs

4. Joignez le nouveau control plane

   kubeadm join LOAD_BALANCER_IP:6443 --token <token> \
     --discovery-token-ca-cert-hash sha256:<hash> \
     --control-plane --certificate-key <key>

Erreurs courantes

Les trois échecs suivants concentrent la majorité des blocages lors d'une première mise en place HA. Ils ont un point commun : le message affiché désigne rarement la vraie cause, il faut vérifier la couche en dessous.

Le join échoue avec "certificate has expired"

La clé de certificats produite par kubeadm init a une durée de vie de deux heures. Passé ce délai, la commande de jointure reste syntaxiquement valide mais échoue à récupérer les certificats, avec un message qui n'oriente pas vers la vraie cause.

Le certificate-key expire après 2 heures. Régénérez-le :

sudo kubeadm init phase upload-certs --upload-certs

etcd refuse de démarrer après redémarrage

Vérifiez que les certificats sont présents et valides :

ls -la /etc/kubernetes/pki/etcd/
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -text -noout | grep -A2 Validity

kubectl timeout vers le load balancer

Quand kubectl expire alors que les control planes sont sains, le coupable est presque toujours le répartiteur de charge : mauvaise adresse dans le kubeconfig, backends déclarés sur le mauvais port, ou contrôle de santé qui sort tous les nœuds du service.

Ces trois contrôles se lisent de l'extérieur vers l'intérieur : si le premier échoue, les deux suivants ne diront rien d'utile.

1. Le load balancer répond : nc -zv <LB_IP> 6443
2. Au moins un API Server est vivant : curl -k https://<MASTER_IP>:6443/healthz
3. Les contrôles de santé HAProxy passent, sans quoi le répartiteur vide son pool

À retenir

1. 3 control planes minimum pour la haute disponibilité
2. Load balancer obligatoire devant les API Servers
3. Topologie stacked etcd = plus simple, recommandée pour la CKA
4. Quorum etcd = majorité de membres nécessaire
5. Upgrade un nœud à la fois pour maintenir la disponibilité
6. --upload-certs facilite l'ajout de control planes
7. Les workloads continuent même si le control plane tombe

Testez vos connaissances

Ce questionnaire reprend les points régulièrement évalués à la CKA : quorum etcd, rôle du controlPlaneEndpoint et conséquences d'une panne partielle du control plane.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Backup et Restore : La sauvegarde d'etcd, dernier recours quand le quorum est définitivement perdu.
• Troubleshooting cluster : Le diagnostic d'un control plane qui ne répond plus malgré la redondance.

×

📖 Voir la documentation →