Kaip prijungti „Kubernetes“ grupes skirtinguose duomenų centruose
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 (Danielė Polencic). Danielis dirba instruktoriumi ir programinės įrangos kūrėju Learnk8s.
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 plausto algoritmassuderinti 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.
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.
Kaip 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:
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.
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.
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 oficialus saugyklos puslapis.
Jei norite perskaityti apie tai, kaip veikia kelių grupių planavimo priemonė, Admiralitetas turi įdomus naudojimo atvejis su Argo — 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ų:
Siūlo konteinerinio tinklo sąsajos papildinį Cilium klasterio tinklelio funkcija, kuri leidžia sujungti keletą grupių
Tai viskas siandienai
Ačiū, kad skaitėte iki galo!
Jei žinote, kaip efektyviau sujungti kelias grupes, pasakyk mums.
Prie nuorodų pridėsime jūsų metodą.
Ypatingas ačiū Chrisui Nesbittui-Smithui (Chrisas Nesbittas-Smithas) ir Vincentas de Sme (Vincentas De Smetas) (patikimumo inžinierius swatmobile.io) už tai, kad perskaitėte straipsnį ir dalinatės naudinga informacija apie federacijos veiklą.