Kubernetes na více kontinentech: k3s a k8s s vysokou dostupností napříč datovými centry po celém světě

Kubernetes je standardem, když mají aplikace běžet odolně proti výpadkům a automaticky se škálovat. Nabízí se myšlenka roztáhnout jediný cluster Kubernetes přes servery v USA, Evropě a Asii, jenže ta ztroskotá na jednom detailu: na etcd, databázi, do které Kubernetes ukládá celý svůj stav. Tento článek ukazuje, jak Kubernetes na více kontinentech přesto funguje, a to tak, že smí vypadnout i celý kontinent: s jedním clusterem na region, společným nasazováním přes GitOps a Geo-DNS, který posílá uživatele do nejbližšího zdravého regionu.

Architekturu postavíme na k3s, odlehčené a plně certifikované distribuci Kubernetes, kterou nainstalujete během několika minut, a na konci ukážeme, co se změní u klasického Kubernetes nasazeného přes kubeadm. Základy dostupnosti, kvóra a failoveru napříč více lokalitami podrobně popisuje článek Docker Swarm na třech kontinentech; zde jde o to, čím se Kubernetes liší.

Jeden cluster přes všechny kontinenty, nebo jeden cluster na region?

Pro Kubernetes na více kontinentech je správnou architekturou jeden cluster na region, ne jediný cluster přes všechny kontinenty. Každý cluster běží samostatně, všechny se nasazují ze stejného repozitáře Git a Geo-DNS s health checky rozděluje uživatele. Když region vypadne, převezmou jeho úlohu ostatní, aniž by se přes oceán musel odsouhlasovat společný stav clusteru.

Proč etcd nesnese dálkové spoje

Kubernetes ukládá každý stav, každou konfiguraci a každou změnu do etcd, úložiště typu klíč-hodnota s konsenzem Raft. Každý zápis vyžaduje potvrzení od většiny všech členů etcd. etcd ve výchozím nastavení pracuje s heartbeatem 100 milisekund a s timeoutem volby v délce jedné sekundy; mezi Evropou, Severní Amerikou a Asií se přitom doba přenosu paketů pohybuje od 80 do 250 milisekund. Časy lze zvýšit, pak ale bude pomalý každý zápis v clusteru, od naplánování podu až po uložení secretu. Dokumentace k3s je v tomto bodě jednoznačná: vestavěné etcd není v clusterech rozložených přes více sítí podporováno a všechny servery mají stát ve stejné lokalitě. I samotný Kubernetes je navržen tak, aby jeden cluster pokrýval více zón v rámci jednoho regionu, ne více kontinentů.

Srovnání tří vzorů

Přístup „jeden cluster na region“ má ještě druhou, často podceňovanou výhodu: chyba v řídicí rovině, chybná změna v clusteru nebo nepovedený upgrade zasáhne vždy jen jeden region. Uživatelé ostatních regionů si ničeho nevšimnou.

k3s, nebo k8s?

Obojí je skutečný Kubernetes se stejným API, stejnými manifesty a stejnými nástroji. Rozdíl je ve způsobu sestavení a v náročnosti:

Pro architekturu s jedním clusterem na region doporučujeme k3s: provozovat tři clustery je příjemné jen tehdy, když je každý z nich jednoduchý. Kdo už má zkušenosti s kubeadm, převezme architekturu beze změny; rozdíly ukazuje část o kubeadm níže.

Architektura: tři regiony, tři clustery, jeden vstupní bod

Začátek a rozšíření

Výchozí sestavu tvoří tři servery, po jednom v USA, v Evropě a v Asii, každý jako samostatný jednouzlový cluster. Když vypadne server, vypadne jeho region a Geo-DNS pošle jeho uživatele do sousedního regionu. Už tato fáze je navržena na výpadek celého kontinentu. Při rozšíření dostane každý region tři servery ve stejné lokalitě a pak i každý region sám o sobě přežije výpadek jednoho serveru, aniž by bylo nutné uživatele přesměrovat.

Které lokality KernelHost se hodí

KernelHost provozuje servery v datovém centru maincubes ve Frankfurtu nad Mohanem a nabízí virtuální servery v dalších lokalitách v Evropě, Severní Americe a Asii a Pacifiku, mimo jiné na třech místech v USA, v Kanadě, Londýně, Štrasburku, Varšavě, Helsinkách, Singapuru, Japonsku, Sydney a Mumbai. Úplný seznam najdete na stránce Umístění serverů. Příklad v tomto článku používá Frankfurt nad Mohanem pro Evropu, východní pobřeží USA pro Severní Ameriku a Singapur pro Asii.

Návod: Kubernetes s k3s ve třech regionech

Příklad používá tři servery s Debianem 12 nebo 13: k3s-eu, k3s-us a k3s-asia. Veřejné adresy pocházejí z dokumentačního rozsahu 203.0.113.0/24, doména je example.com. Obojí nahraďte svými hodnotami.

Krok 1: připravit servery ve třech regionech

Objednejte tři servery ve třech regionech, každý nejméně se 2 vCPU a 4 GB RAM, aby vedle k3s zbylo místo i pro vaši aplikaci. Proveďte základní hardening podle checklistu pro nové root servery a nastavte výstižné názvy hostitelů. etcd znatelně těží z rychlých SSD, což úložiště NVMe na serverech KernelHost splňuje.

Krok 2: nainstalovat k3s

Na každém ze tří serverů nainstalujete k3s jediným příkazem. Každý server se tím stane plnohodnotným clusterem Kubernetes s jedním uzlem:

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

Přibližně po minutě hlásí kubectl get nodes uzel jako Ready. Součástí jsou Traefik jako ingress controller, Flannel jako síť a provisioner pro lokální svazky.

Krok 3: rozšíření na tři servery v každém regionu

Má-li být vysoce dostupný i samotný region, umístěte do stejné lokality tři servery. První server spustí vestavěné etcd, další dva se k němu připojí pomocí společného tokenu. etcd vyžaduje lichý počet serverů; se třemi servery zvládne region výpadek jednoho serveru:

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

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

Všechny servery jednoho regionu potřebují stejné nastavení síťových rozsahů a funkcí. Mezi nimi musí být otevřené porty 2379 až 2380/TCP pro etcd, 6443/TCP pro API, 10250/TCP pro kubelet a 8472/UDP pro síť Flannel, navenek zůstávají zavřené. Token je tajemství: kdo ho zná, může do clusteru připojit vlastní servery.

Krok 4: nastavit přístup ke všem třem clusterům

k3s ukládá přístupové údaje do /etc/rancher/k3s/k3s.yaml. Zkopírujte tento soubor z každého clusteru na svůj pracovní počítač, nahraďte v něm 127.0.0.1 adresou serveru a kontexty pojmenujte podle regionu:

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

API na portu 6443 je nejmocnější přístup ke clusteru. Ve firewallu ho povolte jen ze své vlastní adresy nebo z VPN, nikdy pro celý internet. Soubor k3s.yaml obsahuje certifikát administrátora a je třeba ho uchovávat stejně pečlivě jako heslo roota.

Krok 5: GitOps přes Flux v každém clusteru

Aby všechny tři regiony provozovaly stejnou aplikaci ve stejné verzi, leží požadovaný stav v repozitáři Git a v každém clusteru běží Flux, který tento stav samostatně zajišťuje. Každý cluster si tedy konfiguraci stahuje sám; centrální server pro nasazování, který by mohl vypadnout, neexistuje. Osvědčená struktura repozitáře:

apps/
  web/            společné manifesty aplikace
clusters/
  eu/             nastavení a verze pro Evropu
  us/             nastavení a verze pro Severní Ameriku
  asia/           nastavení a verze pro Asii

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

Stejný příkaz spusťte v příslušném kontextu s --path=clusters/us a --path=clusters/asia. Protože má každý region vlastní adresář, můžete novou verzi nasadit nejprve v jednom regionu a teprve potom v ostatních.

Krok 6: popsat aplikaci tak, aby odolala výpadkům

V rámci regionu zajišťují tři věci, aby aplikace přežila údržbu i výpadky serverů: více replik rozmístěných na různé uzly, kontroly, které rozpoznají nezdravé pody, a budget, který zabrání tomu, aby údržba odstranila všechny pody najednou:

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

Readiness probe vyřadí pod z provozu, dokud neodpovídá, liveness probe ho restartuje, když se zasekne. V jednouzlovém clusteru se rozmístění na více uzlů ještě neprojeví; uplatní se automaticky, jakmile bude mít region tři servery.

Krok 7: Ingress a certifikáty

Vstup obstarává přibalený Traefik. Protože všechny tři regiony obsluhují stejnou doménu, získávejte TLS certifikáty nástrojem cert-manager přes DNS challenge: funguje v každém regionu bez ohledu na to, kam DNS záznam právě ukazuje. HTTP challenge naopak selže v každém regionu, na který záznam právě neukazuje. Kdo pracuje bez Kubernetes Ingressu, najde základy v článku Nastavení nginx jako reverzní proxy.

Krok 8: nastavit Geo-DNS s failoverem

Služba DNS s geografickým směrováním a health checky posílá uživatele z Evropy do Frankfurtu nad Mohanem, z Ameriky na východní pobřeží USA a z Asie do Singapuru a každých 30 až 60 sekund kontroluje, zda vstup každého regionu odpovídá. Když region vypadne, přestane vracet jeho adresu. Nastavte TTL záznamů na 60 sekund, pak je přepnutí většinou hotové za jednu až dvě minuty. Kdo chce záznamy spravovat přímo z clusteru, může k tomu použít external-dns.

Krok 9: nasazovat region po regionu a otestovat výpadek

Novou verzi nejprve zapište do adresáře jednoho regionu, region několik minut sledujte a potom verzi převezměte i pro ostatní. Chyba, kterou žádná kontrola neodhalí, tak zasáhne nanejvýš jeden region. Výpadek regionu vyzkoušíte tak, že na jeho serveru zastavíte k3s, a přitom ověříte, zda Geo-DNS region vyřadí ze svých odpovědí a zda sousední region unese zátěž:

systemctl stop k3s
systemctl start k3s

V regionu se třemi servery si navíc vyzkoušejte údržbu jednotlivého serveru. kubectl drain přesune pody s ohledem na budget z kroku 6, kubectl uncordon vrátí server zpět do provozu:

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

Data napříč regiony

Kubernetes rozmisťuje pody, ne data. PersistentVolume z přibaleného provisioneru leží na právě jednom uzlu a mezi clustery ve výchozím stavu neexistuje vůbec žádné společné ukládání dat. Pro vše, co pracuje s daty, proto platí totéž jako u každého clusteru napříč více lokalitami:

• Databáze se replikují samy. Osvědčila se primární instance v jednom regionu s replikami v ostatních; databázové operátory jako CloudNativePG pro PostgreSQL podporují takové repliky i přes hranice clusterů. Mezi kontinenty běží replikace asynchronně a v krizové situaci mohou chybět zápisy z posledních sekund. Pro bezztrátový zápis po celém světě existují databáze pro více regionů jako CockroachDB nebo YugabyteDB.
• Soubory a nahraná data patří do objektového úložiště kompatibilního se S3 s replikací do druhého regionu.
• Relace se ukládají do replikované databáze nebo replikované cache, případně aplikace používá podepsané tokeny.
• Zálohy zůstávají povinností, protože replikace šíří chyby stejně jako dobrá data. Pro objekty Kubernetes a svazky se hodí Velero, pro základy viz Zálohovací strategie pro servery.

Kubernetes s kubeadm místo k3s

Architektura zůstává s kubeadm stejná: jeden cluster na region, GitOps, Geo-DNS. Liší se sestavení každého clusteru. Na všechny uzly nainstalujete container runtime, například containerd, a k tomu kubeadm, kubelet a kubectl, před API regionu postavíte load balancer nebo virtuální adresu, třeba přes kube-vip, a inicializujete první uzel control plane:

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

Výstup obsahuje dva příkazy pro připojení: jeden s --control-plane --certificate-key pro další dva uzly control plane a jeden pro worker uzly. Poté nainstalujete síťový plugin jako Calico nebo Cilium a ingress controller, který k3s obsahuje už v základu. Práce navíc se vyplatí, pokud potřebujete cíleně vybírat jednotlivé komponenty nebo se úzce držet upstream verze.

Proč KernelHost pro Kubernetes na více kontinentech

Přehled všech cloudových tarifů a srovnání nákladů s velkými poskytovateli cloudu najdete na stránce Pronájem cloudového serveru.

Časté chyby a jak se jim vyhnout

• etcd roztažené přes kontinenty. Následkem jsou pomalé zápisy a nestabilní volby, u k3s s vestavěným etcd to není podporováno. Řešení: jeden cluster na region.
• Dva servery v jednom regionu. etcd potřebuje většinu, dva servery nezvládnou žádný výpadek. Řešení: jeden, nebo tři.
• API otevřené celému internetu. Port 6443 je generální klíč ke clusteru. Řešení: jen z vlastní adresy nebo přes VPN.
• Centrální server pro nasazování. Když vypadne, nedá se už nic nasadit. Řešení: Flux v každém clusteru, který si konfiguraci stahuje z Gitu sám.
• Aktualizace ve všech regionech současně. Chyba pak zasáhne všechny uživatele. Řešení: region po regionu přes adresáře v repozitáři.
• Certifikáty přes HTTP challenge. V regionech, na které DNS záznam právě neukazuje, obnova selže. Řešení: DNS challenge.
• Databáze v lokálním svazku bez replikace. Když vypadne uzel, data nejsou dostupná. Řešení: replikace pomocí databázového operátoru.
• Žádné probes a žádný budget. Nezdravé pody dál dostávají provoz a údržba odpojí všechny pody najednou. Řešení: readiness a liveness probe plus PodDisruptionBudget.

Stručné shrnutí

• Pro Kubernetes na více kontinentech je správnou volbou jeden cluster na region, jediný cluster přes všechny kontinenty ztroskotá na latenci etcd.
• Výchozí sestavu tvoří tři servery, po jednom v USA, v Evropě a v Asii; už tato fáze přežije výpadek celého kontinentu.
• Při rozšíření dostane každý region tři servery ve stejné lokalitě a pak každý region přežije i výpadky jednotlivých serverů.
• Flux v každém clusteru nasazuje aplikaci ze stejného repozitáře Git, region po regionu.
• Geo-DNS s health checky a krátkým TTL posílá uživatele do nejbližšího zdravého regionu, certifikáty se získávají přes DNS challenge.
• Kubernetes rozmisťuje pody, ne data: databáze potřebují vlastní replikaci a zálohy zůstávají povinností.
• k3s je pro tuto architekturu většinou lepší volbou než kubeadm, protože tři jednoduché clustery se provozují snáz než tři složité.