Dobrodošli u seriju kratkih vodiča o Kubernetesu. Ovo je redovita kolumna s najzanimljivijim pitanjima koja primamo putem interneta i na našim treninzima. Odgovara stručnjak za Kubernetes.
Današnji stručnjak je Daniele Polencic (). Daniele radi kao instruktor i softverski inženjer u .
Ako želite dobiti odgovor na svoje pitanje u sljedećem postu, ili u .
Jeste li propustili prethodne postove? .
Kako povezati Kubernetes klastere u različitim podatkovnim centrima?
Ukratko: , a preporučujem da pročitate o i .
Često se infrastruktura replicira i distribuira po različitim regijama, posebno u kontroliranim okruženjima.
Ako jedan region postane nedostupan, promet se preusmjerava u drugi kako bi se izbjegli prekidi.
Uz Kubernetes možete koristiti sličnu strategiju i distribuirati radne terete po različitim regijama.
Možete imati jedan ili više klastera po timu, regiji, okruženju ili kombinaciji tih elemenata.
Vaši klasteri mogu biti smješteni u različitim oblačnim uslugama i lokalnom okruženju.
Ali kako planirati infrastrukturu za takvo geografsko raspršenje?
Da li stvoriti jedan veliki klaster u više oblačnih sredina preko jedinstvene mreže?
Ili otvoriti mnogo malih klastera i pronaći način da ih kontrolišete i sinkronizujete?
Jedan upravljački klaster
Nije lako stvoriti jedan klaster u jedinstvenoj mreži.
Zamislite, imate kvar, izgubljena je povezanost između segmenata klastera.
Ako imate jedan master server, polovina resursa neće moći primati nove komande, jer se neće moći povezati s masterom.
A uz to, imate stare tablice rutiranja (kube-proxy ne može učitati nove) i nijedan dodatni pod (kubelet ne može tražiti ažuriranja).
Što je još gore, ako Kubernetes ne vidi čvor, označava ga kao izgubljenog i preusmjerava nedostajuće podove na postojeće čvorove.
Na kraju imate dvostruko više podova.
Ako napravite po jedan master server za svaku regiju, imat ćete problema s konsenzus algoritmom u bazi podataka etcd.napomena urednika — U stvarnosti, etcd baza podataka ne mora nužno biti na master poslužiteljima. Može se pokrenuti na zasebnoj grupi poslužitelja u jednoj regiji. Ipak, to rezultira točkom kvara klastera. No, brzo je.)
etcd koristi , kako bi se usuglasila vrijednost prije nego što se zapiše na disk.
Odnosno, većina instanci mora postići konsenzus prije nego što se stanje može zapisati u etcd.
Ako se kašnjenje između instanci etcd naglo povećava, kao u slučaju s tri instance etcd u različitim regijama, potrebno je puno vremena za usuglašavanje vrijednosti i zapisivanje na disk.
To se odražava i na Kubernetes kontrolere.
Menadžeru kontrolera treba više vremena da sazna za promjenu i zabilježi odgovor u bazu podataka.
A kako nije samo jedan kontroler, nego nekoliko, dobiva se lančana reakcija i cijeli klaster počinje raditi vrlo sporo..
etcd je toliko osjetljiv na kašnjenje da .
Trenutno ne postoje dobri primjeri velike mreže za jedan klaster.
Uglavnom, zajednica programera i grupa SIG-cluster pokušavaju shvatiti kako orkestrirati klastere na sličan način na koji Kubernetes orkestrira kontejnere.
Opcija 1: federacija klastera s kubefed
Službeni odgovor od SIG-cluster — .
Prvi put je upravljanje zbirkom klastera kao jedinstvenim objektom pokušano pomoću alata kube federation.
Početak je bio dobar, ali na kraju kube federation nikada nije stekao popularnost jer nije podržavao sve resurse.
Podržavao je objedinjene isporuke i servise, ali, na primjer, ne StatefulSets.
A konfiguracija federacije se prenosila u obliku anotacija i nije bila fleksibilna.
Zamislite kako se može opisati razdvajanje replika za svaki klaster u federaciji pomoću samo jednih anotacija.
Nastao je potpuni nered.
SIG-cluster je učinio veliki posao nakon kubefed v1 i odlučili su pristupiti problemu s druge strane.
Umjesto anotacija, odlučili su izdati kontroler koji se instalira na klastere. Može se konfigurirati pomoću korisničkih definicija resursa (Custom Resource Definition, CRD).
Za svaki resurs koji će biti dio federacije, imate prilagođenu definiciju CRD od tri dijela:
- standardna definicija resursa, poput implementacije;
- odjeljak
placement, gdje definirate kako će se resurs raspodijeliti unutar federacije; - odjeljak
override, gdje se za određeni resurs mogu nadjačati težina i parametri iz placement-a.
Evo primjera objedinjene isporuke s dijelovima 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 i cluster2.
Prvi klaster isporučuje tri replike, dok je za drugi navedena vrijednost 5.
Ako vam treba veća kontrola nad brojem replika, kubefed2 pruža novi objekt ReplicaSchedulingPreference, gdje se replike mogu rasporediti po 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š nisu potpuno spremni, a u službenom repozitoriju projekta aktivno se radi.
Pratite kubefed2, ali imajte na umu da trenutna verzija nije pogodna za proizvodno okruženje.
Saznajte više o kubefed2 iz na blogu o Kubernetesu i iz .
Opcija 2: objedinjavanje klastera u stilu Booking.com
Programeri Booking.com nisu radili na kubefed v2, ali su smislili Shipper — operator za isporuku na više klastera, u različitim regijama i u različitim oblacima.
nešto slično kubefed2.
Oba alata omogućuju postavljanje strategije implementacije na više klastera (koji klasteri se koriste i koliko im je replika).
Ali cilj Shipper-a je smanjiti rizik od grešaka prilikom isporuke.
U Shipper-u možete definirati niz koraka koji opisuju raspodjelu replika između prethodne i trenutne isporuke i volumen dolaznog prometa.
Kada šaljete resurs u klaster, Shipperov kontroler postupno implementira tu promjenu po svim objedninjenim klasterima.
Osim toga, Shipper je vrlo ograničen.
Na primjer, prihvaća Helm chartove kao ulazne podatke. i ne podržava vanilla resurse.
U osnovi, Shipper radi na sljedeći način.
Umjesto standardne isporuke, potrebno je stvoriti resurs aplikacije, uključujući 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 dobar izbor za upravljanje više klastera, ali njegova uska povezanost s Helm-om samo smeta.
A što ako se svi prebacimo s Helma na ili ?
Saznajte više o Shipperu i njegovoj filozofiji u .
Ako želite zaviriti u kod, .
Opcija 3: "magije" spajanja klastera
Kubefed v2 i Shipper rade s federacijom klastera, pružajući klasterima nove resurse kroz korisnički definirane resurse.
Ali možda ne želite ponovno pisati sve isporuke, StatefulSets, DaemonSets itd. za spajanje?
Kako uključiti postojeći klaster u federaciju, a da ne mijenjate YAML?
, koji se bavi radnim opterećenjima planiranja u klasterima.
Ali umjesto da izmislite novi način interakcije s klasterom i obavijate resurse u korisničke definicije, multi-cluster-scheduler se implementira u standardni životni ciklus Kubernetes-a i presreće sve pozive koji kreiraju pod-ove.
Svaki stvoreni pod odmah se zamjenjuje praznim.
multi-cluster-scheduler koristi , kako bi presreo poziv i stvorio neaktivan pod-praznjak.
Izvorni pod prolazi kroz još jedan ciklus planiranja, gdje se nakon ispitivanja cijele federacije donosi odluka o smještaju.
Na kraju, pod se isporučuje u ciljani klaster.
Na kraju imate dodatni pod koji ništa ne radi, samo zauzima prostor.
Prednost je u tome što niste morali pisati nove resurse za spajanje isporuka.
Svaki resurs koji stvara pod automatski je spreman za spajanje.
To je zanimljivo, jer iznenada imate isporuke raspoređene u nekoliko regija, a niste ni primijetili. No, to je prilično rizično jer se ovdje sve oslanja na magiju.
Ali ako Shipper nastoji ublažiti posljedice isporuka, multi-cluster-scheduler obavlja općenitije zadatke i možda bolje odgovara za paketne zadatke.
Nema napredni mehanizam postepenih isporuka.
Više o multi-cluster-scheduleru možete saznati na .
Ako želite čitati o multi-cluster-scheduleru u praksi, Admiralty ima — radnim procesima, događajima, CI i CD Kubernetes.
Drugi alati i rješenja
Povezivanje i upravljanje nekoliko klastera je složen zadatak, ne postoji univerzalno rješenje.
Ako želite detaljnije proučiti ovu temu, evo nekoliko resursa:
- — alat koji povezuje overlay mreže različitih Kubernetes klastera.
- Maloprodajna mreža Target koristi .
- Pokušajte koristiti IPV6 i .
- Možete koristiti service mesh, na primjer .
- Cilium, dodatak mrežnog sučelja za kontejnere, nudi , koja omogućuje kombiniranje nekoliko klastera
To bi bilo sve za danas
Hvala što ste pročitali do kraja!
Ako znate kako učinkovitije povezati nekoliko klastera, .
Dodati ćemo vaš način u linkove.
Posebna zahvalnost Krisu Nesbittu-Smithu () i Vincentu de Smetu () (inženjeru pouzdanosti u ) za pregled članka i dijeljenje korisnih informacija o tome kako funkcionira federacija.
Izvor: habr.com
