Kubernetes über mehrere Kontinente: k3s und k8s hochverfügbar über Rechenzentren weltweit

Kubernetes ist der Standard, wenn Anwendungen ausfallsicher und automatisch skalierend laufen sollen. Die naheliegende Idee, einen einzigen Kubernetes-Cluster über Server in den USA, Europa und Asien zu spannen, scheitert allerdings an einem Detail: an etcd, der Datenbank, in der Kubernetes seinen gesamten Zustand speichert. Dieser Beitrag zeigt, wie Kubernetes über mehrere Kontinente trotzdem funktioniert, und zwar so, dass ein ganzer Kontinent ausfallen darf: mit einem Cluster je Region, einer gemeinsamen Auslieferung per GitOps und einem Geo-DNS, das die Nutzer zur nächsten gesunden Region schickt.

Wir bauen die Architektur mit k3s auf, der schlanken, vollständig zertifizierten Kubernetes-Distribution, die sich in Minuten installieren lässt, und zeigen am Ende, was sich mit einem klassischen Kubernetes per kubeadm ändert. Die Grundlagen zu Verfügbarkeit, Quorum und Failover über mehrere Standorte stehen ausführlich im Beitrag Docker Swarm über drei Kontinente; hier geht es um das, was bei Kubernetes anders ist.

Ein Cluster über alle Kontinente oder ein Cluster je Region?

Für Kubernetes über mehrere Kontinente ist ein Cluster je Region die richtige Architektur, nicht ein einziger Cluster über alle Kontinente. Jeder Cluster läuft für sich, alle werden aus demselben Git-Repository ausgerollt, und ein Geo-DNS mit Health Checks verteilt die Nutzer. Fällt eine Region aus, übernehmen die anderen, ohne dass ein gemeinsamer Clusterzustand über den Ozean abgestimmt werden muss.

Warum etcd keine Fernstrecken verträgt

Kubernetes speichert jeden Zustand, jede Konfiguration und jede Änderung in etcd, einem Schlüssel-Wert-Speicher mit Raft-Konsens. Jeder Schreibvorgang braucht die Bestätigung der Mehrheit aller etcd-Mitglieder. etcd arbeitet standardmäßig mit einem Herzschlag von 100 Millisekunden und einem Wahl-Timeout von einer Sekunde; zwischen Europa, Nordamerika und Asien liegen die Paketlaufzeiten bei 80 bis 250 Millisekunden. Man kann die Zeiten hochsetzen, aber dann wird jeder Schreibvorgang im Cluster langsam, von der Planung eines Pods bis zum Speichern eines Secrets. Die k3s-Dokumentation ist an dieser Stelle eindeutig: Das eingebaute etcd wird in über mehrere Netze verteilten Clustern nicht unterstützt, alle Server sollen am selben Standort stehen. Auch Kubernetes selbst ist dafür ausgelegt, dass ein Cluster mehrere Zonen innerhalb einer Region abdeckt, nicht mehrere Kontinente.

Die drei Muster im Vergleich

Der Ansatz „ein Cluster je Region" hat einen zweiten, oft unterschätzten Vorteil: Ein Fehler in der Steuerungsebene, eine fehlerhafte Änderung am Cluster oder ein Upgrade, das schiefgeht, trifft immer nur eine Region. Die Nutzer der anderen Regionen merken davon nichts.

k3s oder k8s?

Beide sind echtes Kubernetes mit derselben API, denselben Manifesten und denselben Werkzeugen. Der Unterschied liegt im Aufbau und im Aufwand:

Für die Architektur mit einem Cluster je Region empfehlen wir k3s: Drei Cluster zu betreiben ist nur dann angenehm, wenn jeder einzelne einfach ist. Wer bereits kubeadm-Erfahrung hat, übernimmt die Architektur unverändert, der Abschnitt zu kubeadm weiter unten zeigt die Unterschiede.

Die Architektur: drei Regionen, drei Cluster, ein Einstieg

Einstieg und Ausbau

Der Einstieg sind drei Server, je einer in den USA, in Europa und in Asien, jeder als eigener Einzelknoten-Cluster. Fällt ein Server aus, fällt seine Region aus, und der Geo-DNS schickt ihre Nutzer in die Nachbarregion. Diese Stufe ist bereits auf den Ausfall eines ganzen Kontinents ausgelegt. Im Ausbau bekommt jede Region drei Server am selben Standort, dann übersteht auch jede Region für sich den Ausfall eines Servers, ohne dass Nutzer umgeleitet werden müssen.

Welche KernelHost-Standorte sich eignen

KernelHost betreibt Server im maincubes-Rechenzentrum in Frankfurt am Main und bietet virtuelle Server an weiteren Standorten in Europa, Nordamerika und Asien-Pazifik an, darunter drei Standorte in den USA, Kanada, London, Straßburg, Warschau, Helsinki, Singapur, Japan, Sydney und Mumbai. Die vollständige Liste steht auf der Seite Serverstandorte. Das Beispiel dieses Beitrags nutzt Frankfurt am Main für Europa, die US-Ostküste für Nordamerika und Singapur für Asien.

Anleitung: Kubernetes mit k3s in drei Regionen

Das Beispiel nutzt drei Server mit Debian 12 oder 13: k3s-eu, k3s-us und k3s-asia. Öffentliche Adressen stammen aus dem Dokumentationsnetz 203.0.113.0/24, die Domain ist example.com. Ersetzen Sie beides durch Ihre Werte.

Schritt 1: Server in drei Regionen bereitstellen

Bestellen Sie drei Server in drei Regionen, mindestens mit 2 vCPU und 4 GB RAM, damit neben k3s auch Ihre Anwendung Platz hat. Setzen Sie die Grundabsicherung aus der Checkliste für neue Rootserver um und vergeben Sie sprechende Hostnamen. etcd profitiert spürbar von schnellen SSDs, die NVMe-Speicher der KernelHost-Server erfüllen das.

Schritt 2: k3s installieren

Auf jedem der drei Server installieren Sie k3s mit einem Befehl. Jeder Server wird damit zu einem vollständigen Kubernetes-Cluster mit einem Knoten:

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

Nach etwa einer Minute meldet kubectl get nodes den Knoten als Ready. Mitgeliefert sind Traefik als Ingress-Controller, Flannel als Netzwerk und ein Provisioner für lokale Volumes.

Schritt 3: Ausbau auf drei Server je Region

Soll eine Region selbst hochverfügbar werden, stellen Sie drei Server an denselben Standort. Der erste Server startet das eingebaute etcd, die beiden anderen treten mit einem gemeinsamen Token bei. etcd verlangt eine ungerade Zahl von Servern, bei drei Servern verkraftet die Region den Ausfall eines Servers:

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

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

Alle Server einer Region brauchen dieselben Einstellungen für Netzbereiche und Funktionen. Zwischen ihnen müssen die Ports 2379 bis 2380/TCP für etcd, 6443/TCP für die API, 10250/TCP für das Kubelet und 8472/UDP für das Flannel-Netz offen sein, nach außen bleiben sie gesperrt. Das Token ist ein Geheimnis: Wer es kennt, kann eigene Server in den Cluster bringen.

Schritt 4: Zugriff auf alle drei Cluster einrichten

k3s legt die Zugangsdaten unter /etc/rancher/k3s/k3s.yaml ab. Kopieren Sie die Datei jedes Clusters auf Ihren Arbeitsrechner, ersetzen Sie darin 127.0.0.1 durch die Adresse des Servers und benennen Sie die Kontexte nach der Region:

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

Die API auf Port 6443 ist der mächtigste Zugang zum Cluster. Erlauben Sie ihn in der Firewall nur von Ihrer eigenen Adresse oder einem VPN, nie für das ganze Internet. Die Datei k3s.yaml enthält ein Administratorzertifikat und gehört genauso sorgfältig verwahrt wie ein Root-Passwort.

Schritt 5: GitOps mit Flux in jedem Cluster

Damit alle drei Regionen dieselbe Anwendung in derselben Version betreiben, liegt der Sollzustand in einem Git-Repository, und in jedem Cluster läuft Flux, das diesen Zustand selbstständig herstellt. Jeder Cluster holt sich seine Konfiguration also selbst; einen zentralen Auslieferungsserver, der ausfallen könnte, gibt es nicht. Ein bewährter Aufbau des Repositorys:

apps/
  web/            gemeinsame Manifeste der Anwendung
clusters/
  eu/             Einstellungen und Version für Europa
  us/             Einstellungen und Version für Nordamerika
  asia/           Einstellungen und Version für Asien

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

Denselben Befehl führen Sie mit --path=clusters/us und --path=clusters/asia im jeweiligen Kontext aus. Weil jede Region ihr eigenes Verzeichnis hat, können Sie eine neue Version zuerst in einer Region ausrollen und erst danach in den anderen.

Schritt 6: Die Anwendung ausfallsicher beschreiben

Innerhalb einer Region sorgen drei Dinge dafür, dass die Anwendung Wartungen und Serverausfälle übersteht: mehrere Repliken, die auf verschiedene Knoten verteilt werden, Prüfungen, die kranke Pods erkennen, und ein Budget, das verhindert, dass eine Wartung alle Pods gleichzeitig entfernt:

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

Die Readiness-Prüfung nimmt einen Pod aus dem Verkehr, solange er nicht antwortet, die Liveness-Prüfung startet ihn neu, wenn er hängt. Bei einem Einzelknoten-Cluster wirkt die Verteilung auf mehrere Knoten noch nicht, sie greift automatisch, sobald die Region drei Server hat.

Schritt 7: Ingress und Zertifikate

Den Eingang übernimmt der mitgelieferte Traefik. Weil alle drei Regionen dieselbe Domain bedienen, beschaffen Sie die TLS-Zertifikate mit cert-manager über die DNS-Challenge: Sie funktioniert in jeder Region, unabhängig davon, wohin der DNS-Eintrag gerade zeigt. Die HTTP-Challenge scheitert dagegen in jeder Region, auf die der Eintrag gerade nicht zeigt. Wer ohne Kubernetes-Ingress arbeitet, findet die Grundlagen im Beitrag nginx als Reverse Proxy einrichten.

Schritt 8: Geo-DNS mit Failover einrichten

Ein DNS-Dienst mit Geo-Routing und Health Checks schickt Nutzer aus Europa nach Frankfurt am Main, aus Amerika an die US-Ostküste und aus Asien nach Singapur und prüft alle 30 bis 60 Sekunden, ob der Eingang jeder Region antwortet. Fällt eine Region aus, gibt er ihre Adresse nicht mehr heraus. Setzen Sie die TTL der Einträge auf 60 Sekunden, dann ist eine Umstellung meist nach ein bis zwei Minuten abgeschlossen. Wer die Einträge aus dem Cluster heraus pflegen möchte, kann dafür external-dns einsetzen.

Schritt 9: Region für Region ausrollen und den Ausfall testen

Eine neue Version tragen Sie zuerst im Verzeichnis einer Region ein, beobachten die Region einige Minuten und übernehmen die Version danach für die anderen. So erreicht ein Fehler, den keine Prüfung erkennt, höchstens eine Region. Den Ausfall einer Region proben Sie, indem Sie k3s auf ihrem Server anhalten, und prüfen dabei, ob der Geo-DNS die Region aus den Antworten nimmt und die Nachbarregion die Last trägt:

systemctl stop k3s
systemctl start k3s

In einer Region mit drei Servern proben Sie zusätzlich die Wartung eines einzelnen Servers. kubectl drain verlagert die Pods unter Beachtung des Budgets aus Schritt 6, kubectl uncordon nimmt den Server wieder in Betrieb:

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

Daten über Regionen hinweg

Kubernetes verteilt Pods, keine Daten. Ein PersistentVolume des mitgelieferten Provisioners liegt auf genau einem Knoten, und zwischen den Clustern gibt es von Haus aus gar keine gemeinsame Datenhaltung. Für alles mit Daten gilt deshalb dasselbe wie bei jedem Cluster über mehrere Standorte:

• Datenbanken replizieren sich selbst. Bewährt ist eine primäre Instanz in einer Region mit Replikaten in den anderen; Datenbank-Operatoren wie CloudNativePG für PostgreSQL unterstützen solche Replikate auch über Clustergrenzen hinweg. Über Kontinente läuft die Replikation asynchron, im Ernstfall können die letzten Sekunden an Schreibvorgängen fehlen. Für verlustfreies Schreiben weltweit gibt es Datenbanken für mehrere Regionen wie CockroachDB oder YugabyteDB.
• Dateien und Uploads gehören in einen S3-kompatiblen Objektspeicher mit Replikation in eine zweite Region.
• Sitzungen liegen in einer replizierten Datenbank oder einem replizierten Cache, oder die Anwendung nutzt signierte Token.
• Backups bleiben Pflicht, weil Replikation Fehler genauso verteilt wie gute Daten. Für Kubernetes-Objekte und Volumes eignet sich Velero, für die Grundlagen siehe die Backup-Strategie für Server.

Kubernetes mit kubeadm statt k3s

Die Architektur bleibt mit kubeadm dieselbe: ein Cluster je Region, GitOps, Geo-DNS. Anders ist der Aufbau jedes Clusters. Sie installieren auf allen Knoten eine Container-Runtime wie containerd sowie kubeadm, kubelet und kubectl, setzen vor die API der Region einen Load Balancer oder eine virtuelle Adresse, etwa mit kube-vip, und initialisieren den ersten Control-Plane-Knoten:

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

Die Ausgabe enthält zwei Beitrittsbefehle: einen mit --control-plane --certificate-key für die beiden weiteren Control-Plane-Knoten und einen für Worker. Danach installieren Sie ein Netzwerk-Plugin wie Calico oder Cilium und einen Ingress-Controller, den k3s bereits mitbringt. Der Mehraufwand lohnt sich, wenn Sie einzelne Komponenten gezielt auswählen oder eng an der Upstream-Version bleiben müssen.

Warum KernelHost für Kubernetes über mehrere Kontinente

Einen Überblick über alle Cloud-Tarife und einen Kostenvergleich mit den großen Cloud-Anbietern finden Sie auf der Seite Cloud-Server mieten.

Häufige Fehler und wie Sie sie vermeiden

• etcd über Kontinente gespannt. Langsame Schreibvorgänge und instabile Wahlen sind die Folge, bei k3s mit eingebautem etcd ist es nicht unterstützt. Lösung: ein Cluster je Region.
• Zwei Server in einer Region. etcd braucht eine Mehrheit, zwei Server verkraften keinen Ausfall. Lösung: einer oder drei.
• API für das ganze Internet offen. Port 6443 ist der Generalschlüssel zum Cluster. Lösung: nur von der eigenen Adresse oder per VPN.
• Zentraler Auslieferungsserver. Fällt er aus, lässt sich nichts mehr ausrollen. Lösung: Flux in jedem Cluster, das sich selbst aus Git bedient.
• Update in allen Regionen gleichzeitig. Ein Fehler trifft dann alle Nutzer. Lösung: Region für Region über die Verzeichnisse im Repository.
• Zertifikate per HTTP-Challenge. In Regionen, auf die der DNS-Eintrag gerade nicht zeigt, scheitert die Erneuerung. Lösung: DNS-Challenge.
• Datenbank im lokalen Volume ohne Replikation. Fällt der Knoten aus, sind die Daten nicht erreichbar. Lösung: Replikation über einen Datenbank-Operator.
• Keine Probes und kein Budget. Kranke Pods bekommen weiter Verkehr, Wartungen nehmen alle Pods gleichzeitig vom Netz. Lösung: Readiness- und Liveness-Prüfung plus PodDisruptionBudget.

Kurz zusammengefasst

• Für Kubernetes über mehrere Kontinente ist ein Cluster je Region richtig, ein einziger Cluster über alle Kontinente scheitert an der Latenz von etcd.
• Der Einstieg sind drei Server, je einer in den USA, in Europa und in Asien; schon diese Stufe übersteht den Ausfall eines ganzen Kontinents.
• Im Ausbau bekommt jede Region drei Server am selben Standort, dann übersteht jede Region auch Ausfälle einzelner Server.
• Flux in jedem Cluster rollt die Anwendung aus demselben Git-Repository aus, Region für Region.
• Geo-DNS mit Health Checks und kurzer TTL schickt Nutzer zur nächsten gesunden Region, Zertifikate kommen per DNS-Challenge.
• Kubernetes verteilt Pods, keine Daten: Datenbanken brauchen eigene Replikation, Backups bleiben Pflicht.
• k3s ist für diese Architektur meist die bessere Wahl als kubeadm, weil drei einfache Cluster leichter zu betreiben sind als drei komplexe.