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

Les workloads continuent de tourner

Si le control plane tombe, les Pods existants continuent de fonctionner sur les workers. Mais vous ne pouvez plus rien modifier, créer ou diagnostiquer. C'est particulièrement critique en cas d'incident.

Ce qu'apporte la HA

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 :

┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│  Control Plane 1│  │  Control Plane 2│  │  Control Plane 3│
├─────────────────┤  ├─────────────────┤  ├─────────────────┤
│ kube-apiserver  │  │ kube-apiserver  │  │ kube-apiserver  │
│ kube-scheduler  │  │ kube-scheduler  │  │ kube-scheduler  │
│ controller-mgr  │  │ controller-mgr  │  │ controller-mgr  │
│ etcd            │  │ etcd            │  │ etcd            │
└────────┬────────┘  └────────┬────────┘  └────────┬────────┘
         │                    │                    │
         └────────────────────┼────────────────────┘
                              │
                    ┌─────────┴─────────┐
                    │   Load Balancer   │
                    │   (API Server)    │
                    └─────────┬─────────┘
                              │
              ┌───────────────┼───────────────┐
              │               │               │
        ┌─────┴─────┐   ┌─────┴─────┐   ┌─────┴─────┐
        │  Worker 1 │   │  Worker 2 │   │  Worker 3 │
        └───────────┘   └───────────┘   └───────────┘

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 :

┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│   etcd 1     │  │   etcd 2     │  │   etcd 3     │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       └─────────────────┼─────────────────┘
                         │
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│  Control Plane 1│  │  Control Plane 2│  │  Control Plane 3│
├─────────────────┤  ├─────────────────┤  ├─────────────────┤
│ kube-apiserver  │  │ kube-apiserver  │  │ kube-apiserver  │
│ kube-scheduler  │  │ kube-scheduler  │  │ kube-scheduler  │
│ controller-mgr  │  │ controller-mgr  │  │ controller-mgr  │
└─────────────────┘  └─────────────────┘  └─────────────────┘

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)

Choix pour la CKA

Pour l'examen CKA, concentrez-vous sur la topologie stacked etcd, c'est celle que kubeadm déploie par défaut en mode HA.

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)

Clusters auto-gérés

Ce guide cible les clusters kubeadm auto-gérés, typiquement sur VM ou bare metal. Les clusters managés (EKS, GKE, AKS) gèrent la HA du control plane automatiquement.

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

Le LB est aussi un SPOF

Un seul HAProxy sans VIP ni redondance reste un Single Point of Failure. En production, combinez HAProxy avec keepalived (virtual IP) ou utilisez un load balancer cloud natif (AWS ELB, GCP LB, Azure LB).

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.36.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

   controlPlaneEndpoint

   L'option controlPlaneEndpoint est obligatoire pour la HA. Elle pointe vers le load balancer. Une fois définie, elle ne peut plus être modifiée.

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

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.36.0
master2   Ready    control-plane   5m      v1.36.0
master3   Ready    control-plane   2m      v1.36.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 bien 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.

# Sur un control plane
sudo 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 -w table

+------------------+---------+---------+------------------------+------------------------+
|        ID        | STATUS  |  NAME   |       PEER ADDRS       |      CLIENT ADDRS      |
+------------------+---------+---------+------------------------+------------------------+
| 8e9e05c52164694d | started | master1 | https://192.168.1.10:2380 | https://192.168.1.10:2379 |
| 91bc3c398fb3c146 | started | master2 | https://192.168.1.11:2380 | https://192.168.1.11:2379 |
| a3d22c71c6ed4a38 | started | master3 | https://192.168.1.12:2380 | https://192.168.1.12:2379 |
+------------------+---------+---------+------------------------+------------------------+

Santé des composants

kubectl get componentstatuses est déprécié et renvoie des informations incomplètes. Les endpoints /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
   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	Scheduler	Impact
0/3	✅ Quorum	✅	✅	Fonctionnement normal
1/3	✅ Quorum (2/3)	✅	✅	Fonctionnement normal
2/3	❌ Pas de quorum	⚠️ Dégradé	❌	Aucun changement d'état possible
3/3	❌	❌	❌	Cluster inutilisable

Glissez pour voir

Perte de quorum etcd

Avec perte de quorum etcd, le cluster ne peut plus accepter de changements d'état. L'API peut devenir dégradée ou indisponible selon la panne exacte. Ne comptez pas sur un fonctionnement "lecture seule" fiable.

Règle du quorum etcd

etcd nécessite une majorité de membres pour fonctionner :

• 3 nœuds → 2 minimum fonctionnels
• 5 nœuds → 3 minimum fonctionnels
• 7 nœuds → 4 minimum fonctionnels

C'est pourquoi on utilise toujours un nombre impair de nœuds etcd.

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

Version cible

Consultez kubernetes.io/releases pour connaître la dernière version stable avant un upgrade.

Remplacement d'un control plane défaillant

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"

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

Vérifiez :

1. Le load balancer est accessible : nc -zv <LB_IP> 6443
2. Au moins un API Server répond : curl -k https://<MASTER_IP>:6443/healthz
3. Les health checks HAProxy fonctionnent

À 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

10 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

Prochaines étapes

etcd Comprendre etcd, la base de données du cluster

Backup et restauration Sauvegarder et restaurer etcd

kubeadm Installation et configuration avec kubeadm

Troubleshooting Diagnostiquer les problèmes de cluster

×

📖 Voir la documentation →