Dobrodošli u našu seriju Kubernetes Quick Start. Ovo je stalna rubrika s najzanimljivijim pitanjima koja dobivamo online i na našim treninzima. Stručnjak za Kubernetes odgovara.
Današnji stručnjak je Daniel Polenchik (). Daniel radi kao instruktor i programer softvera u .
Ako želite odgovor na svoje pitanje u sljedećem postu, ili .
Propustili ste prethodne objave? .
Kako povezati Kubernetes klastere u različitim podatkovnim centrima?
ukratko: , a također preporučujem čitanje o и .
Često se infrastruktura replicira i distribuira u različitim regijama, posebno u kontroliranim okruženjima.
Ako jedna regija nije dostupna, promet se preusmjerava na drugu kako bi se izbjegli prekidi.
S Kubernetesom možete koristiti sličnu strategiju i raspodijeliti radna opterećenja po različitim regijama.
Možete imati jedan ili više klastera po timu, regiji, okruženju ili kombinaciji ovih elemenata.
Vaši klasteri mogu biti smješteni u različitim oblacima i na lokaciji.
Ali kako planirati infrastrukturu za takvu geografsku rasprostranjenost?
Trebate li stvoriti jedan veliki klaster za nekoliko okruženja u oblaku preko jedne mreže?
Ili imate mnogo malih klastera i pronađite način da ih kontrolirate i sinkronizirate?
Jedan vodeći klaster
Stvaranje jednog klastera preko jedne mreže nije tako jednostavno.
Zamislite da imate nesreću, izgubljena je povezanost između segmenata klastera.
Ako imate jedan glavni poslužitelj, pola resursa neće moći primati nove naredbe jer neće moći kontaktirati glavnog.
A u isto vrijeme imate stare tablice usmjeravanja (kube-proxy ne može preuzeti nove) i nema dodatnih podova (kubelet ne može zahtijevati ažuriranja).
Da stvar bude gora, ako Kubernetes ne vidi čvor, označava ga kao siroče i distribuira nedostajuće module postojećim čvorovima.
Kao rezultat toga, imate dvostruko više mahuna.
Ako napravite jedan glavni poslužitelj za svaku regiju, bit će problema s algoritmom konsenzusa u etcd bazi podataka. (cca. izd. — Zapravo, etcd baza podataka ne mora se nužno nalaziti na glavnim poslužiteljima. Može se pokrenuti na zasebnoj grupi poslužitelja u istoj regiji. Istina, u isto vrijeme dobivanje točke kvara klastera. Ali brzo.)
etcd koristi za pregovaranje vrijednosti prije nego što je zapišete na disk.
Odnosno, većina instanci mora postići konsenzus prije nego što se stanje može napisati itd.
Ako se latencija između etcd instanci dramatično poveća, kao što je slučaj s tri etcd instance u različitim regijama, potrebno je dugo vremena da se dogovori vrijednost i zapiše je na disk.
To se odražava na Kubernetes kontrolere.
Upravitelj kontrolera treba više vremena da sazna o promjeni i napiše odgovor u bazu podataka.
A budući da ne postoji jedan kontroler, već nekoliko, dolazi do lančane reakcije i cijeli klaster počinje vrlo sporo raditi.
etcd je toliko osjetljiv na kašnjenje da .
Trenutno ne postoje dobri primjeri velike mreže za jedan klaster.
U osnovi, zajednica programera i SIG-cluster grupa pokušavaju smisliti kako orkestrirati klastere na isti način na koji Kubernetes orkestrira kontejnere.
Opcija 1: federacija klastera s kubefedom
Službeni odgovor SIG-klastera - .
Po prvi smo put pokušali upravljati kolekcijom klastera kao jednim objektom pomoću alata za federaciju kube.
Početak je bio dobar, ali na kraju kube federacija nikada nije postala popularna jer nije podržavala sve resurse.
Podržavao je federalne isporuke i usluge, ali ne i StatefulSets, na primjer.
Također, konfiguracija federacije se prenosila u obliku napomena i nije bila fleksibilna.
Zamislite kako biste mogli opisati particioniranje replike za svaki klaster u federaciji koristeći samo bilješke.
Bio je to potpuni nered.
SIG-cluster je napravio puno posla nakon kubefeda v1 i odlučio pristupiti problemu iz drugog kuta.
Umjesto napomena, odlučili su izdati kontroler koji se instalira na klastere. Može se prilagoditi korištenjem Custom Resource Definitions (CRD-ova).
Za svaki resurs koji će biti dio federacije imate prilagođenu CRD definiciju s tri odjeljka:
- standardna definicija resursa, na primjer implementacija;
- odjeljak
placement, gdje definirate kako će se resursi distribuirati u federaciji; - odjeljak
override, gdje za određeni resurs možete nadjačati težinu i parametre iz plasmana.
Ovdje je primjer kombinirane isporuke s odjeljcima za postavljanje i nadjačavanje.
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, opskrba je raspoređena u dva klastera: cluster1 и cluster2.
Prvi klaster daje tri replike, a drugi je postavljen na 5.
Ako vam je potrebna veća kontrola nad brojem replika, kubefed2 nudi novi objekt ReplicaSchedulingPreference gdje se replike mogu ponderirati:
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: 2CRD struktura i API još nisu sasvim spremni, au službenom repozitoriju projekta u tijeku je aktivan rad.
Pripazite na kubefed2, ali zapamtite da još nije prikladan za proizvodnju.
Saznajte više o kubefed2 od u blogu o Kubernetesu i in .
Opcija 2: kombiniranje klastera u stilu Booking.com
Programeri Booking.com-a nisu radili na kubefedu v2, ali su smislili Shipper - operatera za dostavu na nekoliko klastera, u nekoliko regija i u nekoliko oblaka.
donekle sličan kubefed2.
Oba alata omogućuju vam da prilagodite strategiju postavljanja više klastera (koji se klasteri koriste i koliko replika imaju).
Ali Cilj pošiljatelja je smanjiti rizik od pogrešaka tijekom isporuke.
U Shipperu možete definirati niz koraka koji opisuju podjelu replika između prethodne i trenutne implementacije i volumen dolaznog prometa.
Kada gurnete resurs u klaster, kontroler pošiljatelja postupno uvodi tu promjenu u sve pridružene klastere.
Također, Shipper je vrlo ograničen.
Na primjer, prihvaća karte kormila kao ulaz i ne podržava vanilla resurse.
Općenito govoreći, Shipper radi ovako.
Umjesto standardne isporuke, trebate izraditi resurs aplikacije koji uključuje Helm grafikon:
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 opcija za upravljanje više klastera, ali njegova bliska povezanost s Helmom samo smeta.
Što ako svi prijeđemo s Helma na ili ?
Saznajte više o Shipperu i njegovoj filozofiji na .
Ako želite kopati po kodu, .
Opcija 3: "čarobno" spajanje klastera
Kubefed v2 i Shipper rade s federacijom klastera, dajući nove resurse klasterima kroz prilagođenu definiciju resursa.
Ali što ako ne želite prepisati sve isporuke, StatefulSets, DaemonSets itd. za spajanje?
Kako uključiti postojeći klaster u federaciju bez promjene YAML-a?
, koji se bavi raspoređivanjem radnih opterećenja na klasterima.
No umjesto osmišljavanja novog načina interakcije s klasterom i omotavanja resursa u prilagođene definicije, multi-cluster-scheduler ugrađen je u standardni životni ciklus Kubernetesa i presreće sve pozive koji stvaraju podove.
Svaka stvorena mahuna odmah se zamjenjuje lutkom.
multi-cluster-scheduler koristi za presretanje poziva i stvaranje neaktivne lutke.
Izvorna kapsula prolazi kroz još jedan ciklus planiranja u kojem se, nakon anketiranja cijele federacije, donosi odluka o plasmanu.
Na kraju, kapsula se isporučuje u ciljni klaster.
Kao rezultat toga, imate dodatnu mahunu koja ne radi ništa, samo zauzima prostor.
Prednost je u tome što niste morali pisati nove resurse da biste kombinirali zalihe.
Svaki resurs koji stvara pod automatski je spreman za spajanje.
Ovo je zanimljivo, jer odjednom imate zalihe raspoređene u nekoliko regija, a niste ni primijetili. Međutim, to je prilično riskantno, jer ovdje sve počiva na magiji.
Ali dok Shipper uglavnom pokušava ublažiti utjecaj isporuka, multi-cluster-scheduler obrađuje općenitije zadatke i možda je prikladniji za skupne poslove.
Nema napredni mehanizam postupne isporuke.
Više o multi-cluster-scheduleru možete pronaći na .
Ako želite čitati o multi-cluster-scheduleru na djelu, Admiralty ima — tijek rada, događaji, CI i CD Kubernetes.
Ostali alati i rješenja
Povezivanje i upravljanje više klastera složen je zadatak i ne postoji univerzalno rješenje.
Ako želite dalje istražiti ovu temu, evo nekih izvora:
- je alat koji povezuje preklopne mreže različitih Kubernetes klastera.
- Maloprodajni lanac Target koristi .
- Pokušajte koristiti IPV6 i .
- Možete koristiti servisnu mrežu, na primjer .
- Cilium, dodatak mrežnog sučelja spremnika, nudi , koji vam omogućuje kombiniranje nekoliko klastera
To je sve za danas
Hvala što ste pročitali do kraja!
Ako znate kako učinkovitije povezati više klastera, .
Dodat ćemo vašu metodu poveznicama.
Posebna zahvala Chrisu Nesbitt-Smithu () i Vincent de Sme () (inženjer pouzdanosti u ) za čitanje članka i dijeljenje korisnih informacija o tome kako federacija funkcionira.
Izvor: www.habr.com