Kubernetes HA

Fiche express
Type	Modèle de haute disponibilité du control plane Kubernetes
Composants concernés	API server, etcd, scheduler, controller-manager
Topologies etcd	Empilée (stacked) ou externalisée
Voir aussi	Etcdctl · Kubernetes rancher

La haute disponibilité d'un cluster Kubernetes consiste à faire tourner plusieurs nœuds control plane (API server, scheduler, controller-manager) plutôt qu'un seul, afin que la perte d'une machine n'interrompe ni le pilotage du cluster ni la capacité des applications déjà déployées à continuer de fonctionner. Les nœuds workers et les workloads applicatifs ne sont pas directement concernés par ce découpage : un cluster mono-master avec des workers redondants garde déjà les applications disponibles en cas de panne d'un worker, mais perd toute capacité d'administration (déploiements, scaling, reprogrammation de pods) si l'unique master tombe.

Répartition de charge devant les API servers

Avec plusieurs nœuds control plane, chacun expose sa propre instance d'API server. Les clients (kubectl, kubelets des workers, contrôleurs) doivent viser une adresse unique et stable plutôt qu'un nœud en particulier : ce rôle est assuré par un répartiteur de charge (matériel, cloud, ou une solution logicielle comme keepalived + HAProxy pour une IP virtuelle) placé devant l'ensemble des API servers.

Deux topologies pour etcd

Le choix structurant d'une architecture HA porte sur l'emplacement d'etcd, le magasin clé/valeur qui contient l'intégralité de l'état du cluster.

etcd empilé (stacked)

Chaque nœud control plane héberge sa propre instance etcd, colocalisée avec son API server. C'est la topologie la plus simple à déployer (outils comme kubeadm la proposent par défaut) : elle ne nécessite pas de machines supplémentaires, mais couple le sort d'etcd à celui du control plane — perdre un nœud, c'est perdre à la fois une instance d'API server et un membre du quorum etcd.

etcd externalisé (external)

Le cluster etcd est déployé sur un ensemble de nœuds dédiés, distincts des nœuds control plane, entre lesquels et les workers il vient s'intercaler. Cette séparation isole les deux plans de défaillance (perdre un nœud control plane n'affecte pas le quorum etcd, et inversement) et permet de dimensionner et de faire évoluer etcd indépendamment du reste — au prix de machines et d'une exploitation supplémentaires.

Stacked etcd                      External etcd

 [CP1: apiserver+etcd]             [CP1: apiserver]   [etcd-1]
 [CP2: apiserver+etcd]             [CP2: apiserver]   [etcd-2]
 [CP3: apiserver+etcd]             [CP3: apiserver]   [etcd-3]
        ^                                 ^                ^
        |                                 +----------------+
   (LB devant les API servers)         (LB devant les API servers,
                                         etcd sur des nœuds séparés)

Quorum etcd

etcd utilise le protocole de consensus Raft, qui exige qu'une majorité stricte (quorum) des membres soit disponible pour accepter une écriture. Un cluster à 3 membres tolère la perte d'un membre (2/3 restants), un cluster à 5 membres en tolère deux (3/5). Un nombre impair de membres est systématiquement recommandé : passer de 3 à 4 membres n'augmente pas la tolérance aux pannes (toujours une seule perte tolérée) mais alourdit le coût de chaque écriture, qui doit être répliquée sur davantage de membres.

Redémarrer plusieurs nœuds control plane à la fois — a fortiori en topologie empilée — expose donc au risque très concret de perdre le quorum etcd et, avec lui, la capacité du cluster à accepter la moindre écriture ; voir la procédure de renouvellement de certificats décrite sur Kubernetes rancher, qui illustre ce point sur un cluster RKE2 multi-master.

Voir aussi

• Etcdctl — sauvegarde/restauration d'etcd, inspection des membres
• Kubernetes rancher — cas pratique de maintenance d'un control plane HA (RKE2)