Kubs uz kuba, metaklasteri, Ŕūnveida, resursu sadale
RÄ«si. 1. Kubernetes ekosistÄma uz Alibaba mÄkoÅa
KopÅ” 2015. gada Alibaba Cloud Container Service for Kubernetes (ACK) ir bijis viens no visstraujÄk augoÅ”ajiem mÄkoÅpakalpojumiem pakalpojumÄ Alibaba Cloud. Tas apkalpo daudzus klientus, kÄ arÄ« atbalsta Alibaba iekÅ”Äjo infrastruktÅ«ru un citus uzÅÄmuma mÄkoÅpakalpojumus.
TÄpat kÄ lÄ«dzÄ«gu konteineru pakalpojumu gadÄ«jumÄ no pasaules klases mÄkoÅpakalpojumu sniedzÄjiem, mÅ«su galvenÄs prioritÄtes ir uzticamÄ«ba un pieejamÄ«ba. TÄpÄc ir izveidota mÄrogojama un globÄli pieejama platforma desmitiem tÅ«kstoÅ”u Kubernetes klasteru.
Å ajÄ rakstÄ mÄs dalÄ«simies pieredzÄ par liela skaita Kubernetes klasteru pÄrvaldÄ«bu mÄkoÅa infrastruktÅ«rÄ, kÄ arÄ« par pamatÄ esoÅ”Äs platformas arhitektÅ«ru.
Ieraksts
Kubernetes ir kļuvis par de facto standartu dažÄdÄm darba slodzÄm mÄkonÄ«. KÄ parÄdÄ«ts attÄlÄ. 1, Kubernetes klasteros tagad darbojas arvien vairÄk Alibaba Cloud lietojumprogrammu: statusa un bezstÄvokļa lietojumprogrammas, kÄ arÄ« lietojumprogrammu pÄrvaldnieki. Kubernetes vadÄ«ba vienmÄr ir bijusi interesanta un nopietna diskusiju tÄma inženieriem, kuri veido un uztur infrastruktÅ«ru. RunÄjot par mÄkoÅa pakalpojumu sniedzÄjiem, piemÄram, Alibaba Cloud, mÄrogoÅ”anas problÄma tiek izvirzÄ«ta priekÅ”plÄnÄ. KÄ pÄrvaldÄ«t Kubernetes klasterus Å”ÄdÄ mÄrogÄ? MÄs jau esam apskatÄ«juÅ”i paraugpraksi milzÄ«gu 10 000 mezglu Kubernetes klasteru pÄrvaldÄ«Å”anai. Protams, Ŕī ir interesanta mÄrogoÅ”anas problÄma. Bet ir arÄ« cita skala: daudzums paÅ”i klasteri.
MÄs esam apsprieduÅ”i Å”o tÄmu ar daudziem ACK lietotÄjiem. LielÄkÄ daļa no viÅiem izvÄlas vadÄ«t desmitiem, ja ne simtiem mazu vai vidÄju Kubernetes klasteru. Tam ir labi iemesli: potenciÄlo bojÄjumu ierobežoÅ”ana, klasteru atdalÄ«Å”ana dažÄdÄm komandÄm, virtuÄlo klasteru izveide testÄÅ”anai. Ja ACK mÄrÄ·is ir apkalpot globÄlu auditoriju ar Å”o lietoÅ”anas modeli, tam ir uzticami un efektÄ«vi jÄpÄrvalda liels skaits klasteru vairÄk nekÄ 20 reÄ£ionos.
RÄ«si. 2. Liela skaita Kubernetes klasteru pÄrvaldÄ«bas problÄmas
KÄdas ir galvenÄs klasteru pÄrvaldÄ«bas problÄmas Å”ÄdÄ mÄrogÄ? KÄ parÄdÄ«ts attÄlÄ, ir jÄrisina Äetras problÄmas:
- HeterogenitÄte
ACK jÄatbalsta dažÄda veida kopas, tostarp standarta, bez servera, Edge, Windows un vairÄkas citas. DažÄdÄm kopÄm ir nepiecieÅ”amas dažÄdas opcijas, komponenti un mitinÄÅ”anas modeļi. Dažiem klientiem ir nepiecieÅ”ama palÄ«dzÄ«ba ar pielÄgoÅ”anu viÅu konkrÄtajiem gadÄ«jumiem.
- DažÄdi klasteru izmÄri
Klasteru izmÄri ir dažÄdi, sÄkot no pÄris mezgliem ar dažiem pÄkstiem lÄ«dz desmitiem tÅ«kstoÅ”u mezglu ar tÅ«kstoÅ”iem pÄkstÄ«m. ArÄ« resursu prasÄ«bas ir ļoti atŔķirÄ«gas. Nepareiza resursu pieŔķirÅ”ana var ietekmÄt veiktspÄju vai pat izraisÄ«t kļūmi.
- DažÄdas versijas
Kubernetes attÄ«stÄs ļoti Ätri. Jaunas versijas tiek izlaistas ik pÄc dažiem mÄneÅ”iem. Klienti vienmÄr ir gatavi izmÄÄ£inÄt jaunas funkcijas. TÄpÄc viÅi vÄlas uzlikt testa slodzi jaunajÄm Kubernetes versijÄm un ražoÅ”anas slodzi uz stabilajÄm. Lai izpildÄ«tu Å”o prasÄ«bu, ACK klientiem pastÄvÄ«gi jÄpiegÄdÄ jaunas Kubernetes versijas, vienlaikus saglabÄjot stabilas versijas.
- DroŔības atbilstība
Klasteri ir sadalÄ«ti dažÄdos reÄ£ionos. Tiem ir jÄatbilst dažÄdÄm droŔības prasÄ«bÄm un oficiÄlajiem noteikumiem. PiemÄram, klasterim EiropÄ ir jÄbÅ«t saderÄ«gam ar GDPR, savukÄrt finanÅ”u mÄkonim ĶīnÄ ir jÄbÅ«t papildu aizsardzÄ«bas slÄÅiem. Å Ä«s prasÄ«bas ir obligÄtas, un nav pieļaujams tÄs ignorÄt, jo tas rada milzÄ«gus riskus mÄkoÅa platformas klientiem.
ACK platforma ir paredzÄta, lai atrisinÄtu lielÄko daļu iepriekÅ” minÄto problÄmu. Å obrÄ«d tas droÅ”i un stabili pÄrvalda vairÄk nekÄ 10 tÅ«kstoÅ”us Kubernetes klasteru visÄ pasaulÄ. ApskatÄ«sim, kÄ tas tika sasniegts, tostarp izmantojot vairÄkus galvenos dizaina/arhitektÅ«ras principus.
Dizains
Kubs uz kuba un Ŕūnveida
AtŔķirÄ«bÄ no centralizÄtas hierarhijas, uz ŔūnÄm balstÄ«ta arhitektÅ«ra parasti tiek izmantota, lai paplaÅ”inÄtu platformu Ärpus viena datu centra vai paplaÅ”inÄtu avÄrijas atkopÅ”anas jomu.
Katrs Alibaba mÄkoÅa reÄ£ions sastÄv no vairÄkÄm zonÄm (AZ) un parasti atbilst noteiktam datu centram. LielÄ reÄ£ionÄ (piemÄram, Huandžou) bieži vien ir tÅ«kstoÅ”iem Kubernetes klientu kopu, kurÄs darbojas ACK.
ACK pÄrvalda Å”os Kubernetes klasterus, izmantojot paÅ”u Kubernetes, kas nozÄ«mÄ, ka mums ir Kubernetes metaklasteris, kas darbojas, lai pÄrvaldÄ«tu klienta Kubernetes klasterus. Å o arhitektÅ«ru sauc arÄ« par ākube-on-kubeā (KoK). KoK arhitektÅ«ra vienkÄrÅ”o klientu klasteru pÄrvaldÄ«bu, jo klasteru izvietoÅ”ana ir vienkÄrÅ”a un deterministiska. VÄl svarÄ«gÄk ir tas, ka mÄs varam atkÄrtoti izmantot vietÄjÄs Kubernetes funkcijas. PiemÄram, API serveru pÄrvaldÄ«ba, izmantojot izvietoÅ”anu, operatora etcd izmantoÅ”ana, lai pÄrvaldÄ«tu vairÄkus etcd. Å Äda rekursija vienmÄr sagÄdÄ Ä«paÅ”u prieku.
VienÄ reÄ£ionÄ tiek izvietoti vairÄki Kubernetes metaklasteri atkarÄ«bÄ no klientu skaita. MÄs tos saucam par ŔūnÄm. Lai aizsargÄtu pret visas zonas atteici, ACK atbalsta vairÄku aktÄ«vu izvietoÅ”anu vienÄ reÄ£ionÄ: metaklasteris sadala Kubernetes klientu klastera galvenÄs sastÄvdaļas vairÄkÄs zonÄs un palaiž tÄs vienlaicÄ«gi, tas ir, vairÄku aktÄ«vÄ režīmÄ. Lai nodroÅ”inÄtu galvenÄ uzticamÄ«bu un efektivitÄti, ACK optimizÄ komponentu izvietojumu un nodroÅ”ina, ka API serveris un etcd atrodas tuvu viens otram.
Å is modelis ļauj efektÄ«vi, elastÄ«gi un uzticami pÄrvaldÄ«t Kubernetes.
Metaksteru resursu plÄnoÅ”ana
KÄ jau minÄjÄm, metaklasteru skaits katrÄ reÄ£ionÄ ir atkarÄ«gs no klientu skaita. Bet kurÄ brÄ«dÄ« pievienot jaunu metaklasteri? TÄ ir tipiska resursu plÄnoÅ”anas problÄma. Parasti ir pieÅemts izveidot jaunu, kad esoÅ”ie metaklasteri ir izsmÄluÅ”i visus savus resursus.
Å
emsim, piemÄram, tÄ«kla resursus. KoK arhitektÅ«rÄ Kubernetes komponenti no klientu klasteriem tiek izvietoti kÄ podi metaklasterÄ. MÄs izmantojam
Lai noteiktu optimÄlo klientu klasteru skaitu katrÄ metaklasterÄ, mÄs Åemam vÄrÄ arÄ« mÅ«su izmaksas, blÄ«vuma prasÄ«bas, resursu kvotu, uzticamÄ«bas prasÄ«bas un statistiku. Pamatojoties uz visu Å”o informÄciju, tiek pieÅemts lÄmums izveidot jaunu metaklasteri. LÅ«dzu, Åemiet vÄrÄ, ka mazie klasteri nÄkotnÄ var ievÄrojami paplaÅ”inÄties, tÄpÄc resursu patÄriÅÅ” palielinÄs pat tad, ja klasteru skaits paliek nemainÄ«gs. MÄs parasti atstÄjam pietiekami daudz brÄ«vas vietas, lai katrs klasteris varÄtu augt.
Rīsi. 3. Terway tīkla arhitektūra
VedÅa komponentu mÄrogoÅ”ana klientu klasteros
VedÅa komponentiem ir dažÄdas resursu vajadzÄ«bas. Tie ir atkarÄ«gi no mezglu un podziÅu skaita klasterÄ«, nestandarta kontrolleru/operatoru skaita, kas mijiedarbojas ar APIServer.
ProgrammÄ ACK katrs Kubernetes klientu klasteris atŔķiras pÄc lieluma un izpildlaika prasÄ«bÄm. VedÅa komponentu ievietoÅ”anai nav universÄlas konfigurÄcijas. Ja mÄs kļūdaini noteiksim zemu resursu limitu lielam klientam, tad tÄ klasteris nespÄs tikt galÄ ar slodzi. Ja iestatÄ«sit konservatÄ«vi augstu ierobežojumu visÄm kopÄm, resursi tiks izŔķiesti.
Lai atrastu smalku kompromisu starp uzticamÄ«bu un izmaksÄm, ACK izmanto tipa sistÄmu. Proti, mÄs definÄjam trÄ«s veidu klasterus: mazos, vidÄjos un lielos. Katram veidam ir atseviŔķs resursu pieŔķirÅ”anas profils. Veids tiek noteikts, pamatojoties uz vedÅa komponentu slodzi, mezglu skaitu un citiem faktoriem. Klastera veids laika gaitÄ var mainÄ«ties. ACK nepÄrtraukti uzrauga Å”os faktorus un var attiecÄ«gi palielinÄt/uz leju. Kad klastera veids ir mainÄ«ts, resursu pieŔķirÅ”ana tiek automÄtiski atjauninÄta ar minimÄlu lietotÄja iejaukÅ”anos.
MÄs strÄdÄjam, lai uzlabotu Å”o sistÄmu, izmantojot precÄ«zÄku mÄrogoÅ”anu un precÄ«zÄku tipa atjauninÄÅ”anu, lai Ŕīs izmaiÅas notiktu vienmÄrÄ«gÄk un ekonomiski izdevÄ«gÄk.
RÄ«si. 4. InteliÄ£enta daudzpakÄpju tipa pÄrslÄgÅ”ana
Klientu klasteru evolÅ«cija mÄrogÄ
IepriekÅ”ÄjÄs sadaļÄs tika apskatÄ«ti daži liela skaita Kubernetes klasteru pÄrvaldÄ«bas aspekti. TomÄr ir vÄl viena problÄma, kas jÄatrisina: klasteru evolÅ«cija.
Kubernetes ir mÄkoÅu pasaules āLinuxā. Tas tiek pastÄvÄ«gi atjauninÄts un kļūst modulÄrÄks. Mums pastÄvÄ«gi jÄpiegÄdÄ klientiem jaunas versijas, jÄnovÄrÅ” ievainojamÄ«bas un jÄatjaunina esoÅ”ie klasteri, kÄ arÄ« jÄpÄrvalda liels skaits saistÄ«to komponentu (CSI, CNI, Device Plugin, Scheduler Plugin un daudzi citi).
KÄ piemÄru Åemsim Kubernetes komponentu pÄrvaldÄ«bu. SÄkumÄ mÄs izstrÄdÄjÄm centralizÄtu sistÄmu visu Å”o savienoto komponentu reÄ£istrÄÅ”anai un pÄrvaldÄ«bai.
RÄ«si. 5. ElastÄ«gas un pievienojamas sastÄvdaļas
Pirms turpinÄt, jums jÄpÄrliecinÄs, vai atjauninÄÅ”ana bija veiksmÄ«ga. Lai to izdarÄ«tu, esam izstrÄdÄjuÅ”i sistÄmu komponentu funkcionalitÄtes pÄrbaudei. PÄrbaude tiek veikta pirms un pÄc atjauninÄÅ”anas.
RÄ«si. 6. Klastera komponentu iepriekÅ”Äja pÄrbaude
Lai Ätri un droÅ”i atjauninÄtu Å”os komponentus, nepÄrtrauktas izvietoÅ”anas sistÄma darbojas ar atbalstu daļÄjai attÄ«stÄ«bai (pelÄktoÅu), pauzÄm un citÄm funkcijÄm. Standarta Kubernetes kontrolieri nav labi piemÄroti Å”im lietoÅ”anas gadÄ«jumam. TÄpÄc, lai pÄrvaldÄ«tu klasteru komponentus, esam izstrÄdÄjuÅ”i specializÄtu kontrolieru komplektu, tostarp spraudni un papildu vadÄ«bas moduli (blakusvÄÄ£a vadÄ«ba).
PiemÄram, BroadcastJob kontrolleris ir paredzÄts, lai atjauninÄtu komponentus katrÄ darbinieka maŔīnÄ vai pÄrbaudÄ«tu mezglus katrÄ maŔīnÄ. Apraides darbs katrÄ klastera mezglÄ palaiž podziÅu, piemÄram, DaemonSet. TomÄr DaemonSet vienmÄr ilgstoÅ”i uztur podziÅu, kamÄr BroadcastJob to sakļauj. Apraides kontrolleris arÄ« palaiž apvidus tikko pievienotajos mezglos un inicializÄ mezglus ar nepiecieÅ”amajiem komponentiem. 2019. gada jÅ«nijÄ atvÄrÄm OpenKruise automatizÄcijas dzinÄja pirmkodu, ko paÅ”i izmantojam uzÅÄmuma ietvaros.
RÄ«si. 7. OpenKurise organizÄ Broadcast uzdevuma izpildi visos mezglos
Lai palÄ«dzÄtu klientiem izvÄlÄties pareizÄs klasteru konfigurÄcijas, mÄs piedÄvÄjam arÄ« iepriekÅ” definÄtu profilu kopu, tostarp bez servera, Edge, Windows un Bare Metal profilus. PaplaÅ”inoties ainavai un pieaugot mÅ«su klientu vajadzÄ«bÄm, mÄs pievienosim vairÄk profilu, lai vienkÄrÅ”otu nogurdinoÅ”o iestatÄ«Å”anas procesu.
RÄ«si. 8. Uzlaboti un elastÄ«gi klasteru profili dažÄdiem scenÄrijiem
GlobÄla novÄrojamÄ«ba datu centros
KÄ parÄdÄ«ts zemÄk attÄlÄ. 9, Alibaba Cloud Container mÄkoÅpakalpojums ir izvietots divdesmit reÄ£ionos visÄ pasaulÄ. Å emot vÄrÄ Å”o mÄrogu, viens no galvenajiem ACK mÄrÄ·iem ir viegli pÄrraudzÄ«t darbÄ«go klasteru stÄvokli, lai, ja klientu klasteris saskaras ar problÄmu, mÄs varÄtu Ätri reaÄ£Ät uz situÄciju. Citiem vÄrdiem sakot, jums ir jÄnÄk klajÄ ar risinÄjumu, kas ļaus efektÄ«vi un droÅ”i apkopot statistiku reÄllaikÄ no klientu klasteriem visos reÄ£ionos un vizuÄli prezentÄt rezultÄtus.
RÄ«si. 9. Alibaba Cloud Container pakalpojuma globÄla izvietoÅ”ana divdesmit reÄ£ionos
TÄpat kÄ daudzas Kubernetes uzraudzÄ«bas sistÄmas, mÄs kÄ galveno rÄ«ku izmantojam Prometheus. Katram metaklasterim Prometheus aÄ£enti apkopo Å”Ädus rÄdÄ«tÄjus:
- OS metrika, piemÄram, resursdatora resursi (CPU, atmiÅa, disks utt.) un tÄ«kla joslas platums.
- Metrikas metaklasteru un klientu klasteru pÄrvaldÄ«bas sistÄmai, piemÄram, kube-apiserver, kube-controller-manager un kube-plÄnotÄjs.
- Metrika no kubernetes-state-metrics un cadvisor.
- etcd metrika, piemÄram, diska rakstÄ«Å”anas laiks, datu bÄzes lielums, savienojumu caurlaidspÄja starp mezgliem utt.
GlobÄlÄ statistika tiek vÄkta, izmantojot tipisku daudzslÄÅu apkopoÅ”anas modeli. Monitoringa dati no katra metaklastera vispirms tiek apkopoti katrÄ reÄ£ionÄ un pÄc tam tiek nosÅ«tÄ«ti uz centrÄlo serveri, kas parÄda kopÄjo ainu. Viss darbojas caur federÄcijas mehÄnismu. Prometheus serveris katrÄ datu centrÄ apkopo metriku no Ŕī datu centra, un centrÄlais Prometheus serveris ir atbildÄ«gs par uzraudzÄ«bas datu apkopoÅ”anu. AlertManager savienojas ar centrÄlo Prometheus un, ja nepiecieÅ”ams, nosÅ«ta brÄ«dinÄjumus, izmantojot DingTalk, e-pastu, SMS utt. VizualizÄcija - izmantojot Grafana.
10. attÄlÄ uzraudzÄ«bas sistÄmu var iedalÄ«t trÄ«s lÄ«meÅos:
- Robežas līmenis
SlÄnis, kas atrodas vistÄlÄk no centra. Prometheus Edge Server darbojas katrÄ metaklasterÄ, savÄcot metriku no meta un klientu klasteriem tajÄ paÅ”Ä tÄ«kla domÄnÄ.
- KaskÄdes lÄ«menis
Prometheus kaskÄdes slÄÅa funkcija ir vÄkt monitoringa datus no vairÄkiem reÄ£ioniem. Å ie serveri darbojas lielÄku Ä£eogrÄfisko vienÄ«bu lÄ«menÄ«, piemÄram, Ķīna, Äzija, Eiropa un Amerika. Klasteriem augot, reÄ£ionu var sadalÄ«t, un tad katrÄ jaunajÄ lielajÄ reÄ£ionÄ parÄdÄ«sies kaskÄdes lÄ«meÅa Prometheus serveris. Izmantojot Å”o stratÄÄ£iju, varat netraucÄti mÄrogot pÄc vajadzÄ«bas.
- CentrÄlais lÄ«menis
CentrÄlais Prometheus serveris savienojas ar visiem kaskÄdes serveriem un veic galÄ«go datu apkopoÅ”anu. UzticamÄ«bas labad divas centrÄlÄs Prometheus instances tika izveidotas dažÄdÄs zonÄs, savienotas ar vieniem un tiem paÅ”iem kaskÄdes serveriem.
RÄ«si. 10. GlobÄlÄ daudzlÄ«meÅu uzraudzÄ«bas arhitektÅ«ra, kuras pamatÄ ir Prometheus federÄcijas mehÄnisms
Kopsavilkums
Uz Kubernetes balstÄ«ti mÄkoÅa risinÄjumi turpina pÄrveidot mÅ«su nozari. Alibaba Cloud konteinera pakalpojums nodroÅ”ina droÅ”u, uzticamu un augstas veiktspÄjas mitinÄÅ”anu - tas ir viens no labÄkajiem Kubernetes mÄkoÅa mitinÄÅ”anas pakalpojumiem. Alibaba Cloud komanda stingri tic atvÄrtÄ pirmkoda un atvÄrtÄ pirmkoda kopienas principiem. Noteikti turpinÄsim dalÄ«ties ar savÄm zinÄÅ”anÄm mÄkoÅtehnoloÄ£iju darbÄ«bas un pÄrvaldÄ«bas jomÄ.
Avots: www.habr.com