Cum să conectați clustere Kubernetes în centre de date diferite

Bine ați venit la seria de ghiduri scurte despre Kubernetes. Aceasta este o coloană regulată cu cele mai interesante întrebări pe care le primim online și la cursurile noastre. Răspunde un expert în Kubernetes.

Expertul de astăzi este Daniele Polencic (Daniele Polencic). Daniele este instructor și dezvoltator de software la Learnk8s.

Dacă doriți să primiți un răspuns la întrebarea dvs. în următoarea postare, contactați-ne prin e-mail sau pe Twitter: @learnk8s.

Ați ratat postările anterioare? Le căutați aici.

Cum să conectați clustere Kubernetes în diferite centre de date?

Pe scurt: Kubefed v2 va fi disponibil în curând, de asemenea, vă recomand să citiți despre Shipper și proiectul multi-cluster-scheduler.

Destul de frecvent, infrastructura este replicată și distribuită în diferite regiuni, în special în medii controlate.

Dacă o regiune devine indisponibilă, traficul este redirecționat către alta pentru a evita întreruperile.

Cu Kubernetes, se poate folosi o strategie similară și distribuirea sarcinilor de lucru în diferite regiuni.

Puteți avea un singur cluster sau mai multe pentru echipă, regiune, mediu sau o combinație a acestor elemente.

Clusterele dvs. pot fi găzduite în diferite cloud-uri și în medii locale.

Dar cum să planificați infrastructura pentru o astfel de dispersie geografică?
Este necesar să creați un singur cluster mare pe mai multe cloud-uri printr-o rețea unitară?
Sau să creați multe clustere mici și să găsiți o modalitate de a le controla și sincroniza?

Un cluster de conducere

Crearea unui singur cluster pe o rețea unitară nu este atât de simplă.

Imaginați-vă că aveți o defecțiune, pierderea conectivității între segmentele cluster-ului.

Dacă aveți un singur server master, jumătate din resurse nu vor putea primi comenzi noi, deoarece nu pot comunica cu masterul.

Și în acest caz, aveți vechile tabele de rutare (kube-proxy nu poate încărca altele noi) și fără pod-uri suplimentare (kubelet nu poate solicita actualizări).

Ce este și mai rău, dacă Kubernetes nu vede un nod, îl marchează ca fiind pierdut și redistribuie pod-urile lipsă pe nodurile existente.

În cele din urmă, veți avea de două ori mai multe pod-uri.

Dacă faceți câte un server master pentru fiecare regiune, vor apărea probleme cu algoritmul de atingere a consensului în baza de date etcd. (editorial note — De fapt, baza de date etcd nu trebuie să fie neapărat pe serverele master. Poate fi lansată pe un grup separat de servere într-o singură regiune. Totuși, acest lucru va crea un punct de eșec al clusterei. În schimb, va fi rapid.)

etcd folosește algoritmul raft, pentru a conveni asupra unei valori înainte de a o scrie pe disc.
Asta înseamnă că majoritatea instanțelor trebuie să ajungă la un consens înainte ca starea să poată fi scrisă în etcd.

Dacă întârzierile între instanțele etcd cresc brusc, cum ar fi în cazul a trei instanțe etcd în regiuni diferite, este nevoie de mult timp pentru a consensualiza valoarea și a o scrie pe disc.
Acest lucru se reflectă și în controlerele Kubernetes.

Managerul de controlere are nevoie de mai mult timp pentru a răspunde la modificări și a scrie răspunsul în baza de date.

Și, având în vedere că nu este un singur controler, ci mai multe, se produce un efect de reacție în lanț, iar întreaga cluster devine foarte lentă.

etcd este atât de sensibil la întârzieri încât în documentația oficială se recomandă utilizarea SSD-urilor în loc de hard disk-uri obișnuite..

În prezent, nu există exemple bune de rețea mare pentru un singur cluster.

În principal, comunitatea de dezvoltatori și grupul SIG-cluster încearcă să înțeleagă cum să orchestreze clusterele așa cum Kubernetes orchestrează containerele.

Varianta 1: federația clusterelor cu kubefed

Răspunsul oficial din partea SIG-cluster este kubefed2, noua versiune a clientului sursă și operatorului kube federation.

Pentru prima dată, gestionarea unei colecții de clustere ca un singur obiect a fost încercată cu ajutorul instrumentului kube federation.

Începutul a fost promițător, dar în cele din urmă kube federation nu a devenit popular, deoarece nu suporta toate resursele.

Susținea livrările și serviciile combinate, dar, de exemplu, nu suporta StatefulSets.
În plus, configurația federației era transmisă sub formă de anotări și nu era flexibilă.

Imaginați-vă cum s-ar putea descrie separarea replicilor pentru fiecare cluster în federație folosind doar anotări.

A rezultat un haos total.

SIG-cluster a depus mult efort după kubefed v1 și a decis să abordeze problema dintr-o altă direcție.

În loc de anotări, au decis să lanseze un controller care se instalează pe clustere. Acesta poate fi configurat folosind definiții de resurse personalizate (Custom Resource Definition, CRD).

Pentru fiecare resursă care va face parte din federație, aveți o definiție CRD personalizată din trei secțiuni:

• definiția standard a resursei, de exemplu, o desfășurare;
• secțiunea placement, unde definiți cum va fi distribuită resursa în federație;
• secțiunea override, unde pentru o resursă specifică se pot suprascrie greutatea și parametrii din placement.

Iată un exemplu de desfășurare combinată cu secțiunile placement și override.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

După cum puteți observa, desfășurarea este distribuită între două clustere: cluster1 și cluster2.

Primul cluster furnizează trei replici, iar pentru al doilea este specificată valoarea 5.

Dacă aveți nevoie de mai mult control asupra numărului de replici, kubefed2 oferă un nou obiect ReplicaSchedulingPreference, unde replicile pot fi distribuite pe baza greutății:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

Structura CRD și API-ul nu sunt încă complet gata, iar în depozitul oficial al proiectului se lucrează activ.

Urmăriți kubefed2, dar amintiți-vă că momentan nu este potrivit pentru medii de producție.

Aflați mai multe despre kubefed2 din articolul oficial despre kubefed2 de pe blogul Kubernetes și din depozitul oficial al proiectului kubefed.

Varianta 2: combinarea clusterei în stilul Booking.com

Dezvoltatorii de la Booking.com nu s-au ocupat de kubefed v2, dar au inventat Shipper - un operator pentru desfășurări pe mai multe clustere, în mai multe regiuni și în mai multe cloud-uri.

Shipper este oarecum similar cu kubefed2.

Ambele instrumente permit configurarea strategiei de desfășurare pe mai multe clustere (care clustere sunt folosite și câte replici au).

Dar scopul Shipper este de a reduce riscul erorilor în desfășurare.

În Shipper, se poate defini un set de pași care descriu împărțirea replicilor între desfășurarea anterioară și cea curentă și volumul de trafic care intră.

Când trimiteți o resursă într-un cluster, controlerul Shipper desfășoară treptat această modificare în toate clusterele unite.

În plus, Shipper este foarte limitat.

De exemplu, acesta acceptă grafice Helm ca date de intrare. și nu suportă resursele vanilla.
În general, Shipper funcționează astfel.

În loc de livrarea standard, trebuie să creați un resource al aplicației care să includă graficul Helm:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper este o opțiune bună pentru gestionarea mai multor clustere, dar conexiunea sa strânsă cu Helm este un dezavantaj.

Dar, dacă am face toți tranziția de la Helm la kustomize sau kapitan?

Aflați mai multe despre Shipper și filosofia sa în acest comunicat oficial de presă.

Dacă doriți să explorați codul, mergeți la depozitul oficial al proiectului.

Opțiunea 3: „magica” unire a clusterelor

Kubefed v2 și Shipper lucrează cu federația clusterelor, oferind clusterelor resurse noi prin definiția personalizată a resurselor.

Dar, dacă nu doriți să rescrieți toate livrările, StatefulSets, DaemonSets etc. pentru unire?

Cum să includeți un cluster existent în federație fără a schimba YAML?

multi-cluster-scheduler este un proiect Admirality, care se ocupă de sarcini de planificare în clustere.

Dar în loc să inventeze o nouă modalitate de interacțiune cu clusterul și să învelească resursele în definiții personalizate, multi-cluster-scheduler se integrează în ciclul de viață standard al Kubernetes și intercepta toate apelurile care creează poduri.

Fiecare pod creat este înlocuit imediat cu un dummy.

multi-cluster-scheduler folosește web-hooks pentru a modifica accesul, pentru a intercepta apelul și a crea un pod dummy inactiv.

Podul original trece printr-un alt ciclu de planificare, unde, după sondarea întregii federații, se ia o decizie privind plasamentul.

În cele din urmă, podul este livrat în clusterul țintă.

Ca urmare, aveți un pod suplimentar, care nu face nimic, ci ocupă loc.

Avantajul este că nu a trebuit să scrieți noi resurse pentru unirea livrărilor.

Fiecare resursă care creează un pod este automat pregătită pentru unire.

Este interesant, deoarece livrările începeau brusc să fie distribuite pe mai multe regiuni, iar tu nici nu ai observat. Totuși, acest lucru este destul de riscant, deoarece totul se bazează pe magie aici.

Dar dacă Shipper face eforturi, în principal, pentru a atenua consecințele livrărilor, multi-cluster-scheduler îndeplinește sarcini mai generale și, probabil, se potrivește mai bine pentru lucrările de lot.

Nu are un mecanism avansat de livrare treptată.

Mai multe despre multi-cluster-scheduler puteți afla pe pagina oficială a depozitului.

Dacă vrei să citești despre multi-cluster-scheduler în acțiune, Admiralty are un caz interesant de utilizare cu Argo — fluxuri de lucru, evenimente, CI și CD Kubernetes.

Alte instrumente și soluții

Conectarea și gestionarea mai multor clustere este o sarcină complexă, nu există o soluție universală.

Dacă vrei să studiezi mai în detaliu acest subiect, iată câteva resurse:

• Submariner de la Rancher — un instrument care conectează rețelele overlay ale diferitelor clustere Kubernetes.
• Rețeaua de retail Target folosește Unimatrix împreună cu Spinnaker pentru a orchestra desfășurarea pe mai multe clustere.
• Încercați să utilizați IPV6 și o rețea unică în mai multe regiuni.
• Puteți folosi service mesh, de exemplu Istio pentru a conecta mai multe clustere.
• Cilium, un plugin pentru interfața de rețea a containerelor, oferă funcția cluster mesh, care permite combinarea mai multor clustere

Asta e tot pentru astăzi

Mulțumim că ai citit până la capăt!

Dacă știi o modalitate mai eficientă de a conecta mai multe clustere, spune-ne.

Vom adăuga metoda ta la resurse.

O mulțumire specială lui Chris Nesbitt-Smith (Chris Nesbitt-Smith) și lui Vincent De Smet (Vincent De Smet) (inginer de fiabilitate la swatmobile.io) pentru că au citit articolul și au împărtășit informații utile despre cum funcționează federația.

Sursa: habr.com