Dobrodošli v naši seriji Kubernetes Quick Start. To je redna rubrika z najbolj zanimivimi vprašanji, ki jih prejemamo na spletu in na naših izobraževanjih. Odgovor strokovnjaka za Kubernetes.
Današnji strokovnjak je Daniel Polenchik (). Daniel dela kot inštruktor in razvijalec programske opreme pri .
Če želite odgovor na svoje vprašanje v naslednji objavi, ali .
Ste zamudili prejšnje objave? .
Kako povezati gruče Kubernetes v različnih podatkovnih centrih?
Na kratko: , in priporočam tudi branje o и .
Pogosto se infrastruktura replicira in porazdeli po različnih regijah, zlasti v nadzorovanih okoljih.
Če ena regija ni na voljo, se promet preusmeri na drugo, da se preprečijo motnje.
S Kubernetesom lahko uporabite podobno strategijo in razdelite delovne obremenitve po različnih regijah.
Imate lahko eno ali več gruč na ekipo, regijo, okolje ali kombinacijo teh elementov.
Vaše gruče lahko gostujejo v različnih oblakih in na mestu uporabe.
Kako pa načrtujete infrastrukturo za takšno geografsko razširjenost?
Ali morate ustvariti eno veliko gručo za več oblačnih okolij v enem omrežju?
Ali pa imeti veliko majhnih gruč in najti način za njihov nadzor in sinhronizacijo?
En vodstveni grozd
Ustvarjanje ene gruče v enem omrežju ni tako enostavno.
Predstavljajte si, da imate nesrečo, povezljivost med segmenti gruče je izgubljena.
Če imate en glavni strežnik, polovica virov ne bo mogla prejemati novih ukazov, ker ne bodo mogli vzpostaviti stika z glavnim strežnikom.
In hkrati imate stare usmerjevalne tabele (kube-proxy ne more prenesti novih) in brez dodatnih sklopov (kubelet ne more zahtevati posodobitev).
Da je zadeva še hujša, če Kubernetes ne vidi vozlišča, ga označi kot osirotelega in razdeli manjkajoče pode obstoječim vozliščem.
Posledično imate dvakrat več strokov.
Če naredite en glavni strežnik za vsako regijo, bodo težave z algoritmom soglasja v bazi podatkov etcd. (pribl. izd. — Pravzaprav ni nujno, da se baza podatkov etcd nahaja na glavnih strežnikih. Lahko se izvaja na ločeni skupini strežnikov v isti regiji. Res je, hkrati pa dobimo točko odpovedi grozda. Ampak hitro.)
etcd uporablja da se pogaja o vrednosti, preden jo zapiše na disk.
To pomeni, da mora večina primerov doseči soglasje, preden se lahko državi piše itd.
Če se zakasnitev med primerki etcd dramatično poveča, kot je to v primeru treh primerkov etcd v različnih regijah, traja dolgo časa, da se dogovorite o vrednosti in jo zapišete na disk.
To se odraža v krmilnikih Kubernetes.
Vodja krmilnika potrebuje več časa, da se seznani s spremembo in zapiše odgovor v bazo podatkov.
In ker ni enega krmilnika, ampak več, pride do verižne reakcije in celoten grozd začne delovati zelo počasi.
etcd je tako občutljiv na zakasnitev, da .
Trenutno ni dobrih primerov velikega omrežja za posamezen grozd.
V bistvu skupnost razvijalcev in skupina SIG-cluster poskušata ugotoviti, kako orkestrirati gruče na enak način, kot Kubernetes orkestrira vsebnike.
Možnost 1: združevanje grozdov s kubefedom
Uradni odgovor SIG-clustra - .
Prvič smo poskusili upravljati zbirko gruč kot en sam objekt z orodjem kube federation.
Začetek je bil dober, a na koncu zveza kube nikoli ni postala priljubljena, ker ni podpirala vseh virov.
Podpiral je zvezne dostave in storitve, ne pa na primer StatefulSets.
Poleg tega je bila zvezna konfiguracija posredovana v obliki opomb in ni bila prilagodljiva.
Predstavljajte si, kako bi lahko opisali particioniranje replike za vsako gručo v zvezi samo z opombami.
Bila je popolna zmešnjava.
SIG-cluster je opravil veliko dela po kubefed v1 in se odločil, da pristopi k problemu z drugega zornega kota.
Namesto opomb so se odločili izdati krmilnik, ki je nameščen na gručah. Lahko ga prilagodite z uporabo Custom Resource Definitions (CRD).
Za vsak vir, ki bo del zveze, imate definicijo CRD po meri s tremi razdelki:
- standardna definicija vira, na primer uvedba;
- oddelek
placement, kjer določite, kako bo vir razdeljen v federaciji; - oddelek
override, kjer lahko za določen vir preglasite težo in parametre iz umestitve.
Tukaj je primer kombinirane dostave z odseki za umestitev in preglasitev.
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: 5Kot lahko vidite, je ponudba porazdeljena v dva grozda: cluster1 и cluster2.
Prva gruča zagotavlja tri replike, druga pa je nastavljena na 5.
Če potrebujete več nadzora nad številom replik, kubefed2 ponuja nov objekt ReplicaSchedulingPreference, kjer je mogoče tehtati replike:
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: 2Struktura CRD in API še nista povsem pripravljena, aktivno delo pa poteka v uradnem repozitoriju projekta.
Bodite pozorni na kubefed2, vendar ne pozabite, da še ni primeren za proizvodnjo.
Izvedite več o kubefed2 na v blogu o Kubernetesu in v .
Možnost 2: združevanje grozdov v stilu Booking.com
Razvijalci Booking.com niso delali na kubefedu v2, ampak so prišli do Shipperja - operaterja za dostavo v več grozdih, v več regijah in v več oblakih.
nekoliko podoben kubefed2.
Obe orodji vam omogočata prilagoditev vaše strategije uvajanja z več gručami (katere gruče se uporabljajo in koliko replik imajo).
Vendar Cilj pošiljatelja je zmanjšati tveganje napak med dostavo.
V Shipperju lahko definirate niz korakov, ki opisujejo razdelitev replik med prejšnjo in trenutno uvedbo ter obseg dohodnega prometa.
Ko potisnete vir v gručo, krmilnik Shipper postopoma uvede to spremembo v vseh združenih gručah.
Tudi Shipper je zelo omejen.
Na primer, kot vhod sprejema krmilne karte in ne podpira virov vanilije.
Na splošno Shipper deluje tako.
Namesto standardne dostave morate ustvariti vir aplikacije, ki vključuje grafikon 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: 3Shipper je dobra možnost za upravljanje več gruč, vendar je njegova tesna povezava s Helmom le v napoto.
Kaj pa, če vsi preidemo s Helma na ali ?
Izvedite več o podjetju Shipper in njegovi filozofiji na .
Če se želite poglobiti v kodo, .
Možnost 3: »čarobno« združevanje grozdov
Kubefed v2 in Shipper delujeta z zvezo gruče in zagotavljata nove vire grozdom prek definicije virov po meri.
Kaj pa, če ne želite prepisati vseh dostav, StatefulSets, DaemonSets itd., da se združijo?
Kako vključiti obstoječo gručo v zvezo brez spreminjanja YAML?
, ki se ukvarja z razporejanjem delovnih obremenitev na gručah.
Toda namesto da bi iznašel nov način interakcije z gručo in zavil vire v definicije po meri, je razporejevalnik z več gručami vdelan v standardni življenjski cikel Kubernetes in prestreže vse klice, ki ustvarjajo pode.
Vsak ustvarjen pod je takoj zamenjan z lutko.
uporablja razporejevalnik več gruč da prestreže klic in ustvari nedejavno lutko.
Prvotni pod gre skozi še en cikel načrtovanja, kjer se po anketi celotne zveze sprejme odločitev o umestitvi.
Končno je pod dostavljen v ciljno gručo.
Posledično imate dodatno enoto, ki ne dela ničesar, samo zavzema prostor.
Prednost je, da vam ni bilo treba pisati novih virov za združevanje zalog.
Vsak vir, ki ustvari pod, je samodejno pripravljen za združitev.
To je zanimivo, ker imate nenadoma zaloge razporejene po več regijah, pa tega sploh niste opazili. Vendar je to precej tvegano, saj tukaj vse temelji na magiji.
Toda medtem ko Shipper poskuša večinoma ublažiti vpliv dostav, multi-cluster-scheduler obravnava bolj splošne naloge in je morda bolj primeren za paketna opravila.
Nima naprednega mehanizma postopne dostave.
Več o multi-cluster-schedulerju lahko najdete na .
Če želite prebrati o delu razporejevalnika več gruč, Admiralty ima — poteki dela, dogodki, CI in CD Kubernetes.
Druga orodja in rešitve
Povezovanje in upravljanje več gruč je kompleksna naloga in univerzalne rešitve ni.
Če želite to temo podrobneje raziskati, je tukaj nekaj virov:
- je orodje, ki povezuje prekrivna omrežja različnih gruč Kubernetes.
- Maloprodajna veriga Target uporablja .
- Poskusite uporabiti IPV6 in .
- Uporabite lahko na primer servisno mrežo .
- Cilium, vsebniški vtičnik omrežnega vmesnika, ponuja , ki omogoča združevanje več grozdov
To je vse za danes
Hvala, ker ste prebrali do konca!
Če veste, kako učinkoviteje povezati več gruč, .
Vašo metodo bomo dodali na povezave.
Posebna zahvala Chrisu Nesbitt-Smithu () in Vincent de Sme () (inženir za zanesljivost v ) za branje članka in deljenje koristnih informacij o delovanju zveze.
Vir: www.habr.com