Dobrodošli u Kubernetes Quick Start Series. Ovo je redovna kolumna sa najzanimljivijim pitanjima koja dobijamo na internetu i na našim treninzima. Odgovori stručnjaka za Kubernetes.
Današnji stručnjak je Daniel Polenchik (). Daniel radi kao instruktor i programer softvera u .
Ukoliko želite odgovor na svoje pitanje u sljedećem postu, ili .
Propustili ste prethodne objave? .
Kako povezati Kubernetes klastere u različitim data centrima?
Ukratko: , a također vam savjetujem da pročitate o tome и .
Često se infrastruktura replicira i distribuira u različitim regionima, posebno u kontrolisanim okruženjima.
Ako je jedna regija nedostupna, saobraćaj se preusmjerava na drugu kako bi se izbjegli prekidi.
Uz Kubernetes, možete koristiti sličnu strategiju i distribuirati radna opterećenja u različitim regijama.
Možete imati jedan ili više klastera po timu, regionu, okruženju ili kombinaciju ovih.
Vaši klasteri mogu biti hostovani u više oblaka i na lokaciji.
Ali kako planirati infrastrukturu za takvo geografsko širenje?
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 klaster lidera
Stvaranje jednog klastera preko jedne mreže nije tako lako.
Zamislite da imate nesreću, veza između segmenata klastera je izgubljena.
Ako imate jedan glavni server, polovina resursa neće moći primiti nove komande jer neće moći kontaktirati glavnog servera.
A u isto vrijeme imate stare tablice rutiranja (kube-proxy ne može preuzeti nove) i nema dodatnih podova (kubelet ne može tražiti ažuriranja).
Još gore, ako Kubernetes ne može vidjeti čvor, označava ga kao siroče i distribuira module koji nedostaju na postojeće čvorove.
Kao rezultat, imate duplo više mahuna.
Ako napravite jedan glavni server po regionu, biće problema sa algoritmom konsenzusa u etcd bazi podataka. (cca. ed. - U stvari, etcd baza podataka ne mora biti locirana na glavnim serverima. Može se pokrenuti na posebnoj grupi servera u istoj regiji. Međutim, primivši u isto vrijeme tačku kvara klastera. Ali brzo.)
etcd koristi da se dogovorite o vrijednosti prije nego što je zapišete na disk.
To jest, većina instanci mora postići konsenzus prije nego što se država može pisati u etcd.
Ako kašnjenje između etcd instanci vrtoglavo raste, kao što je slučaj sa tri etcd instance u različitim regijama, potrebno je mnogo vremena da se dogovorimo oko vrijednosti i zapišemo je na disk.
Ovo se odražava i na Kubernetes kontrolere.
Menadžer kontrolora treba više vremena da nauči o promjeni i napiše odgovor u bazu podataka.
A pošto kontroler nije jedan, već nekoliko, dobije se lančana reakcija i cijeli klaster počinje raditi vrlo sporo.
etcd je toliko osjetljiv na kašnjenje da .
Trenutno nema dobrih primjera velike mreže za jedan klaster.
U osnovi, zajednica programera i grupa SIG-klastera pokušavaju da shvate kako da orkestriraju klastere na isti način na koji Kubernetes orkestrira kontejnere.
Opcija 1: federalni klasteri s kubefed-om
Zvaničan odgovor SIG-klastera - .
Po prvi put smo pokušali da upravljamo kolekcijom klastera kao jednim objektom pomoću alata kube federacije.
Početak je bio dobar, ali na kraju kube federacija nije postala popularna, jer nije podržavala sve resurse.
Podržavao je federalne zalihe i usluge, ali ne i StatefulSets, na primjer.
Također, konfiguracija federacije je proslijeđena u obliku napomena i nije bila fleksibilna.
Zamislite kako možete opisati podelu replika za svaki klaster u federaciji koristeći jednu napomenu.
Ispostavilo se da je to bio potpuni haos.
SIG-cluster je napravio odličan posao nakon kubefed v1 i odlučio je pristupiti problemu iz drugog ugla.
Umjesto napomena, odlučili su izdati kontroler koji je instaliran na klasterima. Može se konfigurirati korištenjem prilagođenih definicija resursa (Custom Resource Definition, CRD).
Za svaki resurs koji će biti udružen, imate prilagođenu CRD definiciju u tri odjeljka:
- standardna definicija resursa, kao što je deploy;
- odjeljak
placement, gdje definirate kako će se resurs distribuirati u federaciji; - odjeljak
override, gdje za određeni resurs možete nadjačati težinu i parametre iz položaja.
Evo primjera skupne isporuke sa 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, ponuda je podijeljena u dva klastera: cluster1 и cluster2.
Prvi klaster isporučuje tri replike, a drugi ima vrijednost 5.
Ako vam je potrebna veća kontrola nad brojem replika, kubefed2 pruža novi ReplicaSchedulingPreference objekat gdje se replike mogu mjeriti:
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, a aktivan je rad u zvaničnom repozitorijumu projekta.
Pripazite na kubefed2, ali imajte na umu da još uvijek nije dovoljno dobar za proizvodno okruženje.
Saznajte više o kubefed2 od na Kubernetes blogu i .
Opcija 2: grupisanje Booking.com stila
Programeri Booking.com-a nisu se bavili kubefed v2, ali su smislili Shipper, operatera za dostavu na više klastera, više regija i više oblaka.
donekle sličan kubefed2.
Oba alata vam omogućavaju da prilagodite svoju strategiju implementacije više klastera (koji se klasteri koriste i koliko replika imaju).
Još Posao pošiljatelja je da smanji rizik od grešaka u isporuci.
U Shipperu možete definirati niz koraka koji opisuju podjelu replika između prethodne i trenutne implementacije i količinu dolaznog prometa.
Kada gurnete resurs u klaster, kontroler otpremnika postepeno implementira tu promjenu na sve federalne klastere.
Također je Shipper vrlo ograničen.
Na primjer, uzima Helmove karte kao ulaz i ne podržava resurse vanile.
Općenito, otpremnik funkcionira na sljedeći način.
Umjesto standardne distribucije, trebate kreirati resurs aplikacije koji uključuje Helmov 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šestrukim klasterima, ali njegov bliski odnos sa Helmom samo smeta.
Šta ako se svi prebacimo sa Helma na ili ?
Saznajte više o Shipperu i njegovoj filozofiji na .
Ako želite da se udubite u kod, .
Opcija 3: "magično" spajanje klastera
Kubefed v2 i Shipper rade sa federacijom klastera dajući nove resurse klasterima kroz prilagođenu definiciju resursa.
Ali šta ako ne želite da prepišete sve zalihe, StatefulSets, DaemonSets, itd. koji će biti spojeni?
Kako uključiti postojeći klaster u federaciju bez promjene YAML-a?
, koji se bavi planiranjem radnih opterećenja na klasterima.
Ali umjesto izmišljanja novog načina interakcije s klasterom i umotavanja resursa u prilagođene definicije, multi-cluster-scheduler se ubrizgava u standardni životni ciklus Kubernetesa i presreće sve pozive koji stvaraju podove.
Svaka kreirana kapsula se odmah zamjenjuje lutkom.
koristi multi-cluster-scheduler za presretanje poziva i kreiranje neaktivne lažne kapsule.
Originalni pod prolazi kroz drugi ciklus zakazivanja gdje se, nakon anketiranja cijele federacije, donosi odluka o hostingu.
Konačno, kapsula se isporučuje u ciljni klaster.
Kao rezultat, imate dodatnu kapsulu koja ne radi ništa, samo zauzima prostor.
Prednost je u tome što ne morate pisati nove resurse da biste kombinirali zalihe.
Svaki resurs koji kreira pod je automatski spreman za povezivanje.
Ovo je zanimljivo, jer odjednom imate zalihe raspoređene u nekoliko regija, a niste primijetili. Međutim, to je prilično rizično, jer ovdje sve počiva na magiji.
Ali dok Shipper uglavnom pokušava da ublaži efekte pošiljki, multi-cluster-scheduler je opštiji i možda bolje prilagođen za grupne poslove.
Nema napredni mehanizam postupne isporuke.
Više o multi-cluster-scheduleru možete pronaći na .
Ako želite čitati o multi-cluster-scheduleru u akciji, Admiralty ima - tokovi posla, događaji, CI i CD Kubernetes.
Ostali alati i rješenja
Povezivanje i upravljanje višestrukim klasterima je složen zadatak i ne postoji jedno rješenje za sve.
Ako želite saznati više o ovoj temi, evo nekoliko resursa:
- je alat koji povezuje preklapajuće mreže različitih Kubernetes klastera.
- Trgovački lanac Target koristi .
- Pokušajte koristiti IPV6 i .
- Možete koristiti servisnu mrežu, na primjer .
- Cilium, dodatak mrežnog interfejsa kontejnera, nudi , što vam omogućava da kombinujete nekoliko klastera
To je sve za danas
Hvala što ste pročitali do kraja!
Ako znate kako efikasnije povezati više klastera, .
Vašu metodu ćemo dodati na linkove.
Posebno hvala Chrisu Nesbitt-Smithu () i Vincent de Sme () (inženjeru pouzdanosti u ) za čitanje članka i dijeljenje korisnih informacija o tome kako federacija funkcionira.
izvor: www.habr.com