Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes

Kubs uz kuba, metaklasteri, Ŕūnveida, resursu sadale

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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 Tervejs (3. att.) ir Alibaba Cloud izstrādāts augstas veiktspējas spraudnis konteineru tÄ«kla pārvaldÄ«bai. Tas nodroÅ”ina bagātÄ«gu droŔības politiku kopumu un ļauj izveidot savienojumu ar klientu virtuālajiem privātajiem mākoņiem (VPC), izmantojot Alibaba Cloud Elastic Networking Interface (ENI). Lai efektÄ«vi sadalÄ«tu tÄ«kla resursus starp mezgliem, podiem un pakalpojumiem metaklasterā, mums rÅ«pÄ«gi jāuzrauga to lietojums virtuālo privāto mākoņu metaklasterā. Kad tÄ«kla resursi beidzas, tiek izveidota jauna Ŕūna.

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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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.

Kā Alibaba Cloud pārvalda desmitiem tūkstoŔu Kubernetes klasteru ar... Kubernetes
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

Pievieno komentāru