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

Infrastructure

• 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

• 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

1. Préparez le fichier de configuration kubeadm

   Créez kubeadm-config.yaml :

   apiVersion: kubeadm.k8s.io/v1beta4
   kind: ClusterConfiguration
   kubernetesVersion: v1.35.2
   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.35.2
master2   Ready    control-plane   5m      v1.35.2
master3   Ready    control-plane   2m      v1.35.2

Vérifier l’état du cluster HA

État des nœuds

kubectl get nodes -o wide

État d’etcd

# 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

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

Scénarios de failover

Test de panne d’un control plane

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

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

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

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

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 →