Kubernetes több kontinensen: k3s és k8s magas rendelkezésre állással, világszerte több adatközpontban

A Kubernetes számít szabványnak, ha az alkalmazásoknak hibatűrően és automatikusan skálázódva kell futniuk. Az a kézenfekvő ötlet, hogy egyetlen Kubernetes-klaszter fogja át az USA-ban, Európában és Ázsiában álló szervereket, azonban egy részleten elbukik: az etcd-n, azon az adatbázison, amelyben a Kubernetes a teljes állapotát tárolja. Ez a cikk bemutatja, hogyan működik mégis a Kubernetes több kontinensen, mégpedig úgy, hogy akár egy teljes kontinens is kieshet: régiónként egy klaszterrel, közös, GitOps-alapú kitelepítéssel és egy Geo-DNS-sel, amely a felhasználókat a legközelebbi egészséges régióba irányítja.

Az architektúrát a k3s-re építjük, amely egy könnyűsúlyú, teljes körűen tanúsított Kubernetes-disztribúció, és percek alatt telepíthető; a végén pedig megmutatjuk, mi változik egy klasszikus, kubeadm-alapú Kubernetesnél. A rendelkezésre állás, a kvórum és a több helyszínre kiterjedő failover alapjait részletesen a Docker Swarm három kontinensen című cikk tárgyalja; itt arról lesz szó, ami a Kubernetesnél más.

Egy klaszter az összes kontinensen át vagy régiónként egy klaszter?

Több kontinensre kiterjedő Kuberneteshez az a helyes architektúra, ha minden régió saját klasztert kap, nem pedig egyetlen klaszter fogja át az összes kontinenst. Minden klaszter önállóan fut, mindegyiket ugyanabból a Git-repositoryból telepítjük ki, a felhasználókat pedig egy állapotellenőrzést végző Geo-DNS osztja el. Ha egy régió kiesik, a többi átveszi a szerepét, anélkül, hogy közös klaszterállapotot kellene az óceánon át egyeztetni.

Miért nem bírja az etcd a nagy távolságokat

A Kubernetes minden állapotot, minden konfigurációt és minden változást az etcd-ben tárol, amely egy Raft-konszenzussal működő kulcs-érték tároló. Minden írási művelethez az összes etcd-tag többségének megerősítése szükséges. Az etcd alapértelmezés szerint 100 ezredmásodperces szívverési időközzel és egy másodperces választási időkorláttal dolgozik; Európa, Észak-Amerika és Ázsia között a csomagok késleltetése 80 és 250 ezredmásodperc között van. Ezeket az időket meg lehet emelni, de akkor a klaszterben minden írási művelet lelassul, egy pod ütemezésétől egy Secret mentéséig. A k3s dokumentációja ezen a ponton egyértelmű: a beépített etcd nem támogatott olyan klaszterekben, amelyek több hálózatra vannak elosztva; minden szerver ugyanazon a helyszínen álljon. Maga a Kubernetes is arra van tervezve, hogy egy klaszter egy régión belül több zónát fedjen le, nem pedig több kontinenst.

A három minta összehasonlítása

A „régiónként egy klaszter” megközelítésnek van egy második, gyakran alábecsült előnye is: egy hiba a vezérlősíkban, egy hibás módosítás a klaszteren vagy egy balul elsült verziófrissítés mindig csak egy régiót érint. A többi régió felhasználói ebből semmit sem vesznek észre.

k3s vagy k8s?

Mindkettő valódi Kubernetes ugyanazzal az API-val, ugyanazokkal a manifestekkel és ugyanazokkal az eszközökkel. A különbség a felépítésben és a ráfordításban rejlik:

Ahhoz az architektúrához, amelyben minden régió saját klasztert kap, a k3s-t ajánljuk: három klasztert csak akkor kényelmes üzemeltetni, ha mindegyik egyszerű. Akinek már van kubeadm-tapasztalata, változatlanul átveheti az architektúrát, a lenti kubeadm-szakasz megmutatja a különbségeket.

Az architektúra: három régió, három klaszter, egy belépési pont

Kezdő fokozat és bővítés

A kezdő fokozat három szerverből áll, egy-egy az USA-ban, Európában és Ázsiában, mindegyik saját, egycsomópontos klaszterként. Ha egy szerver kiesik, kiesik a régiója is, és a Geo-DNS a régió felhasználóit a szomszédos régióba irányítja. Ez a fokozat már egy teljes kontinens kiesésére van tervezve. A bővítés során minden régió három szervert kap ugyanazon a helyszínen, így minden régió önmagában is túléli egy szerver kiesését, anélkül, hogy a felhasználókat át kellene irányítani.

Mely KernelHost-helyszínek alkalmasak

A KernelHost a Frankfurt am Main-i maincubes adatközpontban üzemeltet szervereket, és további helyszíneken is kínál virtuális szervereket Európában, Észak-Amerikában és Ázsia-Csendes-óceán térségében, köztük három helyszínen az USA-ban, továbbá Kanadában, Londonban, Strasbourgban, Varsóban, Helsinkiben, Szingapúrban, Japánban, Sydney-ben és Mumbaiban. A teljes lista a Szerverhelyszínek oldalon található. A cikk példája Európához Frankfurt am Maint, Észak-Amerikához az USA keleti partját, Ázsiához pedig Szingapúrt használja.

Útmutató: Kubernetes k3s-sel három régióban

A példa három szervert használ Debian 12 vagy 13 rendszerrel: k3s-eu, k3s-us és k3s-asia. A nyilvános címek a 203.0.113.0/24 dokumentációs hálózatból származnak, a domain az example.com. Mindkettőt cserélje le a saját értékeire.

1. lépés: szerverek üzembe helyezése három régióban

Rendeljen három szervert három régióban, legalább 2 vCPU-val és 4 GB RAM-mal, hogy a k3s mellett az alkalmazásának is jusson hely. Végezze el az alapvető megerősítést az új root szerverek ellenőrzőlistája alapján, és adjon beszédes hostneveket. Az etcd számára érezhető előnyt jelentenek a gyors SSD-k, ezt a KernelHost-szerverek NVMe-tárolói teljesítik.

2. lépés: a k3s telepítése

Mindhárom szerverre egyetlen paranccsal telepíti a k3s-t. Ezzel minden szerver egy teljes értékű, egycsomópontos Kubernetes-klaszterré válik:

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

Körülbelül egy perc múlva a kubectl get nodes parancs a csomópontot Ready állapotban mutatja. Beépítve érkezik a Traefik Ingress-controllerként, a Flannel hálózatként és egy provisioner a helyi kötetekhez.

3. lépés: bővítés régiónként három szerverre

Ha egy régiónak önmagában is magas rendelkezésre állásúnak kell lennie, helyezzen el három szervert ugyanazon a helyszínen. Az első szerver elindítja a beépített etcd-t, a másik kettő egy közös tokennel csatlakozik. Az etcd páratlan számú szervert igényel, három szerverrel a régió elviseli egy szerver kiesését:

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

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

Egy régió minden szerverén azonosnak kell lennie a hálózati tartományok és a funkciók beállításainak. A szerverek között nyitva kell lennie az etcd számára a 2379-től 2380-ig terjedő TCP-portoknak, az API számára a 6443/TCP, a kubelet számára a 10250/TCP, a Flannel-hálózat számára pedig a 8472/UDP portnak, kifelé viszont ezek zárva maradnak. A token titok: aki ismeri, saját szervereket juttathat be a klaszterbe.

4. lépés: hozzáférés beállítása mindhárom klaszterhez

A k3s a hozzáférési adatokat az /etc/rancher/k3s/k3s.yaml fájlba menti. Másolja át minden klaszter fájlját a munkaállomására, cserélje benne a 127.0.0.1 címet a szerver címére, és nevezze el a kontextusokat a régió szerint:

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

A 6443-as porton futó API a klaszter legerősebb hozzáférési pontja. A tűzfalban csak a saját címéről vagy egy VPN-ről engedélyezze, soha ne az egész internet számára. A k3s.yaml fájl rendszergazdai tanúsítványt tartalmaz, és ugyanolyan gondosan kell őrizni, mint egy root jelszót.

5. lépés: GitOps Fluxszal minden klaszterben

Ahhoz, hogy mindhárom régió ugyanazt az alkalmazást ugyanabban a verzióban futtassa, a kívánt állapot egy Git-repositoryban található, és minden klaszterben fut a Flux, amely ezt az állapotot önállóan előállítja. Minden klaszter tehát maga kéri le a konfigurációját; központi telepítőszerver, amely kieshetne, nincs. A repository egy bevált felépítése:

apps/
  web/            az alkalmazás közös manifestjei
clusters/
  eu/             beállítások és verzió Európához
  us/             beállítások és verzió Észak-Amerikához
  asia/           beállítások és verzió Ázsiához

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

Ugyanezt a parancsot a --path=clusters/us és a --path=clusters/asia kapcsolóval futtatja az adott kontextusban. Mivel minden régiónak saját könyvtára van, egy új verziót először egy régióban telepíthet ki, és csak utána a többiben.

6. lépés: az alkalmazás hibatűrő leírása

Egy régión belül három dolog gondoskodik arról, hogy az alkalmazás túlélje a karbantartásokat és a szerverkieséseket: több replika, amelyek különböző csomópontokra oszlanak el, ellenőrzések, amelyek felismerik a hibás podokat, és egy kiesési keret, amely megakadályozza, hogy egy karbantartás egyszerre távolítsa el az összes podot:

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

A readiness-ellenőrzés kivesz egy podot a forgalomból, amíg az nem válaszol, a liveness-ellenőrzés pedig újraindítja, ha lefagy. Egycsomópontos klaszternél a több csomópontra való elosztás még nem érvényesül, automatikusan életbe lép, amint a régiónak három szervere van.

7. lépés: Ingress és tanúsítványok

A bejövő forgalmat a beépített Traefik fogadja. Mivel mindhárom régió ugyanazt a domaint szolgálja ki, a TLS-tanúsítványokat a cert-managerrel, DNS-challenge útján szerezze be: ez minden régióban működik, függetlenül attól, hogy a DNS-bejegyzés éppen hová mutat. A HTTP-challenge ezzel szemben minden olyan régióban kudarcot vall, amelyre a bejegyzés éppen nem mutat. Aki Kubernetes-Ingress nélkül dolgozik, az alapokat az nginx beállítása reverse proxyként című cikkben találja.

8. lépés: Geo-DNS beállítása failoverrel

Egy földrajzi útválasztással és állapotellenőrzéssel dolgozó DNS-szolgáltatás az európai felhasználókat Frankfurt am Mainba, az amerikaiakat az USA keleti partjára, az ázsiaiakat pedig Szingapúrba irányítja, közben pedig 30 és 60 másodperc közötti időközönként ellenőrzi, hogy minden régió bejárata válaszol-e. Ha egy régió kiesik, a szolgáltatás többé nem adja ki a címét. Állítsa a bejegyzések TTL-jét 60 másodpercre, így az átállás többnyire egy-két perc alatt lezajlik. Aki a bejegyzéseket a klaszteren belülről szeretné kezelni, erre az external-dns-t használhatja.

9. lépés: kitelepítés régióról régióra és a kiesés tesztelése

Egy új verziót először egy régió könyvtárában ad meg, néhány percig figyeli a régiót, majd a verziót a többi régióra is átvezeti. Így egy olyan hiba, amelyet egyetlen ellenőrzés sem ismer fel, legfeljebb egy régiót ér el. Egy régió kiesését úgy próbálja ki, hogy leállítja a k3s-t a régió szerverén, és közben ellenőrzi, hogy a Geo-DNS kiveszi-e a régiót a válaszokból, és hogy a szomszédos régió elviseli-e a terhelést:

systemctl stop k3s
systemctl start k3s

Háromszerveres régióban ezenkívül egyetlen szerver karbantartását is próbálja ki. A kubectl drain a 6. lépésben megadott kiesési keretet betartva áthelyezi a podokat, a kubectl uncordon pedig újra üzembe állítja a szervert:

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

Adatok régiókon át

A Kubernetes podokat oszt el, nem adatokat. A beépített provisioner által létrehozott PersistentVolume pontosan egy csomóponton található, a klaszterek között pedig alapból egyáltalán nincs közös adattárolás. Ezért mindenre, ami adatokkal dolgozik, ugyanaz érvényes, mint bármely több helyszínre kiterjedő klaszternél:

• Az adatbázisok maguk gondoskodnak a replikációjukról. Bevált megoldás egy elsődleges példány az egyik régióban, replikákkal a többiben; az olyan adatbázis-operátorok, mint a PostgreSQL-hez készült CloudNativePG, az ilyen replikákat klaszterhatárokon át is támogatják. Kontinensek között a replikáció aszinkron módon fut, vészhelyzetben az utolsó másodpercek írási műveletei hiányozhatnak. A világszerte veszteségmentes íráshoz több régióra tervezett adatbázisok léteznek, például a CockroachDB vagy a YugabyteDB.
• A fájlok és feltöltések egy S3-kompatibilis objektumtárolóba valók, egy második régióba irányuló replikációval.
• A munkamenetek replikált adatbázisban vagy replikált gyorsítótárban vannak, vagy az alkalmazás aláírt tokeneket használ.
• A mentések továbbra is kötelezők, mert a replikáció a hibákat ugyanúgy szétteríti, mint a jó adatokat. Kubernetes-objektumokhoz és kötetekhez a Velero alkalmas, az alapokat a szerverek mentési stratégiája című cikk ismerteti.

kubeadm-alapú Kubernetes a k3s helyett

Az architektúra kubeadm esetén is ugyanaz marad: régiónként egy klaszter, GitOps, Geo-DNS. Az egyes klaszterek felépítése viszont más. Minden csomópontra telepít egy konténer-futtatókörnyezetet, például a containerd-t, valamint a kubeadm, a kubelet és a kubectl eszközt, a régió API-ja elé terheléselosztót vagy virtuális címet helyez, például a kube-vip segítségével, majd inicializálja az első vezérlősík-csomópontot:

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

A kimenet két csatlakozási parancsot tartalmaz: egyet a --control-plane --certificate-key kapcsolókkal a további két vezérlősík-csomóponthoz, és egyet a workerekhez. Ezután telepít egy hálózati plugint, például a Calicót vagy a Ciliumot, valamint egy Ingress-controllert, amelyet a k3s már beépítve tartalmaz. A többletmunka akkor éri meg, ha egyes komponenseket célzottan kell kiválasztania, vagy szorosan az upstream verziónál kell maradnia.

Miért a KernelHost a több kontinensre kiterjedő Kuberneteshez

Az összes felhőcsomag áttekintését és a nagy felhőszolgáltatókkal való költség-összehasonlítást a Felhő szerver bérlés oldalon találja.

Gyakori hibák és hogyan kerülheti el őket

• Kontinensekre kifeszített etcd. Lassú írási műveletek és instabil választások a következmények, k3s-nél beépített etcd-vel ez nem is támogatott. Megoldás: régiónként egy klaszter.
• Két szerver egy régióban. Az etcd-nek többség kell, két szerver egyetlen kiesést sem visel el. Megoldás: egy vagy három.
• Az egész internet felé nyitott API. A 6443-as port a klaszter mesterkulcsa. Megoldás: csak a saját címről vagy VPN-en keresztül.
• Központi telepítőszerver. Ha kiesik, semmit sem lehet többé kitelepíteni. Megoldás: Flux minden klaszterben, amely önállóan a Gitből szolgálja ki magát.
• Frissítés az összes régióban egyszerre. Egy hiba ilyenkor minden felhasználót érint. Megoldás: régióról régióra, a repository könyvtárain keresztül.
• Tanúsítványok HTTP-challenge útján. Azokban a régiókban, amelyekre a DNS-bejegyzés éppen nem mutat, a megújítás meghiúsul. Megoldás: DNS-challenge.
• Adatbázis helyi köteten, replikáció nélkül. Ha a csomópont kiesik, az adatok elérhetetlenek. Megoldás: replikáció egy adatbázis-operátorral.
• Nincsenek próbák és nincs kiesési keret. A hibás podok továbbra is kapnak forgalmat, a karbantartások egyszerre veszik le az összes podot a hálózatról. Megoldás: readiness- és liveness-ellenőrzés, valamint PodDisruptionBudget.

Röviden összefoglalva

• Több kontinensre kiterjedő Kuberneteshez a régiónként egy klaszter a helyes megoldás, egyetlen, az összes kontinenst átfogó klaszter az etcd késleltetésén bukik el.
• A kezdő fokozat három szerver, egy-egy az USA-ban, Európában és Ázsiában; már ez a fokozat is túléli egy teljes kontinens kiesését.
• A bővítés során minden régió három szervert kap ugyanazon a helyszínen, így minden régió az egyes szerverek kiesését is túléli.
• A Flux minden klaszterben ugyanabból a Git-repositoryból telepíti ki az alkalmazást, régióról régióra.
• Az állapotellenőrzéssel és rövid TTL-lel dolgozó Geo-DNS a legközelebbi egészséges régióba irányítja a felhasználókat, a tanúsítványok DNS-challenge útján érkeznek.
• A Kubernetes podokat oszt el, nem adatokat: az adatbázisoknak saját replikáció kell, a mentések továbbra is kötelezők.
• Ehhez az architektúrához a k3s többnyire jobb választás, mint a kubeadm, mert három egyszerű klasztert könnyebb üzemeltetni, mint három összetettet.