Kubernetes sur plusieurs continents : k3s et k8s en haute disponibilité dans des centres de données du monde entier

Kubernetes est la référence dès que des applications doivent résister aux pannes et monter en charge automatiquement. L'idée la plus évidente consiste à étendre un seul cluster Kubernetes sur des serveurs situés aux États-Unis, en Europe et en Asie, mais elle bute sur un détail : etcd, la base de données dans laquelle Kubernetes enregistre l'intégralité de son état. Cet article montre comment faire tout de même fonctionner Kubernetes sur plusieurs continents, et ce de telle sorte qu'un continent entier puisse tomber en panne : avec un cluster par région, un déploiement commun par GitOps et un Geo-DNS qui envoie les utilisateurs vers la région saine la plus proche.

Nous construisons l'architecture avec k3s, la distribution Kubernetes légère et entièrement certifiée qui s'installe en quelques minutes, puis nous montrons à la fin ce qui change avec un Kubernetes classique installé via kubeadm. Les bases sur la disponibilité, le quorum et le failover entre plusieurs sites sont détaillées dans l'article Docker Swarm sur trois continents ; ici, il est question de ce qui diffère avec Kubernetes.

Un cluster sur tous les continents ou un cluster par région ?

Pour Kubernetes sur plusieurs continents, la bonne architecture est un cluster par région, et non un cluster unique qui s'étend sur tous les continents. Chaque cluster fonctionne de manière autonome, tous sont déployés à partir du même dépôt Git, et un Geo-DNS avec health checks répartit les utilisateurs. Si une région tombe en panne, les autres prennent le relais, sans qu'un état de cluster commun doive être coordonné de part et d'autre de l'océan.

Pourquoi etcd ne supporte pas les longues distances

Kubernetes enregistre chaque état, chaque configuration et chaque modification dans etcd, un magasin clé-valeur fondé sur le consensus Raft. Chaque écriture doit être confirmée par la majorité des membres etcd. Par défaut, etcd fonctionne avec un intervalle de heartbeat de 100 millisecondes et un délai d'élection d'une seconde ; entre l'Europe, l'Amérique du Nord et l'Asie, le temps de transit des paquets se situe entre 80 et 250 millisecondes. On peut augmenter ces valeurs, mais chaque écriture dans le cluster devient alors lente, de l'ordonnancement d'un pod à l'enregistrement d'un secret. La documentation de k3s est sans ambiguïté sur ce point : l'etcd intégré n'est pas pris en charge dans les clusters répartis sur plusieurs réseaux, et tous les serveurs doivent se trouver sur le même site. Kubernetes lui-même est d'ailleurs conçu pour qu'un cluster couvre plusieurs zones au sein d'une même région, et non plusieurs continents.

Comparaison des trois modèles

L'approche « un cluster par région » présente un second avantage, souvent sous-estimé : une erreur dans le plan de contrôle, une modification défectueuse du cluster ou une mise à niveau qui tourne mal ne touche jamais qu'une seule région. Les utilisateurs des autres régions ne s'en aperçoivent pas.

k3s ou k8s ?

Les deux sont du vrai Kubernetes, avec la même API, les mêmes manifestes et les mêmes outils. La différence tient à leur architecture et à l'effort qu'ils demandent :

Pour l'architecture à un cluster par région, nous recommandons k3s : exploiter trois clusters n'est confortable que si chacun d'eux est simple. Si vous avez déjà de l'expérience avec kubeadm, vous reprenez l'architecture telle quelle ; la section consacrée à kubeadm, plus bas, présente les différences.

L'architecture : trois régions, trois clusters, un point d'entrée

Configuration de départ et extension

La configuration de départ se compose de trois serveurs, un aux États-Unis, un en Europe et un en Asie, chacun formant son propre cluster à nœud unique. Si un serveur tombe en panne, sa région tombe avec lui, et le Geo-DNS envoie les utilisateurs de cette région vers la région voisine. Cette configuration de départ est déjà conçue pour résister à la panne d'un continent entier. Dans la configuration étendue, chaque région reçoit trois serveurs sur le même site : chaque région survit alors aussi, par elle-même, à la panne d'un serveur, sans que les utilisateurs doivent être redirigés.

Quels sites KernelHost conviennent

KernelHost exploite des serveurs dans le centre de données maincubes de Francfort-sur-le-Main et propose des serveurs virtuels sur d'autres sites en Europe, en Amérique du Nord et en Asie-Pacifique, dont trois sites aux États-Unis, le Canada, Londres, Strasbourg, Varsovie, Helsinki, Singapour, le Japon, Sydney et Mumbai. La liste complète figure sur la page Emplacements des serveurs. L'exemple de cet article utilise Francfort-sur-le-Main pour l'Europe, la côte Est des États-Unis pour l'Amérique du Nord et Singapour pour l'Asie.

Guide : Kubernetes avec k3s dans trois régions

L'exemple utilise trois serveurs sous Debian 12 ou 13 : k3s-eu, k3s-us et k3s-asia. Les adresses publiques proviennent du réseau de documentation 203.0.113.0/24, et le domaine est example.com. Remplacez les deux par vos propres valeurs.

Étape 1 : provisionner les serveurs dans trois régions

Commandez trois serveurs dans trois régions, avec au moins 2 vCPU et 4 Go de RAM, afin que votre application ait aussi sa place à côté de k3s. Appliquez la sécurisation de base de la checklist pour les nouveaux serveurs root et attribuez des noms d'hôte explicites. etcd tire un net avantage de SSD rapides : le stockage NVMe des serveurs KernelHost répond à cette exigence.

Étape 2 : installer k3s

Sur chacun des trois serveurs, installez k3s avec une seule commande. Chaque serveur devient ainsi un cluster Kubernetes complet à un nœud :

curl -sfL https://get.k3s.io | sh -
kubectl get nodes

Au bout d'une minute environ, kubectl get nodes indique que le nœud est Ready. k3s fournit d'origine Traefik comme contrôleur Ingress, Flannel pour le réseau et un provisionneur de volumes locaux.

Étape 3 : passer à trois serveurs par région

Si une région doit elle-même devenir hautement disponible, placez trois serveurs sur le même site. Le premier serveur démarre l'etcd intégré, les deux autres rejoignent le cluster avec un jeton commun. etcd exige un nombre impair de serveurs ; avec trois serveurs, la région supporte la panne de l'un d'eux :

curl -sfL https://get.k3s.io | K3S_TOKEN=JETON_SECRET sh -s - server \
    --cluster-init \
    --tls-san=api.eu.example.com

curl -sfL https://get.k3s.io | K3S_TOKEN=JETON_SECRET sh -s - server \
    --server https://203.0.113.21:6443 \
    --tls-san=api.eu.example.com

Tous les serveurs d'une région ont besoin des mêmes paramètres pour les plages réseau et les fonctionnalités. Entre eux, les ports 2379 à 2380/TCP pour etcd, 6443/TCP pour l'API, 10250/TCP pour le kubelet et 8472/UDP pour le réseau Flannel doivent être ouverts ; vers l'extérieur, ils restent bloqués. Le jeton est un secret : quiconque le connaît peut faire entrer ses propres serveurs dans le cluster.

Étape 4 : configurer l'accès aux trois clusters

k3s enregistre les identifiants d'accès dans /etc/rancher/k3s/k3s.yaml. Copiez le fichier de chaque cluster sur votre poste de travail, remplacez-y 127.0.0.1 par l'adresse du serveur et nommez les contextes d'après la région :

kubectl config rename-context default eu
kubectl config use-context eu
kubectl --context us get nodes

L'API sur le port 6443 est l'accès le plus puissant au cluster. Dans le pare-feu, ne l'autorisez que depuis votre propre adresse ou via un VPN, jamais pour tout Internet. Le fichier k3s.yaml contient un certificat d'administrateur et doit être conservé avec autant de soin qu'un mot de passe root.

Étape 5 : GitOps avec Flux dans chaque cluster

Pour que les trois régions exploitent la même application dans la même version, l'état souhaité est stocké dans un dépôt Git, et dans chaque cluster tourne Flux, qui établit cet état de manière autonome. Chaque cluster récupère donc lui-même sa configuration ; il n'existe aucun serveur de déploiement central susceptible de tomber en panne. Une structure de dépôt éprouvée :

apps/
  web/            manifestes communs de l'application
clusters/
  eu/             paramètres et version pour l'Europe
  us/             paramètres et version pour l'Amérique du Nord
  asia/           paramètres et version pour l'Asie

flux bootstrap git --url=ssh://git@git.example.com/infra/fleet.git --branch=main --path=clusters/eu

Exécutez la même commande avec --path=clusters/us et --path=clusters/asia dans le contexte correspondant. Comme chaque région a son propre répertoire, vous pouvez déployer une nouvelle version d'abord dans une région, et seulement ensuite dans les autres.

Étape 6 : décrire l'application pour qu'elle résiste aux pannes

Au sein d'une région, trois éléments permettent à l'application de survivre aux maintenances et aux pannes de serveurs : plusieurs réplicas répartis sur différents nœuds, des sondes qui détectent les pods défaillants, et un budget qui empêche une maintenance de retirer tous les pods en même temps :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: web
      containers:
        - name: web
          image: registry.example.com/web:1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 10
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: web

La sonde de readiness retire un pod du trafic tant qu'il ne répond pas, la sonde de liveness le redémarre s'il est bloqué. Dans un cluster à nœud unique, la répartition sur plusieurs nœuds n'a pas encore d'effet ; elle s'applique automatiquement dès que la région compte trois serveurs.

Étape 7 : Ingress et certificats

C'est le Traefik fourni d'origine qui fait office de point d'entrée. Comme les trois régions servent le même domaine, obtenez les certificats TLS avec cert-manager via le challenge DNS : il fonctionne dans chaque région, quelle que soit la cible actuelle de l'enregistrement DNS. Le challenge HTTP échoue en revanche dans chaque région vers laquelle l'enregistrement ne pointe pas à ce moment-là. Si vous travaillez sans Ingress Kubernetes, vous trouverez les bases dans l'article Configurer nginx en reverse proxy.

Étape 8 : mettre en place un Geo-DNS avec failover

Un service DNS avec routage géographique et health checks envoie les utilisateurs d'Europe vers Francfort-sur-le-Main, ceux d'Amérique vers la côte Est des États-Unis et ceux d'Asie vers Singapour, et vérifie toutes les 30 à 60 secondes que le point d'entrée de chaque région répond. Si une région tombe en panne, il ne renvoie plus son adresse. Réglez le TTL des enregistrements sur 60 secondes : une bascule est alors généralement terminée en une à deux minutes. Si vous souhaitez gérer les enregistrements depuis le cluster, vous pouvez utiliser external-dns.

Étape 9 : déployer région par région et tester la panne

Inscrivez une nouvelle version d'abord dans le répertoire d'une seule région, observez cette région pendant quelques minutes, puis appliquez la version aux autres. Ainsi, une erreur qu'aucune vérification ne détecte n'atteint jamais plus d'une région. Pour simuler la panne d'une région, arrêtez k3s sur son serveur, puis vérifiez que le Geo-DNS retire la région de ses réponses et que la région voisine absorbe la charge :

systemctl stop k3s
systemctl start k3s

Dans une région à trois serveurs, testez en plus la maintenance d'un serveur isolé. kubectl drain déplace les pods en respectant le budget de l'étape 6, kubectl uncordon remet le serveur en service :

kubectl drain k3s-eu-2 --ignore-daemonsets --delete-emptydir-data
kubectl uncordon k3s-eu-2

Les données réparties sur plusieurs régions

Kubernetes répartit des pods, pas des données. Un PersistentVolume créé par le provisionneur fourni d'origine se trouve sur un seul et unique nœud, et il n'existe par défaut aucun stockage de données commun entre les clusters. Pour tout ce qui contient des données, les règles sont donc les mêmes que pour n'importe quel cluster réparti sur plusieurs sites :

• Les bases de données se répliquent elles-mêmes. Une approche éprouvée consiste à placer une instance primaire dans une région et des réplicas dans les autres ; des opérateurs de bases de données comme CloudNativePG pour PostgreSQL prennent en charge ces réplicas y compris au-delà des limites d'un cluster. Entre continents, la réplication est asynchrone : en cas d'incident, les dernières secondes d'écritures peuvent manquer. Pour des écritures sans perte à l'échelle mondiale, il existe des bases de données multi-régions comme CockroachDB ou YugabyteDB.
• Les fichiers et les uploads ont leur place dans un stockage objet compatible S3, répliqué vers une seconde région.
• Les sessions sont stockées dans une base de données ou un cache répliqués, ou bien l'application utilise des jetons signés.
• Les sauvegardes restent indispensables, car la réplication propage les erreurs tout comme les bonnes données. Pour les objets Kubernetes et les volumes, Velero convient ; pour les principes de base, consultez la stratégie de sauvegarde pour serveurs.

Kubernetes avec kubeadm au lieu de k3s

Avec kubeadm, l'architecture reste la même : un cluster par région, GitOps, Geo-DNS. Ce qui change, c'est la construction de chaque cluster. Vous installez sur tous les nœuds un runtime de conteneurs comme containerd, ainsi que kubeadm, kubelet et kubectl, vous placez devant l'API de la région un load balancer ou une adresse virtuelle, par exemple avec kube-vip, puis vous initialisez le premier nœud du plan de contrôle :

kubeadm init --control-plane-endpoint "api.eu.example.com:6443" --upload-certs

La sortie contient deux commandes de jonction : l'une avec --control-plane --certificate-key pour les deux autres nœuds du plan de contrôle, l'autre pour les workers. Installez ensuite un plugin réseau comme Calico ou Cilium, ainsi qu'un contrôleur Ingress, que k3s fournit déjà d'origine. Cet effort supplémentaire en vaut la peine si vous devez choisir précisément certains composants ou rester au plus près de la version upstream.

Pourquoi KernelHost pour Kubernetes sur plusieurs continents

Vous trouverez une vue d'ensemble de toutes les offres cloud et une comparaison des coûts avec les grands fournisseurs de cloud sur la page Louer un serveur cloud.

Erreurs fréquentes et comment les éviter

• etcd étendu sur plusieurs continents. Il en résulte des écritures lentes et des élections instables, et avec l'etcd intégré de k3s, cette configuration n'est pas prise en charge. Solution : un cluster par région.
• Deux serveurs dans une région. etcd a besoin d'une majorité, et deux serveurs ne supportent aucune panne. Solution : un serveur ou trois.
• API ouverte à tout Internet. Le port 6443 est le passe-partout du cluster. Solution : accès uniquement depuis votre propre adresse ou via un VPN.
• Serveur de déploiement central. S'il tombe en panne, plus rien ne peut être déployé. Solution : Flux dans chaque cluster, qui se sert lui-même dans Git.
• Mise à jour dans toutes les régions en même temps. Une erreur touche alors tous les utilisateurs. Solution : région par région, via les répertoires du dépôt.
• Certificats par challenge HTTP. Dans les régions vers lesquelles l'enregistrement DNS ne pointe pas à ce moment-là, le renouvellement échoue. Solution : challenge DNS.
• Base de données sur un volume local sans réplication. Si le nœud tombe en panne, les données sont inaccessibles. Solution : réplication via un opérateur de base de données.
• Ni sondes ni budget. Les pods défaillants continuent de recevoir du trafic, et les maintenances mettent tous les pods hors ligne en même temps. Solution : sondes de readiness et de liveness, plus un PodDisruptionBudget.

En résumé

• Pour Kubernetes sur plusieurs continents, un cluster par région est la bonne approche ; un cluster unique étendu sur tous les continents échoue à cause de la latence d'etcd.
• La configuration de départ comprend trois serveurs, un aux États-Unis, un en Europe et un en Asie ; elle survit déjà à la panne d'un continent entier.
• Dans la configuration étendue, chaque région reçoit trois serveurs sur le même site ; chaque région survit alors aussi à la panne de serveurs isolés.
• Flux, dans chaque cluster, déploie l'application à partir du même dépôt Git, région par région.
• Un Geo-DNS avec health checks et un TTL court envoie les utilisateurs vers la région saine la plus proche ; les certificats sont obtenus par challenge DNS.
• Kubernetes répartit des pods, pas des données : les bases de données ont besoin de leur propre réplication, et les sauvegardes restent indispensables.
• Pour cette architecture, k3s est généralement un meilleur choix que kubeadm, car trois clusters simples sont plus faciles à exploiter que trois clusters complexes.