Dobrodošli v serijo kratkih vodnikov o Kubernetesu. To je redna kolumna z najzanimivejšimi vprašanji, ki jih prejemamo na spletu in na naših treningih. Odgovarja strokovnjak za Kubernetes.
Danes je strokovnjak — Daniele Polencic (). Daniele dela kot inštruktor in razvijalec programske opreme pri .
Če želite prejeti odgovor na svoje vprašanje v naslednji objavi, ali v .
Ste zamudili prejšnje objave? .
Kako povezati Kubernetes klastre v različnih podatkovnih centrih?
Na kratko: , poleg tega priporočam, da preberete o in .
Zelo pogosto se infrastruktura replicira in razporeja v različne regije, še posebej v nadzorovanih okoljih.
Če ena regija ni dosegljiva, se promet preusmeri v drugo, da se izogne motnjam.
S Kubernetesom lahko uporabite podobno strategijo in razdelite delovne obremenitve po različnih regijah.
Imate lahko enega ali več klastri na ekipo, regijo, okolje ali kombinacijo teh elementov.
Vaši klasterji so lahko nameščeni v različnih oblakih in v lokalnem okolju.
Toda kako načrtovati infrastrukturo za to geografsko razpršenost?
Ali naj ustvarite en velik klaster v več oblačnih okoljih po enotni mreži?
Ali naj imate več majhnih klastrov in najti način za njihovo nadzorovanje in sinhronizacijo?
En vodilni klaster
Ustvariti en klaster po enotni mreži ni tako preprosto.
Predstavljajte si, da imate nesrečo, izgubljena je povezanost med segmenti klasterja.
Če imate enega glavnega strežnika, polovica virov ne bo mogla sprejemati novih ukazov, ker se ne bo mogla povezati z glavnim strežnikom.
In ob tem imate stare usmerjevalne tabele (kube-proxy ne more naložiti novih) in nobenih dodatnih podov (kubelet ne more zahtevati posodobitev).
Kar je še huje, če Kubernetes ne vidi vozlišča, ga označi kot izgubljenega in razdeli manjkajoče pode med obstoječimi vozlišči.
Konec koncev bo imel dvakrat več podov.
Če boste imeli po en glavnega strežnika za vsako regijo, bodo težave z algoritmom za dosego konsenza v podatkovni bazi etcd.op. cit. — Pravzaprav podatkovna baza etcd ne rabi biti nujno na master strežnikih. Lahko jo zaženemo na ločeni skupini strežnikov v enem regiji. Vendar to pomeni, da dobimo točko odpovedi klasterja. Kljub temu pa je hitra.)
etcd uporablja , da uskladi vrednost, preden jo zapiše na disk.
To pomeni, da morajo večina primerkov doseči konsenz, preden se stanje lahko zapiše v etcd.
Če se zamuda med primerki etcd drastično poveča, kot v primeru treh primerkov etcd v različnih regijah, traja dolgo, da se uskladi vrednost in zapiše na disk.
To vpliva tudi na Kubernetes kontrolerje.
Kontrolerjem potrebujejo več časa, da izvejo o spremembi in zapišejo odgovor v podatkovno bazo.
In ker ni en sam kontroler, temveč več njih, nastane verižna reakcija, in celoten klaster začne delovati zelo počasi..
etcd je tako občutljiv na zamude, da .
Trenutno ne obstajajo dobri primeri velike mreže za en klaster.
Na splošno skupnost razvijalcev in skupina SIG-cluster poskušata razumeti, kako orkestrirati klastre tako, kot Kubernetes orkestrira kontejnerje.
Možnost 1: federacija klastrov s kubefed
Uradni odgovor od SIG-cluster je, .
Prvič so poskušali upravljati zbirko klastrov kot enotno entiteto z orodjem kube federation.
Začetek je bil obetaven, a na koncu kube federation ni postal priljubljen, ker ni podpiral vseh virov.
Podpirala je združene dobave in storitve, denimo pa ne StatefulSets.
Poleg tega je bila konfiguracija federacije posredovana v obliki anotacij in ni bila fleksibilna.
Predstavljajte si, kako bi lahko opisali delitev replik za vsak klaster v federaciji s pomočjo samo ene anotacije.
Nastala je prava zmeda.
SIG-cluster je opravila veliko dela po kubefed v1 in se odločila, da se problem loti z druge perspektive.
Namesto anotacij so se odločili izdati kontroler, ki se namesti na klastre. Nastavljati ga je mogoče s pomočjo uporabniških definicij virov (Custom Resource Definition, CRD).
Za svaki resurs koji će biti deo federacije, imate prilagođenu definiciju CRD koja se sastoji od tri dela:
- standardna definicija resursa, kao što je deployment;
- oddelek
placement, gde definišete kako će resurs biti raspoređen u federaciji; - oddelek
override, gde možete redefinisati težinu i parametre iz placement za konkretan resurs.
Evo primera objedinjene isporuke sa delovima 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: 5Kao što vidite, isporuka je raspoređena po dva klastera: cluster1 in cluster2.
Prvi klaster isporučuje tri replike, dok je za drugi klaster postavljena vrednost 5.
Ako vam je potrebna veća kontrola nad brojem replika, kubefed2 pruža novi objekat ReplicaSchedulingPreference, gde se replike mogu rasporediti prema težini:
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 i API još uvek nisu sasvim spremni, i na zvaničnom repozitorijumu projekta se aktivno radi.
Pratite kubefed2, ali imajte na umu da za operativno okruženje trenutno nije pogodan.
Saznajte više o kubefed2 iz na blogu o Kubernetes i u .
Opcija 2: objedinjavanje klastera u stilu Booking.com
Razvijači Booking.com-a nisu se bavili kubefed v2, ali su izmislili Shipper — operator za isporuku na više klastera, u više regiona i u više oblaka.
nešto slično kubefed2.
Oba alata omogućavaju podešavanje strategije implementacije na više klastera (koji klasteri se koriste i koliko imaju replika).
Ali zadovoljstvo Shipper-a je da smanji rizik od grešaka tokom isporuke.
U Shipperu možete definisati niz koraka koji opisuju razdvajanje replika između prethodnog i trenutnog deploy-a i obim ulaznog saobraćaja.
Kada šaljete resurs u klaster, Shipperov kontroler korak po korak implementira ovu promenu na sve objedinjene klastere.
A Shipper je veoma ograničen.
Na primer, on prihvata Helm grafikon kao ulazne podatke. in ne podpira vanilla resurse.
Na splošno Shipper deluje takole.
Namesto standardne dobave je treba ustvariti vir aplikacije, ki vključuje Helm-chart:
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 izbira za upravljanje več klasterjev, vendar njegova tesna povezanost s Helm le ovira.
Kaj pa, če se vsi preusmerimo s Helma na ili ?
Izvedite več o Shipper in njegovi filozofiji v .
Če želite raziskati kodo, .
Možnost 3: "magično" združevanje klasterjev
Kubefed v2 in Shipper delujeta z federacijo klasterjev in omogočata klasterjem nove vire prek uporabniško določenih virov.
Ampak morda nočete prepisovati vseh dobav, StatefulSets, DaemonSets itd. za združevanje?
Kako vključiti obstoječi klaster v federacijo, ne da bi spreminjali YAML?
ki se ukvarja z obremenitvami na klasterjih.
Ampak namesto, da bi izumili nov način interakcije s klastrom in zavili vire v uporabniške definicije, se multi-cluster-scheduler integrira v standardni življenjski cikel Kubernetes in prestreza vse klice, ki ustvarjajo pod-e.
Vsak ustvarjen pod se takoj zamenja z 'dummy' podom.
multi-cluster-scheduler uporablja , da prestreže klic in ustvari neaktiven pod-dummy.
Izvorni pod preide skozi še en cikel načrtovanja, kjer se po anketi celotne federacije sprejme odločitev o lociranju.
Na koncu se pod dostavi v ciljni klaster.
Na koncu imate dodaten pod, ki nič ne počne, samo zaseda prostor.
Prednost je v tem, da niste morali pisati novih virov za združevanje dobav.
Vsak vir, ki ustvarja pod, je avtomatično pripravljen za združevanje.
To je zanimivo, saj imate nenadoma dobave, razpršene po več regijah, pa tega niste opazili. Kljub temu je to precej tvegano, saj se vse drži nekakšne magije.
Toda če se Shipper trudi predvsem omiliti posledice dobav, multi-cluster-scheduler izvaja bolj splošne naloge in morda bolje ustreza paketnim nalogam.
Nima naprednega mehanizma postopnih dobav.
Več o multi-cluster-schedulerju lahko izveste na .
Če želite prebrati o multi-cluster-schedulerju v praksi, ima Admiralty — delovnimi procesi, dogodki, CI in CD Kubernetes.
Druga orodja in rešitve
Povezovanje več klasterjev in upravljanje z njimi je zahtevna naloga, splošna rešitev ne obstaja.
Če želite podrobneje raziskati to temo, tukaj je nekaj virov:
- — orodje, ki povezuje overlay omrežja različnih klasterjev Kubernetes.
- Maloprodajna mreža Target uporablja .
- Poskusite uporabiti IPV6 in .
- Lahko uporabite service mesh, na primer .
- Cilium, vtičnik omrežnega vmesnika za kontejnerje, ponuja , ki omogoča združevanje več klasterjev
To je vse za danes
Hvala, da ste prebrali do konca!
Če veste, kako učinkoviteje povezati več klasterjev, .
Dodali bomo vaš način v povezave.
Posebna zahvalnost Krisu Nesbittu-Smitha () in Vincentu de Smetu () (inženirju za zanesljivost na ) za to, da sta prebrala članek in delila koristne informacije o tem, kako deluje federacija.
Izvor: habr.com
