Kubernetes pe mai multe continente: k3s și k8s cu disponibilitate ridicată în centre de date din întreaga lume

Kubernetes este standardul atunci când aplicațiile trebuie să fie tolerante la defecțiuni și să se scaleze automat. Ideea evidentă de a întinde un singur cluster Kubernetes peste servere din SUA, Europa și Asia se lovește însă de un detaliu: etcd, baza de date în care Kubernetes își păstrează întreaga stare. Acest articol arată cum funcționează totuși Kubernetes pe mai multe continente, și anume astfel încât un continent întreg să poată cădea: cu un cluster per regiune, o livrare comună prin GitOps și un Geo-DNS care trimite utilizatorii către cea mai apropiată regiune funcțională.

Construim arhitectura cu k3s, distribuția Kubernetes ușoară și complet certificată, care se instalează în câteva minute, iar la final arătăm ce se schimbă la un Kubernetes clasic instalat cu kubeadm. Noțiunile de bază despre disponibilitate, quorum și failover între mai multe locații sunt explicate pe larg în articolul Docker Swarm pe trei continente; aici ne ocupăm de ceea ce este diferit la Kubernetes.

Un cluster întins pe toate continentele sau un cluster per regiune?

Pentru Kubernetes pe mai multe continente, arhitectura corectă este un cluster per regiune, nu un singur cluster întins pe toate continentele. Fiecare cluster rulează independent, toate sunt implementate din același repository Git, iar un Geo-DNS cu health checks distribuie utilizatorii. Dacă o regiune cade, celelalte preiau sarcina, fără să fie nevoie ca o stare comună a clusterului să fie coordonată peste ocean.

De ce etcd nu suportă distanțele lungi

Kubernetes stochează fiecare stare, fiecare configurație și fiecare modificare în etcd, un depozit de tip cheie-valoare cu consens Raft. Fiecare operație de scriere are nevoie de confirmarea majorității tuturor membrilor etcd. În mod implicit, etcd lucrează cu un heartbeat de 100 de milisecunde și un timeout de alegere de o secundă; între Europa, America de Nord și Asia, latența pachetelor este între 80 și 250 de milisecunde. Valorile pot fi mărite, dar atunci fiecare scriere din cluster devine lentă, de la planificarea unui pod până la salvarea unui secret. Documentația k3s este clară în această privință: etcd-ul integrat nu este suportat în clustere distribuite pe mai multe rețele, iar toate serverele ar trebui să se afle în aceeași locație. Și Kubernetes însuși este conceput pentru ca un cluster să acopere mai multe zone din cadrul unei regiuni, nu mai multe continente.

Comparație între cele trei modele

Abordarea „un cluster per regiune” are un al doilea avantaj, adesea subestimat: o eroare în planul de control, o modificare greșită a clusterului sau un upgrade care eșuează afectează întotdeauna doar o regiune. Utilizatorii din celelalte regiuni nu observă nimic.

k3s sau k8s?

Ambele sunt Kubernetes în toată regula, cu același API, aceleași manifeste și aceleași instrumente. Diferența constă în structură și în efort:

Pentru arhitectura cu un cluster per regiune recomandăm k3s: operarea a trei clustere este comodă doar dacă fiecare dintre ele este simplu. Cine are deja experiență cu kubeadm preia arhitectura neschimbată, iar secțiunea despre kubeadm de mai jos arată diferențele.

Arhitectura: trei regiuni, trei clustere, un singur punct de intrare

Etapa inițială și extinderea

Etapa inițială constă în trei servere, câte unul în SUA, în Europa și în Asia, fiecare fiind un cluster separat cu un singur nod. Dacă un server cade, cade și regiunea lui, iar Geo-DNS-ul trimite utilizatorii ei în regiunea vecină. Această etapă este deja concepută să facă față căderii unui continent întreg. În etapa de extindere, fiecare regiune primește trei servere în aceeași locație; atunci și fiecare regiune în parte supraviețuiește căderii unui server, fără să fie nevoie ca utilizatorii să fie redirecționați.

Ce locații KernelHost sunt potrivite

KernelHost operează servere în centrul de date maincubes din Frankfurt am Main și oferă servere virtuale în alte locații din Europa, America de Nord și Asia-Pacific, printre care trei locații în SUA, Canada, Londra, Strasbourg, Varșovia, Helsinki, Singapore, Japonia, Sydney și Mumbai. Lista completă se află pe pagina Locațiile serverelor. Exemplul din acest articol folosește Frankfurt am Main pentru Europa, Coasta de Est a SUA pentru America de Nord și Singapore pentru Asia.

Ghid: Kubernetes cu k3s în trei regiuni

Exemplul folosește trei servere cu Debian 12 sau 13: k3s-eu, k3s-us și k3s-asia. Adresele publice provin din rețeaua de documentare 203.0.113.0/24, iar domeniul este example.com. Înlocuiți ambele cu valorile dumneavoastră.

Pasul 1: provizionarea serverelor în trei regiuni

Comandați trei servere în trei regiuni, cu cel puțin 2 vCPU și 4 GB RAM, astfel încât pe lângă k3s să aibă loc și aplicația dumneavoastră. Aplicați securizarea de bază din lista de verificare pentru servere root noi și alegeți nume de host descriptive. etcd beneficiază în mod clar de SSD-uri rapide, iar stocarea NVMe a serverelor KernelHost îndeplinește această cerință.

Pasul 2: instalarea k3s

Pe fiecare dintre cele trei servere instalați k3s cu o singură comandă. Astfel, fiecare server devine un cluster Kubernetes complet, cu un singur nod:

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

După aproximativ un minut, kubectl get nodes raportează nodul ca Ready. Sunt incluse Traefik drept controller Ingress, Flannel pentru rețea și un provisioner pentru volume locale.

Pasul 3: extinderea la trei servere per regiune

Dacă doriți ca o regiune să aibă ea însăși disponibilitate ridicată, amplasați trei servere în aceeași locație. Primul server pornește etcd-ul integrat, iar celelalte două se alătură cu un token comun. etcd cere un număr impar de servere; cu trei servere, regiunea suportă căderea unui server:

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

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

Toate serverele unei regiuni au nevoie de aceleași setări pentru plajele de adrese și pentru funcționalități. Între ele trebuie să fie deschise porturile de la 2379 la 2380/TCP pentru etcd, 6443/TCP pentru API, 10250/TCP pentru Kubelet și 8472/UDP pentru rețeaua Flannel; spre exterior rămân blocate. Tokenul este un secret: cine îl cunoaște poate adăuga propriile servere în cluster.

Pasul 4: configurarea accesului la toate cele trei clustere

k3s salvează datele de acces în /etc/rancher/k3s/k3s.yaml. Copiați fișierul fiecărui cluster pe stația dumneavoastră de lucru, înlocuiți în el 127.0.0.1 cu adresa serverului și denumiți contextele după regiune:

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

API-ul de pe portul 6443 este cea mai puternică cale de acces la cluster. Permiteți acest acces în firewall doar de la propria adresă sau printr-un VPN, niciodată pentru întregul internet. Fișierul k3s.yaml conține un certificat de administrator și trebuie păstrat cu aceeași grijă ca o parolă de root.

Pasul 5: GitOps cu Flux în fiecare cluster

Pentru ca toate cele trei regiuni să ruleze aceeași aplicație în aceeași versiune, starea dorită se află într-un repository Git, iar în fiecare cluster rulează Flux, care aduce singur clusterul în această stare. Așadar, fiecare cluster își preia singur configurația; nu există niciun server central de livrare care să poată cădea. O structură a repository-ului dovedită în practică:

apps/
  web/            manifestele comune ale aplicației
clusters/
  eu/             setări și versiune pentru Europa
  us/             setări și versiune pentru America de Nord
  asia/           setări și versiune pentru Asia

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

Rulați aceeași comandă cu --path=clusters/us și --path=clusters/asia în contextul corespunzător. Deoarece fiecare regiune are propriul director, puteți implementa o versiune nouă mai întâi într-o regiune și abia apoi în celelalte.

Pasul 6: descrierea aplicației pentru toleranță la defecțiuni

În cadrul unei regiuni, trei elemente asigură ca aplicația să supraviețuiască lucrărilor de întreținere și căderilor de servere: mai multe replici distribuite pe noduri diferite, verificări care recunosc pod-urile cu probleme și un buget care împiedică o lucrare de întreținere să elimine toate pod-urile în același timp:

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

Verificarea de readiness scoate un pod din trafic cât timp acesta nu răspunde, iar verificarea de liveness îl repornește dacă se blochează. Într-un cluster cu un singur nod, distribuirea pe mai multe noduri nu are încă efect; ea intră automat în funcțiune de îndată ce regiunea are trei servere.

Pasul 7: Ingress și certificate

Punctul de intrare este asigurat de Traefik, care este deja inclus. Deoarece toate cele trei regiuni servesc același domeniu, obțineți certificatele TLS cu cert-manager prin metoda DNS challenge: aceasta funcționează în fiecare regiune, indiferent încotro indică în acel moment înregistrarea DNS. Metoda HTTP challenge, în schimb, eșuează în fiecare regiune spre care înregistrarea nu indică în acel moment. Cine lucrează fără Ingress Kubernetes găsește noțiunile de bază în articolul Configurarea nginx ca reverse proxy.

Pasul 8: configurarea Geo-DNS cu failover

Un serviciu DNS cu rutare geografică și health checks trimite utilizatorii din Europa la Frankfurt am Main, pe cei din America spre Coasta de Est a SUA și pe cei din Asia în Singapore. În plus, verifică la fiecare 30 până la 60 de secunde dacă punctul de intrare al fiecărei regiuni răspunde. Dacă o regiune cade, serviciul nu mai furnizează adresa ei. Setați TTL-ul înregistrărilor la 60 de secunde; astfel, o comutare este de regulă încheiată după unul sau două minute. Cine dorește să administreze înregistrările din interiorul clusterului poate folosi în acest scop external-dns.

Pasul 9: implementarea regiune cu regiune și testarea căderii

Introduceți o versiune nouă mai întâi în directorul unei singure regiuni, urmăriți regiunea câteva minute și abia apoi preluați versiunea și pentru celelalte. Astfel, o eroare pe care nicio verificare nu o detectează ajunge cel mult într-o singură regiune. Căderea unei regiuni o simulați oprind k3s pe serverul ei, verificând totodată dacă Geo-DNS-ul scoate regiunea din răspunsuri și dacă regiunea vecină preia sarcina:

systemctl stop k3s
systemctl start k3s

Într-o regiune cu trei servere exersați, în plus, întreținerea unui singur server. kubectl drain mută pod-urile respectând bugetul din pasul 6, iar kubectl uncordon repune serverul în funcțiune:

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

Datele între regiuni

Kubernetes distribuie pod-uri, nu date. Un PersistentVolume creat de provisionerul inclus se află pe un singur nod, iar între clustere nu există implicit nicio stocare comună a datelor. Pentru tot ce ține de date se aplică așadar același lucru ca la orice cluster întins pe mai multe locații:

• Bazele de date se replică singure. O soluție dovedită în practică este o instanță primară într-o regiune, cu replici în celelalte; operatorii de baze de date precum CloudNativePG pentru PostgreSQL suportă astfel de replici și peste granițele dintre clustere. Între continente, replicarea este asincronă, iar în caz de incident pot lipsi ultimele secunde de scrieri. Pentru scrieri fără pierderi la nivel mondial există baze de date concepute pentru mai multe regiuni, precum CockroachDB sau YugabyteDB.
• Fișierele și upload-urile își au locul într-o stocare de obiecte compatibilă cu S3, cu replicare într-o a doua regiune.
• Sesiunile se păstrează într-o bază de date replicată sau într-un cache replicat, ori aplicația folosește tokenuri semnate.
• Backup-urile rămân obligatorii, deoarece replicarea distribuie erorile la fel ca datele bune. Pentru obiectele Kubernetes și volume este potrivit Velero; pentru noțiunile de bază, consultați strategia de backup pentru servere.

Kubernetes cu kubeadm în loc de k3s

Cu kubeadm, arhitectura rămâne aceeași: un cluster per regiune, GitOps, Geo-DNS. Diferă construcția fiecărui cluster. Instalați pe toate nodurile un runtime de containere cum ar fi containerd, plus kubeadm, kubelet și kubectl, puneți în fața API-ului regiunii un load balancer sau o adresă virtuală, de exemplu cu kube-vip, și inițializați primul nod control plane:

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

Rezultatul afișat conține două comenzi de alăturare: una cu --control-plane --certificate-key pentru celelalte două noduri control plane și una pentru nodurile worker. Apoi instalați un plugin de rețea precum Calico sau Cilium și un controller Ingress, pe care k3s îl include deja. Efortul suplimentar merită atunci când trebuie să alegeți anumite componente în mod țintit sau să rămâneți aproape de versiunea upstream.

De ce KernelHost pentru Kubernetes pe mai multe continente

Găsiți o prezentare generală a tuturor tarifelor cloud și o comparație a costurilor cu marii furnizori de cloud pe pagina Închiriere server cloud.

Greșeli frecvente și cum le evitați

• etcd întins pe mai multe continente. Consecințele sunt scrieri lente și alegeri instabile, iar la k3s cu etcd integrat această configurație nu este suportată. Soluție: un cluster per regiune.
• Două servere într-o regiune. etcd are nevoie de o majoritate, iar două servere nu suportă nicio cădere. Soluție: unul sau trei.
• API deschis pentru întregul internet. Portul 6443 este cheia universală a clusterului. Soluție: acces doar de la propria adresă sau prin VPN.
• Server central de livrare. Dacă acesta cade, nu se mai poate implementa nimic. Soluție: Flux în fiecare cluster, care se alimentează singur din Git.
• Actualizare în toate regiunile simultan. O eroare îi afectează atunci pe toți utilizatorii. Soluție: regiune cu regiune, prin directoarele din repository.
• Certificate prin HTTP challenge. În regiunile spre care înregistrarea DNS nu indică în acel moment, reînnoirea eșuează. Soluție: DNS challenge.
• Bază de date pe un volum local, fără replicare. Dacă nodul cade, datele nu mai sunt accesibile. Soluție: replicare printr-un operator de baze de date.
• Fără probe și fără buget. Pod-urile cu probleme primesc în continuare trafic, iar lucrările de întreținere scot toate pod-urile din rețea în același timp. Soluție: verificări de readiness și liveness plus PodDisruptionBudget.

Pe scurt

• Pentru Kubernetes pe mai multe continente, soluția corectă este un cluster per regiune; un singur cluster întins pe toate continentele eșuează din cauza latenței etcd.
• Etapa inițială constă în trei servere, câte unul în SUA, în Europa și în Asia; deja această etapă supraviețuiește căderii unui continent întreg.
• În etapa de extindere, fiecare regiune primește trei servere în aceeași locație; atunci fiecare regiune supraviețuiește și căderii unor servere individuale.
• Flux din fiecare cluster implementează aplicația din același repository Git, regiune cu regiune.
• Geo-DNS cu health checks și TTL scurt trimite utilizatorii către cea mai apropiată regiune funcțională, iar certificatele se obțin prin DNS challenge.
• Kubernetes distribuie pod-uri, nu date: bazele de date au nevoie de propria replicare, iar backup-urile rămân obligatorii.
• Pentru această arhitectură, k3s este de obicei o alegere mai bună decât kubeadm, deoarece trei clustere simple sunt mai ușor de operat decât trei clustere complexe.