Kubernetes over meerdere continenten: k3s en k8s hoogbeschikbaar in datacenters wereldwijd

Kubernetes is de standaard als applicaties bestand moeten zijn tegen uitval en automatisch moeten schalen. Het voor de hand liggende idee om één enkel Kubernetes-cluster over servers in de VS, Europa en Azië te spannen, loopt echter stuk op één detail: etcd, de database waarin Kubernetes zijn volledige toestand opslaat. Dit artikel laat zien hoe Kubernetes over meerdere continenten toch werkt, en wel zo dat een heel continent mag uitvallen: met één cluster per regio, een gezamenlijke uitrol via GitOps en een Geo-DNS die gebruikers naar de dichtstbijzijnde gezonde regio stuurt.

We bouwen de architectuur op met k3s, de lichtgewicht, volledig gecertificeerde Kubernetes-distributie die binnen enkele minuten is geïnstalleerd, en laten aan het eind zien wat er verandert bij een klassieke Kubernetes-installatie met kubeadm. De basisprincipes van beschikbaarheid, quorum en failover over meerdere locaties staan uitgebreid in het artikel Docker Swarm over drie continenten; hier gaat het om wat er bij Kubernetes anders is.

Eén cluster over alle continenten of één cluster per regio?

Voor Kubernetes over meerdere continenten is één cluster per regio de juiste architectuur, niet één enkel cluster over alle continenten. Elk cluster draait zelfstandig, alle clusters worden uitgerold vanuit dezelfde Git-repository en een Geo-DNS met health checks verdeelt de gebruikers. Valt een regio uit, dan nemen de andere het over, zonder dat een gezamenlijke clustertoestand over de oceaan heen moet worden afgestemd.

Waarom etcd niet tegen lange afstanden kan

Kubernetes slaat elke toestand, elke configuratie en elke wijziging op in etcd, een key-value-store met Raft-consensus. Elke schrijfbewerking heeft de bevestiging nodig van de meerderheid van alle etcd-leden. etcd werkt standaard met een heartbeat van 100 milliseconden en een verkiezingstime-out van één seconde; tussen Europa, Noord-Amerika en Azië bedraagt de latentie 80 tot 250 milliseconden. U kunt die tijden verhogen, maar dan wordt elke schrijfbewerking in het cluster traag, van het inplannen van een pod tot het opslaan van een secret. De k3s-documentatie is op dit punt duidelijk: de ingebouwde etcd wordt niet ondersteund in clusters die over meerdere netwerken zijn verspreid, alle servers horen op dezelfde locatie te staan. Ook Kubernetes zelf is erop ingericht dat een cluster meerdere zones binnen één regio bestrijkt, niet meerdere continenten.

De drie patronen vergeleken

De aanpak „één cluster per regio" heeft een tweede, vaak onderschat voordeel: een fout in de control plane, een foutieve wijziging aan het cluster of een upgrade die misgaat, treft altijd maar één regio. De gebruikers in de andere regio's merken daar niets van.

k3s of k8s?

Beide zijn echt Kubernetes, met dezelfde API, dezelfde manifesten en dezelfde tools. Het verschil zit in de opbouw en in de hoeveelheid werk:

Voor de architectuur met één cluster per regio raden we k3s aan: drie clusters beheren is alleen prettig als elk afzonderlijk cluster eenvoudig is. Wie al ervaring heeft met kubeadm, neemt de architectuur ongewijzigd over; het gedeelte over kubeadm verderop laat de verschillen zien.

De architectuur: drie regio's, drie clusters, één toegangspunt

Startopstelling en uitbreiding

De startopstelling bestaat uit drie servers, één in de VS, één in Europa en één in Azië, elk als eigen cluster met één node. Valt een server uit, dan valt zijn regio uit en stuurt de Geo-DNS de gebruikers van die regio naar de naburige regio. Deze opstelling is al ingericht op de uitval van een heel continent. Bij de uitbreiding krijgt elke regio drie servers op dezelfde locatie; dan overleeft ook elke regio op zichzelf de uitval van een server, zonder dat gebruikers hoeven te worden omgeleid.

Welke KernelHost-locaties geschikt zijn

KernelHost beheert servers in het maincubes-datacenter in Frankfurt am Main en biedt virtuele servers aan op andere locaties in Europa, Noord-Amerika en Azië-Pacific, waaronder drie locaties in de VS, Canada, Londen, Straatsburg, Warschau, Helsinki, Singapore, Japan, Sydney en Mumbai. De volledige lijst staat op de pagina Serverlocaties. Het voorbeeld in dit artikel gebruikt Frankfurt am Main voor Europa, de oostkust van de VS voor Noord-Amerika en Singapore voor Azië.

Handleiding: Kubernetes met k3s in drie regio's

Het voorbeeld gebruikt drie servers met Debian 12 of 13: k3s-eu, k3s-us en k3s-asia. De publieke adressen komen uit het documentatienetwerk 203.0.113.0/24, het domein is example.com. Vervang beide door uw eigen waarden.

Stap 1: servers in drie regio's klaarzetten

Bestel drie servers in drie regio's, met minimaal 2 vCPU en 4 GB RAM, zodat naast k3s ook uw applicatie ruimte heeft. Voer de basisbeveiliging uit de checklist voor nieuwe rootservers door en geef de servers herkenbare hostnamen. etcd heeft merkbaar baat bij snelle SSD's, en de NVMe-opslag van de KernelHost-servers voldoet daaraan.

Stap 2: k3s installeren

Op elk van de drie servers installeert u k3s met één commando. Elke server wordt daarmee een volledig Kubernetes-cluster met één node:

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

Na ongeveer een minuut meldt kubectl get nodes de node als Ready. Meegeleverd worden Traefik als ingress-controller, Flannel als netwerk en een provisioner voor lokale volumes.

Stap 3: uitbreiden naar drie servers per regio

Moet een regio zelf hoogbeschikbaar worden, zet dan drie servers op dezelfde locatie. De eerste server start de ingebouwde etcd, de andere twee sluiten zich aan met een gedeeld token. etcd vereist een oneven aantal servers; met drie servers kan de regio de uitval van één server opvangen:

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

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

Alle servers van een regio hebben dezelfde instellingen nodig voor netwerkbereiken en functies. Tussen die servers moeten de poorten 2379 tot en met 2380/TCP voor etcd, 6443/TCP voor de API, 10250/TCP voor de kubelet en 8472/UDP voor het Flannel-netwerk openstaan; naar buiten blijven ze geblokkeerd. Het token is een geheim: wie het kent, kan eigen servers aan het cluster toevoegen.

Stap 4: toegang tot alle drie de clusters inrichten

k3s slaat de toegangsgegevens op in /etc/rancher/k3s/k3s.yaml. Kopieer dat bestand van elk cluster naar uw werkcomputer, vervang daarin 127.0.0.1 door het adres van de server en geef de contexten de naam van hun regio:

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

De API op poort 6443 is de krachtigste toegang tot het cluster. Sta die in de firewall alleen toe vanaf uw eigen adres of een VPN, nooit voor het hele internet. Het bestand k3s.yaml bevat een beheerderscertificaat en moet net zo zorgvuldig worden bewaard als een rootwachtwoord.

Stap 5: GitOps met Flux in elk cluster

Om alle drie de regio's dezelfde applicatie in dezelfde versie te laten draaien, staat de gewenste toestand in een Git-repository en draait in elk cluster Flux, dat die toestand zelfstandig tot stand brengt. Elk cluster haalt zijn configuratie dus zelf op; een centrale uitrolserver die kan uitvallen, is er niet. Een beproefde opbouw van de repository:

apps/
  web/            gedeelde manifesten van de applicatie
clusters/
  eu/             instellingen en versie voor Europa
  us/             instellingen en versie voor Noord-Amerika
  asia/           instellingen en versie voor Azië

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

Hetzelfde commando voert u in de betreffende context uit met --path=clusters/us en --path=clusters/asia. Omdat elke regio een eigen map heeft, kunt u een nieuwe versie eerst in één regio uitrollen en pas daarna in de andere.

Stap 6: de applicatie fouttolerant beschrijven

Binnen een regio zorgen drie dingen ervoor dat de applicatie onderhoud en serveruitval overleeft: meerdere replica's die over verschillende nodes worden verdeeld, controles die ongezonde pods herkennen, en een budget dat voorkomt dat onderhoud alle pods tegelijk verwijdert:

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

De readiness-probe haalt een pod uit het verkeer zolang hij niet antwoordt, de liveness-probe start hem opnieuw als hij vastloopt. Bij een cluster met één node heeft de verdeling over meerdere nodes nog geen effect; die treedt automatisch in werking zodra de regio drie servers heeft.

Stap 7: ingress en certificaten

De ingang wordt verzorgd door de meegeleverde Traefik. Omdat alle drie de regio's hetzelfde domein bedienen, haalt u de TLS-certificaten met cert-manager op via de DNS-challenge: die werkt in elke regio, ongeacht waar het DNS-record op dat moment naar verwijst. De HTTP-challenge mislukt daarentegen in elke regio waar het record op dat moment niet naar verwijst. Wie zonder Kubernetes-ingress werkt, vindt de basis in het artikel nginx als reverse proxy instellen.

Stap 8: Geo-DNS met failover inrichten

Een DNS-dienst met geo-routing en health checks stuurt gebruikers uit Europa naar Frankfurt am Main, uit Amerika naar de oostkust van de VS en uit Azië naar Singapore, en controleert om de 30 tot 60 seconden of de ingang van elke regio antwoordt. Valt een regio uit, dan geeft hij het adres van die regio niet meer uit. Zet de TTL van de records op 60 seconden; dan is een omschakeling meestal na een à twee minuten afgerond. Wie de records vanuit het cluster wil beheren, kan daarvoor external-dns gebruiken.

Stap 9: regio voor regio uitrollen en de uitval testen

Een nieuwe versie zet u eerst in de map van één regio, u houdt die regio een paar minuten in de gaten en neemt de versie daarna over voor de andere. Zo bereikt een fout die door geen enkele controle wordt opgemerkt, hooguit één regio. De uitval van een regio test u door k3s op de server van die regio te stoppen; controleer daarbij of de Geo-DNS de regio uit de antwoorden haalt en of de naburige regio de belasting opvangt:

systemctl stop k3s
systemctl start k3s

In een regio met drie servers test u daarnaast het onderhoud van één afzonderlijke server. kubectl drain verplaatst de pods met inachtneming van het budget uit stap 6, kubectl uncordon neemt de server weer in gebruik:

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

Data over regio's heen

Kubernetes verdeelt pods, geen data. Een PersistentVolume van de meegeleverde provisioner staat op precies één node, en tussen de clusters is er standaard helemaal geen gedeelde dataopslag. Voor alles met data geldt daarom hetzelfde als bij elk cluster over meerdere locaties:

• Databases repliceren zichzelf. Een beproefde opzet is een primaire instantie in één regio met replica's in de andere regio's; database-operators zoals CloudNativePG voor PostgreSQL ondersteunen zulke replica's ook over clustergrenzen heen. Over continenten verloopt de replicatie asynchroon; in een noodgeval kunnen de laatste seconden aan schrijfbewerkingen ontbreken. Voor verliesvrij schrijven wereldwijd zijn er databases voor meerdere regio's, zoals CockroachDB of YugabyteDB.
• Bestanden en uploads horen thuis in S3-compatibele objectopslag met replicatie naar een tweede regio.
• Sessies staan in een gerepliceerde database of een gerepliceerde cache, of de applicatie gebruikt ondertekende tokens.
• Back-ups blijven verplicht, omdat replicatie fouten net zo goed verspreidt als goede data. Voor Kubernetes-objecten en volumes is Velero geschikt; de basisprincipes staan in de back-upstrategie voor servers.

Kubernetes met kubeadm in plaats van k3s

Met kubeadm blijft de architectuur dezelfde: één cluster per regio, GitOps, Geo-DNS. Wat verschilt, is de opbouw van elk cluster. U installeert op alle nodes een container-runtime zoals containerd, plus kubeadm, kubelet en kubectl, plaatst vóór de API van de regio een loadbalancer of een virtueel adres, bijvoorbeeld met kube-vip, en initialiseert de eerste control-plane-node:

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

De uitvoer bevat twee join-commando's: één met --control-plane --certificate-key voor de twee andere control-plane-nodes en één voor workers. Daarna installeert u een netwerkplug-in zoals Calico of Cilium en een ingress-controller, die k3s al meelevert. Het extra werk loont als u afzonderlijke componenten gericht moet kiezen of dicht bij de upstream-versie moet blijven.

Waarom KernelHost voor Kubernetes over meerdere continenten

Een overzicht van alle cloudpakketten en een kostenvergelijking met de grote cloudaanbieders vindt u op de pagina Cloud server huren.

Veelgemaakte fouten en hoe u ze voorkomt

• etcd over continenten verspreid. Trage schrijfbewerkingen en instabiele verkiezingen zijn het gevolg, en bij k3s met ingebouwde etcd wordt het niet ondersteund. Oplossing: één cluster per regio.
• Twee servers in een regio. etcd heeft een meerderheid nodig, en twee servers kunnen geen uitval opvangen. Oplossing: één of drie.
• API open voor het hele internet. Poort 6443 is de hoofdsleutel van het cluster. Oplossing: alleen vanaf het eigen adres of via een VPN.
• Centrale uitrolserver. Valt die uit, dan kan er niets meer worden uitgerold. Oplossing: Flux in elk cluster, dat zichzelf uit Git bedient.
• Update in alle regio's tegelijk. Een fout treft dan alle gebruikers. Oplossing: regio voor regio via de mappen in de repository.
• Certificaten via de HTTP-challenge. In regio's waar het DNS-record op dat moment niet naar verwijst, mislukt de verlenging. Oplossing: DNS-challenge.
• Database op een lokaal volume zonder replicatie. Valt de node uit, dan zijn de data niet bereikbaar. Oplossing: replicatie via een database-operator.
• Geen probes en geen budget. Ongezonde pods krijgen nog steeds verkeer, en onderhoud haalt alle pods tegelijk van het net. Oplossing: readiness- en liveness-probe plus PodDisruptionBudget.

Kort samengevat

• Voor Kubernetes over meerdere continenten is één cluster per regio de juiste keuze; één enkel cluster over alle continenten loopt stuk op de latentie van etcd.
• De startopstelling bestaat uit drie servers, één in de VS, één in Europa en één in Azië; deze opstelling is al bestand tegen de uitval van een heel continent.
• Bij de uitbreiding krijgt elke regio drie servers op dezelfde locatie; dan overleeft elke regio ook de uitval van afzonderlijke servers.
• Flux in elk cluster rolt de applicatie uit vanuit dezelfde Git-repository, regio voor regio.
• Geo-DNS met health checks en een korte TTL stuurt gebruikers naar de dichtstbijzijnde gezonde regio; certificaten komen via de DNS-challenge.
• Kubernetes verdeelt pods, geen data: databases hebben hun eigen replicatie nodig, back-ups blijven verplicht.
• k3s is voor deze architectuur meestal een betere keuze dan kubeadm, omdat drie eenvoudige clusters makkelijker te beheren zijn dan drie complexe.