Sveiki atvykę į mūsų „Kubernetes Quick Start“ seriją. Tai įprasta rubrika su įdomiausiais klausimais, kuriuos gauname internete ir per mokymus. Kubernetes ekspertas atsako.
Šiandienos ekspertas yra Danielis Polenčikas (). Danielis dirba instruktoriumi ir programinės įrangos kūrėju .
Jei norite, kad į jūsų klausimą būtų atsakyta kitame įraše, arba .
Praleidote ankstesnius įrašus? .
Kaip sujungti „Kubernetes“ grupes skirtinguose duomenų centruose?
Trumpai: , taip pat rekomenduoju paskaityti apie и .
Gana dažnai infrastruktūra atkartojama ir paskirstoma skirtinguose regionuose, ypač kontroliuojamoje aplinkoje.
Jei vienas regionas nepasiekiamas, srautas nukreipiamas į kitą, kad būtų išvengta trikdžių.
Naudodami „Kubernetes“ galite naudoti panašią strategiją ir paskirstyti darbo krūvius skirtinguose regionuose.
Galite turėti vieną ar daugiau grupių vienoje komandoje, regione, aplinkoje arba šių elementų derinyje.
Jūsų grupės gali būti priglobtos skirtinguose debesyse ir vietinėse patalpose.
Bet kaip planuojate infrastruktūrą tokiam geografiniam paplitimui?
Ar reikia sukurti vieną didelį klasterį kelioms debesų aplinkoms viename tinkle?
Arba turite daug mažų grupių ir rasite būdą jas valdyti bei sinchronizuoti?
Vienas vadovų klasteris
Sukurti vieną klasterį viename tinkle nėra taip paprasta.
Įsivaizduokite, kad atsitiko nelaimingas atsitikimas, ryšys tarp klasterio segmentų nutrūksta.
Jei turite vieną pagrindinį serverį, pusė išteklių negalės gauti naujų komandų, nes negalės susisiekti su pagrindiniu serveriu.
Ir tuo pat metu turite senas maršruto lenteles (kube-proxy negali atsisiųsti naujų) ir jokių papildomų rinkinių (kubelet negali prašyti atnaujinimų).
Dar blogiau, jei „Kubernetes“ nemato mazgo, jis pažymi jį kaip našlaitį ir paskirsto trūkstamus blokus esamiems mazgams.
Dėl to jūs turite dvigubai daugiau ankščių.
Jei kiekvienam regionui sukursite vieną pagrindinį serverį, kils problemų su sutarimo algoritmu etcd duomenų bazėje. (apytiksliai red. — Tiesą sakant, etcd duomenų bazė nebūtinai turi būti pagrindiniuose serveriuose. Jis gali būti paleistas atskiroje serverių grupėje tame pačiame regione. Tiesa, tuo pačiu gaunant klasterio gedimo tašką. Bet greitai.)
etcd naudojimas suderinti vertę prieš įrašant ją į diską.
Tai reiškia, kad dauguma atvejų turi pasiekti sutarimą, kad būtų galima parašyti valstybę į etcd.
Jei delsa tarp etcd egzempliorių labai padidėja, kaip yra su trimis etcd egzemplioriais skirtinguose regionuose, reikia ilgai derėtis dėl vertės ir įrašyti ją į diską.
Tai atsispindi Kubernetes valdikliuose.
Valdiklio valdytojui reikia daugiau laiko sužinoti apie pakeitimą ir parašyti atsakymą į duomenų bazę.
Ir kadangi yra ne vienas valdiklis, o keli, įvyksta grandininė reakcija ir visas klasteris pradeda veikti labai lėtai.
etcd yra toks jautrus delsai, kad .
Šiuo metu nėra gerų didelio tinklo, skirto vienam klasteriui, pavyzdžių.
Iš esmės kūrėjų bendruomenė ir SIG klasterių grupė bando išsiaiškinti, kaip organizuoti grupes taip pat, kaip Kubernetes orkestruoja konteinerius.
1 variantas: klasterių susijungimas su kubefed
Oficialus atsakymas iš SIG klasterio - .
Pirmą kartą bandėme valdyti grupių kolekciją kaip vieną objektą naudodami kube federacijos įrankį.
Pradžia buvo gera, bet galiausiai kube federacija taip ir neišpopuliarėjo, nes nepalaikė visų išteklių.
Jis palaikė sujungtus pristatymus ir paslaugas, bet ne, pavyzdžiui, „StatefulSets“.
Be to, federacijos konfigūracija buvo perduota anotacijų forma ir nebuvo lanksti.
Įsivaizduokite, kaip galėtumėte apibūdinti kiekvienos federacijos klasterio replikų skaidymą naudodami tik komentarus.
Pasirodė visiška netvarka.
SIG klasteris padarė daug darbo po kubefed v1 ir nusprendė pažvelgti į problemą kitu kampu.
Vietoj anotacijų jie nusprendė išleisti valdiklį, kuris yra įdiegtas klasteriuose. Jį galima tinkinti naudojant tinkintus išteklių apibrėžimus (CRD).
Kiekvienam ištekliui, kuris bus federacijos dalis, turite tinkintą CRD apibrėžimą su trimis skyriais:
- standartinis išteklių apibrėžimas, pavyzdžiui, diegimas;
- skyrius
placement, kur apibrėžiate, kaip ištekliai bus paskirstomi federacijoje; - skyrius
override, kur konkrečiam ištekliui galite nepaisyti svorio ir parametrų iš paskirties vietos.
Štai kombinuoto pristatymo pavyzdys su išdėstymo ir nepaisymo skyriais.
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: 5Kaip matote, tiekimas yra paskirstytas dviem klasteriams: cluster1 и cluster2.
Pirmasis klasteris pateikia tris kopijas, o antrasis nustatytas į 5.
Jei jums reikia daugiau kontroliuoti kopijų skaičių, kubefed2 pateikia naują ReplicaSchedulingPreference objektą, kuriame replikos gali būti įvertintos:
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 struktūra ir API dar nėra visiškai paruoštos, o aktyvus darbas vyksta oficialioje projektų saugykloje.
Stebėkite kubefed2, bet atminkite, kad jis dar netinkamas gamybai.
Sužinokite daugiau apie kubefed2 iš dienoraštyje apie Kubernetes ir in .
2 variantas: grupių sujungimas Booking.com stiliumi
Booking.com kūrėjai nedirbo su kubefed v2, tačiau jie sugalvojo „Shipper“ - operatorių, skirtą pristatyti keliuose klasteriuose, keliuose regionuose ir keliuose debesyse.
šiek tiek panašus į kubefed2.
Abu įrankiai leidžia tinkinti kelių grupių diegimo strategiją (kurios grupės naudojamos ir kiek jos turi kopijų).
bet Siuntėjo tikslas – sumažinti klaidų riziką pristatymo metu.
Programoje „Siuntėjas“ galite apibrėžti keletą veiksmų, apibūdinančių kopijų padalijimą į ankstesnį ir dabartinį diegimą bei gaunamo srauto apimtį.
Kai siunčiate išteklius į klasterį, siuntėjo valdiklis laipsniškai išleidžia tuos pokyčius visose sujungtose grupėse.
Be to, siuntėjas yra labai ribotas.
Pavyzdžiui, kaip įvestį priima vairo diagramas ir nepalaiko vanilės išteklių.
Apskritai siuntėjas veikia taip.
Vietoj standartinio pristatymo turite sukurti programos šaltinį, kuriame yra vairo diagrama:
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: 3Siuntėjas yra geras pasirinkimas norint valdyti kelias grupes, tačiau jo glaudūs santykiai su „Helm“ tik trukdo.
Ką daryti, jei mes visi pereisime iš Helmo į arba ?
Sužinokite daugiau apie Shipper ir jo filosofiją adresu .
Jei norite įsigilinti į kodą, .
3 variantas: „stebuklingas“ klasterio sujungimas
„Kubefed v2“ ir „Siuntėjas“ dirba su klasterių federacija, suteikdami naujų išteklių klasteriams per tinkintą išteklių apibrėžimą.
Bet ką daryti, jei nenorite perrašyti visų pristatymų, „StatefulSets“, „DaemonSets“ ir kt.
Kaip įtraukti esamą klasterį į federaciją nekeičiant YAML?
, kuriame kalbama apie klasterių darbo krūvių planavimą.
Tačiau vietoj to, kad būtų sukurtas naujas būdas sąveikauti su grupe ir įtraukti išteklius į pasirinktinius apibrėžimus, kelių grupių planuoklis įterpiamas į standartinį „Kubernetes“ gyvavimo ciklą ir perima visus skambučius, kurie sukuria blokus.
Kiekviena sukurta anga iš karto pakeičiama manekenu.
kelių grupių planavimo priemonės Norėdami perimti skambutį ir sukurti tuščiosios eigos manekenę.
Pradinė grupė pereina kitą planavimo ciklą, kuriame, apklausus visą federaciją, priimamas sprendimas dėl paskirties vietos.
Galiausiai ankštis pristatoma į tikslinę grupę.
Dėl to jūs turite papildomą dėklą, kuri nieko nedaro, tik užima vietą.
Privalumas yra tas, kad jums nereikėjo rašyti naujų išteklių, kad derintumėte atsargas.
Kiekvienas išteklius, sukuriantis grupę, yra automatiškai paruoštas sujungti.
Tai įdomu, nes staiga jūs turite atsargas paskirstytas keliuose regionuose, o jūs net nepastebėjote. Tačiau tai gana rizikinga, nes čia viskas remiasi magija.
Tačiau nors „Siuntėjas“ daugiausia stengiasi sušvelninti pristatymo poveikį, kelių grupių planuotojas atlieka bendresnes užduotis ir galbūt geriau tinka paketiniams darbams.
Jame nėra pažangaus laipsniško pristatymo mechanizmo.
Daugiau apie kelių grupių planavimo priemonę galite rasti adresu .
Jei norite perskaityti apie tai, kaip veikia kelių grupių planavimo priemonė, Admiralitetas turi — darbo eigos, įvykiai, CI ir CD Kubernetes.
Kiti įrankiai ir sprendimai
Kelių grupių prijungimas ir valdymas yra sudėtinga užduotis ir nėra universalaus sprendimo.
Jei norite toliau nagrinėti šią temą, čia yra keletas šaltinių:
- yra įrankis, jungiantis skirtingų Kubernetes klasterių perdangos tinklus.
- Mažmeninės prekybos tinklas Tikslinės paskirties .
- Pabandykite naudoti IPV6 ir .
- Pavyzdžiui, galite naudoti aptarnavimo tinklelį .
- Siūlo konteinerinio tinklo sąsajos papildinį Cilium , kuri leidžia sujungti keletą grupių
Tai viskas siandienai
Ačiū, kad skaitėte iki galo!
Jei žinote, kaip efektyviau sujungti kelias grupes, .
Prie nuorodų pridėsime jūsų metodą.
Ypatingas ačiū Chrisui Nesbittui-Smithui () ir Vincentas de Sme () (patikimumo inžinierius ) už tai, kad perskaitėte straipsnį ir dalinatės naudinga informacija apie federacijos veiklą.
Šaltinis: www.habr.com