Kubernetes haute disponibilité multi-datacenter en Suisse : architecture et fonctionnement réel

Control plane répliqué, etcd en quorum, stockage Geneva-Gland-Lucerne : ce qui se passe réellement quand un datacenter tombe.

Un cluster Kubernetes en configuration single-zone atteint généralement 99,9 % de disponibilité, soit jusqu'à 8,7 heures d'arrêt par an. Passer à une architecture multi-datacenter avec control plane répliqué monte ce chiffre à 99,99 %, soit moins de 53 minutes annuelles. Pour une application métier critique, c'est la différence entre un incident gérable et une interruption qui coûte.

Ce que la plupart des articles sur le K8s HA ne disent pas : la disponibilité ne se joue pas uniquement au niveau des worker nodes. Elle se gagne ou se perd au niveau du control plane et d'etcd. Comprendre ces deux couches avant de configurer quoi que ce soit est la condition d'une vraie haute disponibilité.

Ce qui détermine vraiment la disponibilité d'un cluster Kubernetes

Deux métriques pilotent toutes les décisions d'architecture HA.

Le RTO (Recovery Time Objective) mesure le temps nécessaire pour que les workloads soient recalculés sur les sites sains après une panne. Sur un cluster single-master, ce délai est de plusieurs minutes : il faut détecter la panne, reconstruire le control plane, puis rescheduler les pods. Sur un cluster multi-master avec etcd en quorum, le failover est automatique et se compte en secondes : le control plane continue de fonctionner sans intervention humaine.

Le RPO (Recovery Point Objective) définit la quantité de données potentiellement perdues lors d'un incident. Il dépend directement de la stratégie de réplication du stockage persistant. Une réplication synchrone garantit RPO visé (réplication synchrone ; pas un engagement publié) : aucune donnée n'est perdue car chaque écriture est confirmée sur tous les sites avant d'être acquittée. Une réplication asynchrone tolère une légère perte de données en échange d'une latence d'écriture réduite.

* SLA Hikube Kubernetes managé confirmé sur hikube.cloud/pourquoi-hikube

Ces métriques définissent les objectifs. L'architecture du control plane détermine si ces objectifs sont atteignables.

L'architecture du control plane Hikube sur 3 sites suisses

Le control plane Hikube fonctionne avec 3 réplicas opérés par Hikube, distribués sur les 3 datacenters suisses : Geneva, Gland et Lucerne. Chaque réplica comprend un kube-apiserver, un kube-scheduler et un kube-controller-manager. L'ensemble est complété par un cluster etcd répliqué entre les 3 sites.

Le mécanisme clé est le quorum etcd. Pour que le control plane continue de fonctionner, une majorité des membres etcd doit rester disponible. Avec 3 membres, ce quorum est de 2. Si le datacenter de Gland tombe en panne complète, Geneva et Lucerne maintiennent le quorum et le control plane continue de planifier les workloads sans interruption. Si 2 datacenters tombent simultanément, le quorum est perdu et le control plane passe en lecture seule jusqu'à restauration d'un troisième membre. Ce cas de figure, deux pannes de site simultanées, correspond à une probabilité inférieure à ce que couvre un SLA 99,99 %.

Ce mécanisme est entièrement opéré par Hikube. Le client ne gère pas etcd, ne surveille pas le quorum, ne déclenche pas le failover. La configuration control plane dans un manifeste cluster Hikube :

controlPlane:
  replicas: 3
  apiServer:
    resourcesPreset: small
  controllerManager:
    resourcesPreset: small
  scheduler:
    resourcesPreset: micro

Le control plane survivant à une panne de site ne suffit pas seul à maintenir la disponibilité applicative. La répartition des pods (topology spread, PDB) est le deuxième levier.

Pods : ce que Kubernetes ne répartit pas tout seul

Les worker nodes (node groups) tournent dans le tenant client. Hikube les répartit automatiquement sur Genève, Gland et Lucerne : vous ne choisissez pas le DC. Kubernetes ne répartit pas les pods tout seul : un Deployment avec 3 réplicas peut coller les trois dans le même datacenter. Si ce datacenter tombe, l'application est indisponible même si le control plane survit sur les deux autres sites.

Deux mécanismes corrigent ce comportement. Le premier est le topology spread constraint, qui force la répartition des pods entre zones de disponibilité :

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: mon-application

Le second est le PodDisruptionBudget, qui garantit qu'un nombre minimum de pods reste disponible pendant un rolling update ou une opération de maintenance :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: mon-application-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: mon-application

Ces deux configurations relèvent de la responsabilité du client, pas de Hikube. Un cluster correctement configuré côté Hikube mais sans ces contraintes côté workloads n'atteindra pas le SLA 99,99 % en pratique. Pour aller plus loin sur les stratégies de déploiements CI/CD sur Kubernetes, notre article dédié couvre les pipelines GitOps avec FluxCD.

StorageClass : le choix qui détermine votre RPO

Hikube propose la réplication des volumes persistants sur les trois sites pour les volumes persistants Kubernetes, chacune avec un compromis différent entre disponibilité, performance et complexité opérationnelle.

* Source, documentation Hikube , docs.hikube.cloud/services/kubernetes/faq

La règle de décision est directe, si une perte de données est inacceptable, utilisez réplication synchrone. Si la performance d'écriture prime et qu'une légère perte est tolérable, réplication asynchrone est le bon compromis. Les volumes bloc Hikube sont toujours géo-redondants (Genève, Gland, Lucerne), en synchrone ou en asynchrone. La storageClass se définit au niveau du manifeste cluster et s'applique à tous les PVC créés dans ce cluster. Pour les workloads GPU sur Kubernetes, la storageClass réplication synchrone est recommandée pour protéger les checkpoints de modèles.

Rolling updates sans interruption : ce que Hikube gère, ce que vous gérez

Les mises à jour de version Kubernetes se font par rolling update sans interruption du control plane. Hikube opère la rotation des composants control plane un par un, maintient le quorum etcd pendant toute la durée de l'upgrade, et gère les versions supportées. Le client déclenche la mise à jour via une modification du manifeste cluster.

Deux contraintes s'appliquent du côté client. D'abord, les upgrades doivent être incrémentaux : les upgrades restent incrémentaux (on ne saute pas de version mineure). Ensuite, les workloads doivent être configurés pour survivre au rolling update des worker nodes. Un Deployment critique sans PodDisruptionBudget ni maxUnavailable: 0 peut voir ses pods interrompus pendant la rotation des nodes.

Configuration recommandée pour les workloads critiques pendant un upgrade :

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Ce qui se passe quand le datacenter de Gland tombe à 3h du matin

Scénario concret sur un cluster de production Hikube correctement configuré, 3 réplicas control plane sur Geneva, Gland et Lucerne, storageClass réplication synchrone, nodeGroups avec topology spread constraints activés.

T+0 : panne complète du datacenter de Gland. L'ensemble des composants hébergés sur ce site devient indisponible.

T+15 secondes : le kube-apiserver détecte la perte du membre etcd de Gland. Le quorum est maintenu avec Geneva et Lucerne (2 membres sur 3). Le control plane continue de fonctionner en lecture et écriture sans interruption.

T+30 secondes : le kube-controller-manager identifie les pods orphelins précédemment hébergés sur Gland. Le kube-scheduler les recalcule sur les worker nodes disponibles à Geneva et Lucerne, en respectant les topology spread constraints.

T+45 à 60 secondes : les workloads avec minReplicas ≥ 2 et PodDisruptionBudgets configurés sont à nouveau pleinement opérationnels. Les volumes persistants en storageClass réplication synchrone sont accessibles depuis Geneva et Lucerne sans perte de données.

RTO : ordre de grandeur, pas un engagement publié pour les workloads correctement configurés. RPO visé (réplication synchrone ; pas un engagement publié) avec storageClass réplication synchrone. Ce scénario suppose une configuration conforme aux bonnes pratiques décrites dans cet article. Un cluster sans topology spread constraints ni PodDisruptionBudgets verra un RTO significativement plus long.

Synthèse

Trois couches déterminent la HA réelle d'un cluster K8s : le control plane multi-réplicas avec etcd en quorum sur 3 sites suisses (opéré par Hikube), la distribution des workloads via topology spread constraints et PodDisruptionBudgets (à configurer côté client), et le choix de storageClass adapté au RPO cible. La HA ne s'active pas d'un clic. C'est une combinaison de décisions d'architecture à chaque couche.

Votre cluster Kubernetes doit survivre à la panne d'un datacenter suisse. Voir notre offre Kubernetes managé →