Mirë se vini në serinë e udhëzuesve të shpejtë për Kubernetes. Kjo është një kolonë e rregullt me pyetje nga më interesante që marrim online dhe në trajnimet tona. Pëgjigjet një ekspert i Kubernetes.
Eksperti i sotëm është Daniele Polencic (). Daniele punon si instruktor dhe zhvillues softueri në .
Nëse dëshironi të merrni përgjigjen për pyetjen tuaj në postimin e ardhshëm, ose në .
A e keni humbur postimin e kaluar? .
Si të lidhni klasterët Kubernetes në qendra të ndryshme të të dhënave?
Në përmbledhje: , dhe gjithashtu rekomandoj të lexoni për dhe .
Shpesh infrastruktura riprodhohet dhe shpërndahet në rajone të ndryshme, veçanërisht në ambiente të kontrolluara.
Nëse një rajon nuk është në dispozicion, trafiku redirektohet në një tjetër për të shmangur ndalesat.
Me Kubernetes mund të përdorni një strategji të ngjashme dhe të shpërndani ngarkesat e punës në rajone të ndryshme.
Mund të keni një ose më shumë klasterë për ekip, rajon, ambient ose një kombinim të këtyre elementeve.
Klasterët tuaj mund të vendosen në re të ndryshme dhe në mjedise lokale.
Por si të planifikoni infrastrukturën për një shpërndarje të tillë gjeografike?
A duhet të krijoni një klaster të madh që përfshin disa re nën një rrjet të vetëm?
Ose të vendosni shumë klasterë të vegjël dhe të gjeni një mënyrë për t'i kontrolluar dhe sinkronizuar ato?
Një klaster udhëheqës
Krijimi i një klasteri nën një rrjet të vetëm nuk është aq e lehtë.
Imaginoni, keni një aksident, është humbur lidhja midis segmenteve të klasterit.
Nëse keni një server kryesor, gjysma e burimeve nuk do të mund të marrin urdhra të rinj, sepse nuk do të mund të lidhen me kryesorin.
Dhe në këtë rast, keni tabela të vjetra ruterimi (kube-proxy nuk mund të ngarkojë të rejat) dhe asnjë pod të shtuar (kubelet nuk mund të kërkojë azhurnime).
Çfarë është edhe më e keqe, nëse Kubernetes nuk sheh një nyje, e markon atë si të humbur dhe shpërndan pod’ët që mungojnë në nyjet ekzistuese.
Si rezultat, keni dyfish pod’ë.
Nëse krijoni nga një server kryesor për secilin rajon, do të keni probleme me algoritmin për të arritur konsensusin në databazën etcd.Shën. red. — Në të vërtetë, baza e të dhënave etcd nuk ka nevojë patjetër të ndodhet në serverat kryesorë. Ajo mund të aktivizohet në një grup të veçantë serverësh në një rajon. Megjithatë, kjo do të sjellë një pikë dështimi për klusterin. Sidoqoftë, është e shpejtë.)
etcd përdor , për të arritur një konsensus mbi vlerën para se ta shkruajë atë në disk.
Kështu që shumica e instancave duhet të arrijnë konsensusin para se gjendja të mund të shkruhet në etcd.
Nëse vonesa midis instancave të etcd rritet ndjeshëm, siç ndodh me tre instanca etcd në regione të ndryshme, kërkohet shumë kohë për të arritur konsensusin dhe për ta shkruar atë në disk.
Kjo ndikon edhe në kontrollorët e Kubernetes.
Menaxheri i kontrollorëve ka nevojë për më shumë kohë për të mësuar mbi ndryshimin dhe për të shkruar përgjigjen në bazën e të dhënave.
Dhe pasi që kontrollorët nuk janë vetëm një, por disa, ndodhin një reaksion në zinxhir, dhe e gjithë klasteri fillon të funksionojë shumë ngadalë..
etcd është aq i ndjeshëm ndaj vonesave, saqë .
Momentalisht, nuk ka shembuj të mirë të një rrjeti të madh për një klaster.
Në përgjithësi, komuniteti i zhvilluesve dhe grupi SIG-cluster po përpiqen të kuptojnë se si të orkestrojnë klasterët ashtu si Kubernetes orkestrojnë konteinerit.
Opsioni 1: federata e klasterëve me kubefed
Pergjigjja zyrtare nga SIG-cluster është .
Për herë të parë, doli të menaxhohej një koleksion klasterësh si një objekt të vetëm përmes mjetit kube federation.
Fillimi ishte i mirë, por përfundimisht kube federation nuk arriti të bëhej popullor, sepse nuk mbështeste të gjitha burimet.
Ai mbështeste shpërndarjen e kombinuar dhe shërbimet, por, për shembull, nuk mbështeste StatefulSets.
Dhe gjithashtu konfigurimi i federatës u transmetua në formë anotacionesh dhe nuk ishte fleksibël.
Imagjinoni se si mund të përshkruhet ndarja e kopjeve për çdo klaster në federatë duke përdorur vetëm dhe vetëm anotacione.
Rezultoi një kaos i plotë.
SIG-cluster bëri një punë të madhe pas kubefed v1 dhe vendosi të qaset problemit nga një këndvështrim tjetër.
Në vend të anotacioneve, ata vendosën të lëshonin një kontrollor që instalon në klasterët. Ai mund të konfigurohet me ndihmën e përcaktimeve të burimeve të personalizuara (Custom Resource Definition, CRD).
Për çdo burim që do të jetë pjesë e federatës, keni një përcaktim personal të CRD nga tre seksione:
- përcaktimi standard i burimit, si p.sh. një deploy;
- me kaluesin e pseudo-klasës
pozitimi, ku përcaktoni se si do të shpërndahen burimet në federatë; - me kaluesin e pseudo-klasës
përsëritje, ku për një burim specifik mund të përsëritni peshën dhe parametrat nga pozicioni.
Ja një shembull i një shpërndarjeje të përbashkët me seksione pozicioni dhe përsëritje.
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: 5Siç shihni, shpërndarja është e shpërndarë në dy klastera: cluster1 dhe cluster2.
Klusteri i parë ofron tre replika, ndërsa klusteri i dytë ka vlerën 5.
Nëse keni nevojë për më shumë kontroll mbi numrin e replikave, kubefed2 ofron një objekt të ri ReplicaSchedulingPreference, ku replikat mund të shpërndahen sipas peshës:
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 dhe API ende nuk janë plotësisht gati, dhe në depo zyrtare të projektit po zhvillohet aktivisht.
Mbani nën vëzhgim kubefed2, por mbani mend se për mjedisin e punës, ai ende nuk është i përshtatshëm.
Mësoni më shumë për kubefed2 nga në blogun për Kubernetes dhe në .
Opcion 2: bashkimi i klasterave në stilin Booking.com
Zhvilluesit e Booking.com nuk u morën me kubefed v2, por shpikën Shipper - një operator për shpërndarjen në klastera të shumtë, në rajone të shumta dhe në mjete të shumta.
që është disi e ngjashme me kubefed2.
Të dy mjetet lejojnë konfiguroin strategjinë e shpërndarjes në klastera të shumtë (cilët klastera përdoren dhe sa replika kanë).
Por qëllimi i Shipper është të zvogëlojë rrezikun e gabimeve në shpërndarje.
Në Shipper mund të përcaktoni një sërë hapash, që përshkruajnë ndarjen e replikave ndërmjet shpërndarjes së mëparshme dhe asaj aktuale dhe volumin e trafikut që hyn.
Kur dërgoni një burim në klaster, kontrolluesi i Shipper e shpërndan këtë ndryshim hap pas hapi në të gjithë klasterat e bashkuar.
Dhe, Shipper është shumë i kufizuar.
Për shembull, ai pranon Helm-chart si input dhe nuk mbështet burimet vanilla.
Në përgjithësi, Shipper funksionon kështu.
Në vend të dërgesës standarde, duhet të krijoni burimin e aplikacionit, duke përfshirë Helm-chartin:
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 është një opsion i mirë për menaxhimin e shumë klasterëve, por lidhja e tij e ngushtë me Helm vetëm sa pengon.
Po t’i kalojmë të gjithë nga Helm në или ?
Mësoni më shumë rreth Shipper dhe filozofisë së tij në .
Nëse dëshironi të hulumtoni kodin, .
Opsioni 3: ‘magjike’ bashkimi i klasterëve
Kubefed v2 dhe Shipper punojnë me federatën e klasterëve, duke u ofruar klasterëve burime të reja përmes definicionit të burimeve të përdoruesve.
Por ndoshta nuk dëshironi të rishkruani të gjitha dërgesat, StatefulSets, DaemonSets dhe të tjerë për të bashkuar?
Si ta përfshini një klaster ekzistues në federatë pa ndryshuar YAML?
, i cili merret me ngarkesat e punës në klasterë.
Por në vend që të shpikni një mënyrë të re për të ndërvepruar me klasterin dhe për të mbështjellë burimet në definicionet e përdoruesve, multi-cluster-scheduler është integruar në ciklin standard të jetës të Kubernetesit dhe kap të gjitha thirrjet që krijojnë pods.
Çdo pod i krijuar menjëherë zëvendësohet me një vend të zbrazët.
multi-cluster-scheduler përdor , në mënyrë që të kapë thirrjen dhe të krijojë një pod të zbrazët pa aktivitet.
Pod-i origjinal kalon nëpër një cikël tjetër planifikimi, ku pas anketimit të gjithë federatës merret një vendim mbi vendosjen.
Në fund, pod-i dërgohet në klasterin e synuar.
Si rezultat, ju keni një pod të tepërt, i cili nuk bën asgjë, thjesht zëvendëson hapësirën.
Avantazhi është se nuk keni pasur nevojë të shkruani burime të reja për të bashkuar dërgesat.
Çdo burim që krijon pod, automatikisht është i gatshëm për bashkim.
Kjo është interesante, pasi ju papritur keni dërgesa të shpërndara në disa rajone, dhe nuk e keni vënë re. Megjithatë, kjo është mjaft e rrezikshme, pasi gjithçka mbështetet në magji.
Por nëse Shipper përpiqet kryesisht të zbusë pasojat e dërgesave, multi-cluster-scheduler kryen detyra më gjithëpërfshirëse dhe ndoshta është më i përshtatshëm për detyra me paketa.
Ai nuk ka një mekanizëm të avancuar për dërgesat gradualisht.
Më shumë rreth multi-cluster-scheduler mund të mësoni në .
Nëse dëshironi të lexoni rreth multi-cluster-scheduler në veprim, Admiralty ka — proceset e punës, ngjarjet, CI dhe CD të Kubernetes.
Mjetet dhe zgjidhjet e tjera
Lidhja dhe menaxhimi i disa klasterëve është një detyrë e komplikuar, nuk ka një zgjidhje universale.
Nëse dëshiron të studiojë më në thellësi këtë temë, ja disa burime për ju:
- — një mjet që lidh rrjetet overlay të klasterëve të ndryshëm të Kubernetes.
- Rrjeti me pakicë Target përdor .
- Provoni të përdorni IPV6 dhe .
- Mund të përdoret një service mesh, për shembull .
- Cilium, një plugin i ndërfaqes së rrjetit të kontejnerëve, ofron , i cili lejon kombinimin e disa klasterëve
Kjo është gjithçka për sot
Faleminderit që e lexuat deri në fund!
Nëse e dini një mënyrë më efikase për të lidhur disa klasterë, .
Ne do të shtojmë mënyrën tuaj në lidhje.
Falë të veçantë Chris Nesbitt-Smith () dhe Vincent De Smet () (inxhiner sigurie në ) për leximin e artikullit dhe ndarjen e informacionit të dobishëm rreth mënyrës sesi funksionon federata.
Burimi: habr.com
