Kubas ant kubo, metaklasteriai, koriai, išteklių paskirstymas

Ryžiai. 1. Kubernetes ekosistema Alibaba debesyje

Nuo 2015 m. „Alibaba Cloud Container Service for Kubernetes“ (ACK) yra viena greičiausiai augančių debesies paslaugų „Alibaba Cloud“. Jis aptarnauja daugybę klientų, taip pat palaiko vidinę „Alibaba“ infrastruktūrą ir kitas bendrovės debesijos paslaugas.

Kaip ir teikiant panašias pasaulinio lygio debesijos paslaugų teikėjų konteinerių paslaugas, mūsų pagrindiniai prioritetai yra patikimumas ir pasiekiamumas. Todėl dešimčiai tūkstančių „Kubernetes“ grupių buvo sukurta keičiamo dydžio ir visame pasaulyje prieinama platforma.

Šiame straipsnyje mes pasidalinsime savo patirtimi, kaip valdyti daugybę Kubernetes klasterių debesų infrastruktūroje, taip pat pagrindinės platformos architektūrą.

Įrašas

„Kubernetes“ tapo de facto standartu įvairiems darbo krūviams debesyje. Kaip parodyta pav. 1 aukščiau, vis daugiau Alibaba Cloud programų dabar veikia Kubernetes klasteriuose: būsenos ir be būsenos programos, taip pat programų tvarkyklės. „Kubernetes“ valdymas visada buvo įdomi ir rimta infrastruktūrą kuriančių ir prižiūrinčių inžinierių diskusijų tema. Kalbant apie debesų tiekėjus, tokius kaip „Alibaba Cloud“, iškyla mastelio keitimo problema. Kaip valdyti tokio masto „Kubernetes“ grupes? Jau aptarėme geriausios praktikos pavyzdžius, kaip valdyti didžiulius 10 000 mazgų „Kubernetes“ grupes. Žinoma, tai įdomi mastelio keitimo problema. Tačiau yra ir kita skalė: kiekis pačių klasterių.

Šią temą aptarėme su daugeliu ACK vartotojų. Dauguma jų pasirenka paleisti dešimtis, jei ne šimtus, mažų ar vidutinio dydžio „Kubernetes“ grupių. Tam yra rimtų priežasčių: galimos žalos ribojimas, skirtingų komandų grupių atskyrimas, virtualių grupių kūrimas bandymams. Jei ACK siekia aptarnauti pasaulinę auditoriją naudodama šį naudojimo modelį, ji turi patikimai ir efektyviai valdyti daugybę grupių daugiau nei 20 regionų.

Ryžiai. 2. Daugelio Kubernetes klasterių valdymo problemos

Kokie yra pagrindiniai tokio masto klasterių valdymo iššūkiai? Kaip parodyta paveikslėlyje, reikia išspręsti keturias problemas:

• Heterogeniškumas

ACK turėtų palaikyti įvairių tipų grupes, įskaitant standartines, be serverio, Edge, Windows ir keletą kitų. Skirtingoms grupėms reikia skirtingų parinkčių, komponentų ir prieglobos modelių. Kai kuriems klientams reikia pagalbos pritaikant jų konkrečiais atvejais.

• Įvairių dydžių klasterių

Klasteriai skiriasi dydžiu: nuo kelių mazgų su keliomis ankštimis iki dešimčių tūkstančių mazgų su tūkstančiais ankščių. Išteklių reikalavimai taip pat labai skiriasi. Netinkamas išteklių paskirstymas gali turėti įtakos našumui ar net sukelti gedimų.

• Įvairios versijos

„Kubernetes“ vystosi labai greitai. Naujos versijos išleidžiamos kas kelis mėnesius. Klientai visada nori išbandyti naujas funkcijas. Taigi bandomąją apkrovą jie nori skirti naujoms „Kubernetes“ versijoms, o gamybos apkrovą – stabilioms. Kad atitiktų šį reikalavimą, ACK klientams turi nuolat teikti naujas Kubernetes versijas, išlaikydamas stabilias versijas.

• Saugumo laikymasis

Klasteriai yra paskirstyti skirtinguose regionuose. Todėl jie turi atitikti įvairius saugos reikalavimus ir oficialius reglamentus. Pavyzdžiui, Europoje esantis klasteris turi atitikti GDPR, o finansinis debesis Kinijoje turi turėti papildomų apsaugos lygių. Šie reikalavimai yra privalomi ir jų nepaisyti nepriimtina, nes tai kelia didžiulę riziką debesų platformos klientams.

ACK platforma skirta daugeliui minėtų problemų išspręsti. Šiuo metu ji patikimai ir stabiliai valdo daugiau nei 10 tūkstančių Kubernetes klasterių visame pasaulyje. Pažiūrėkime, kaip tai buvo pasiekta, įskaitant keletą pagrindinių projektavimo / architektūros principų.

Dizainas

Kubas ant kubo ir korio

Skirtingai nuo centralizuotos hierarchijos, ląstelių architektūra paprastai naudojama platformai išplėsti už vieno duomenų centro arba išplėsti atkūrimo po nelaimių apimtį.

Kiekvienas Alibaba Cloud regionas susideda iš kelių zonų (AZ) ir paprastai atitinka konkretų duomenų centrą. Dideliame regione (pvz., Huangdžou) dažnai yra tūkstančiai Kubernetes klientų grupių, kuriose veikia ACK.

ACK valdo šias „Kubernetes“ grupes naudodamas patį „Kubernetes“, o tai reiškia, kad turime „Kubernetes“ metaklasterį, skirtą valdyti kliento „Kubernetes“ grupes. Ši architektūra taip pat vadinama „kube-on-kube“ (KoK). KoK architektūra supaprastina klientų grupių valdymą, nes klasterių diegimas yra paprastas ir deterministinis. Dar svarbiau, kad galime pakartotinai naudoti vietines „Kubernetes“ funkcijas. Pavyzdžiui, valdyti API serverius per diegimą, naudojant operatorių etcd, norint valdyti kelis etcd. Toks pasikartojimas visada teikia ypatingą malonumą.

Viename regione, atsižvelgiant į klientų skaičių, yra įdiegtos kelios Kubernetes metaklasteriai. Šiuos metaklasterius vadiname ląstelėmis. Siekdama apsisaugoti nuo visos zonos gedimo, ACK palaiko daugiafunkcinį diegimą viename regione: metaklasteris paskirsto Kubernetes klientų klasterio pagrindinius komponentus keliose zonose ir paleidžia juos vienu metu, ty kelių aktyviu režimu. Siekdama užtikrinti pagrindinio įrenginio patikimumą ir efektyvumą, ACK optimizuoja komponentų išdėstymą ir užtikrina, kad API serveris ir etcd būtų arti vienas kito.

Šis modelis leidžia efektyviai, lanksčiai ir patikimai valdyti Kubernetes.

Metaksterių išteklių planavimas

Kaip jau minėjome, metaklasterių skaičius kiekviename regione priklauso nuo klientų skaičiaus. Bet kada pridėti naują metaklasterį? Tai tipiška išteklių planavimo problema. Paprastai įprasta sukurti naują, kai esami metaklasteriai išnaudojo visus savo išteklius.

Paimkime, pavyzdžiui, tinklo išteklius. KoK architektūroje Kubernetes komponentai iš klientų grupių yra diegiami kaip pods metaklasteryje. Mes naudojame Terway (3 pav.) – tai Alibaba Cloud sukurtas didelio našumo įskiepis, skirtas konteinerių tinklo valdymui. Tai suteikia daugybę saugos strategijų ir leidžia prisijungti prie klientų virtualių privačių debesų (VPC) per Alibaba Cloud Elastic Networking Interface (ENI). Norėdami efektyviai paskirstyti tinklo išteklius tarp mazgų, blokų ir paslaugų metaklasteryje, turime atidžiai stebėti jų naudojimą virtualių privačių debesų metaklasteryje. Kai baigiasi tinklo ištekliai, sukuriama nauja ląstelė.

Norėdami nustatyti optimalų klientų grupių skaičių kiekviename metaklasteryje, taip pat atsižvelgiame į savo išlaidas, tankio reikalavimus, išteklių kvotą, patikimumo reikalavimus ir statistiką. Sprendimas sukurti naują metaklasterį priimamas remiantis visa šia informacija. Atkreipkite dėmesį, kad maži klasteriai ateityje gali labai plėstis, todėl išteklių suvartojimas didėja, net jei klasterių skaičius nesikeičia. Paprastai paliekame pakankamai laisvos vietos kiekvienai klasteriui augti.

Ryžiai. 3. Terway tinklo architektūra

Mastelio keitimo vedlio komponentai klientų grupėse

Vedlio komponentai turi skirtingus išteklių poreikius. Jie priklauso nuo mazgų ir podų skaičiaus klasteryje, nestandartinių valdiklių/operatorių, sąveikaujančių su APIServer, skaičiaus.

ACK kiekvienas Kubernetes klientų klasteris skiriasi dydžiu ir vykdymo laiko reikalavimais. Nėra universalios konfigūracijos vedlio komponentams įdėti. Jei dideliam klientui klaidingai nustatysime žemą išteklių limitą, tada jo klasteris negalės susidoroti su apkrova. Jei nustatysite konservatyviai aukštą ribą visoms grupėms, ištekliai bus švaistomi.

Norėdami rasti subtilų kompromisą tarp patikimumo ir kainos, ACK naudoja tipo sistemą. Būtent, mes apibrėžiame tris klasterių tipus: mažus, vidutinius ir didelius. Kiekvienas tipas turi atskirą išteklių paskirstymo profilį. Tipas nustatomas pagal vedlio komponentų apkrovą, mazgų skaičių ir kitus veiksnius. Klasterio tipas laikui bėgant gali keistis. ACK nuolat stebi šiuos veiksnius ir atitinkamai gali įvesti aukštyn / žemyn. Pakeitus klasterio tipą, išteklių paskirstymas atnaujinamas automatiškai su minimaliu vartotojo įsikišimu.

Stengiamės patobulinti šią sistemą, taikydami smulkesnį mastelį ir tikslesnius tipo atnaujinimus, kad šie pakeitimai vyktų sklandžiau ir būtų ekonomiškesni.

Ryžiai. 4. Sumanus kelių pakopų tipo perjungimas

Klientų grupių evoliucija mastu

Ankstesniuose skyriuose buvo aptariami kai kurie didelio Kubernetes klasterių skaičiaus valdymo aspektai. Tačiau yra ir kita problema, kurią reikia išspręsti – tai klasterių evoliucija.

Kubernetes yra debesų pasaulio „Linux“. Jis nuolat atnaujinamas ir tampa labiau modulinis. Privalome nuolat teikti naujas versijas savo klientams, taisyti spragas ir atnaujinti esamas grupes, taip pat valdyti daugybę susijusių komponentų (CSI, CNI, Device Plugin, Scheduler Plugin ir daugelis kitų).

Paimkime Kubernetes komponentų valdymą kaip pavyzdį. Pirmiausia sukūrėme centralizuotą visų šių prijungtų komponentų registravimo ir valdymo sistemą.

Ryžiai. 5. Lankstūs ir prijungiami komponentai

Prieš tęsdami, turite įsitikinti, kad atnaujinimas buvo sėkmingas. Tam sukūrėme komponentų funkcionalumo tikrinimo sistemą. Patikra atliekama prieš ir po atnaujinimo.

Ryžiai. 6. Preliminarus klasterio komponentų patikrinimas

Norint greitai ir patikimai atnaujinti šiuos komponentus, nuolatinio diegimo sistema veikia su dalinio patobulinimo (pilkos tonų), pauzių ir kitų funkcijų palaikymu. Standartiniai Kubernetes valdikliai nėra tinkami šiam naudojimo atvejui. Todėl, norėdami valdyti klasterio komponentus, sukūrėme specializuotų valdiklių rinkinį, įskaitant papildinį ir pagalbinį valdymo modulį (šoninės priekabos valdymas).

Pavyzdžiui, „BroadcastJob“ valdiklis skirtas atnaujinti kiekvieno darbuotojo įrenginio komponentus arba patikrinti kiekvieno įrenginio mazgus. Transliavimo užduotis kiekviename klasterio mazge paleidžia pogrupį, kaip „DaemonSet“. Tačiau „DaemonSet“ visada palaiko podėlį ilgą laiką, o „BroadcastJob“ jį sutraukia. „Broadcast“ valdiklis taip pat paleidžia blokus naujai sujungtuose mazguose ir inicijuoja mazgus su reikalingais komponentais. 2019 metų birželį atidarėme OpenKruise automatizavimo variklio šaltinio kodą, kurį patys naudojame įmonėje.

Ryžiai. 7. OpenKurise organizuoja transliacijos užduoties vykdymą visuose mazguose

Siekdami padėti klientams pasirinkti tinkamas klasterio konfigūracijas, taip pat pateikiame iš anksto nustatytų profilių rinkinį, įskaitant be serverio, „Edge“, „Windows“ ir „Bare Metal“ profilius. Plečiantis kraštovaizdžiui ir augant klientų poreikiams, pridėsime daugiau profilių, kad supaprastintume varginantį sąrankos procesą.

Ryžiai. 8. Pažangūs ir lankstūs klasterių profiliai įvairiems scenarijams

Visuotinis stebėjimas duomenų centruose

Kaip parodyta žemiau esančiame pav. 9, „Alibaba Cloud Container“ debesies paslauga buvo įdiegta dvidešimtyje pasaulio regionų. Atsižvelgiant į šį mastą, vienas iš pagrindinių ACK tikslų yra lengvai stebėti veikiančių klasterių būseną, kad, jei klientų klasteris susiduria su problema, galėtume greitai reaguoti į situaciją. Kitaip tariant, reikia sugalvoti sprendimą, kuris leistų efektyviai ir saugiai rinkti statistiką realiu laiku iš klientų grupių visuose regionuose – ir vizualiai pateikti rezultatus.

Ryžiai. 9. Pasaulinis Alibaba Cloud Container paslaugos diegimas dvidešimtyje regionų

Kaip ir daugelis Kubernetes stebėjimo sistemų, kaip pagrindinį įrankį naudojame Prometheus. Kiekvienam metaklasteriui „Prometheus“ agentai renka šią metriką:

• OS metrika, pvz., pagrindinio kompiuterio ištekliai (CPU, atmintis, diskas ir kt.) ir tinklo pralaidumas.
• Metaklasterio ir klientų grupių valdymo sistemos metrika, pvz., kube-apiserver, kube-controller-manager ir kube-scheduler.
• Metrika iš kubernetes-state-metrics ir cadvisor.
• etcd metrikos, tokios kaip disko įrašymo laikas, duomenų bazės dydis, nuorodų tarp mazgų pralaidumas ir kt.

Pasaulinė statistika renkama naudojant tipinį daugiasluoksnį agregavimo modelį. Stebėjimo duomenys iš kiekvieno metaklasterio pirmiausia sujungiami kiekviename regione ir siunčiami į centrinį serverį, kuriame rodomas bendras vaizdas. Viskas veikia per federacijos mechanizmą. Prometheus serveris kiekviename duomenų centre renka metrikas iš to duomenų centro, o centrinis Prometheus serveris yra atsakingas už stebėjimo duomenų kaupimą. AlertManager prisijungia prie centrinio Prometheus ir prireikus siunčia įspėjimus per DingTalk, el. paštą, SMS ir tt Vizualizacija – naudojant Grafana.

10 paveiksle stebėjimo sistemą galima suskirstyti į tris lygius:

• Ribinis lygis

Sluoksnis toliausiai nuo centro. Prometheus Edge Server veikia kiekviename metaklasteryje, renka metriką iš meta ir klientų grupių tame pačiame tinklo domene.

• Kaskados lygis

Prometheus kaskados sluoksnio funkcija yra rinkti stebėjimo duomenis iš kelių regionų. Šie serveriai veikia didesnių geografinių vienetų, tokių kaip Kinija, Azija, Europa ir Amerika, lygiu. Klasteriams augant, regionas gali būti padalintas, o tada kiekviename naujame dideliame regione atsiras kaskados lygio Prometheus serveris. Naudodami šią strategiją galite sklandžiai keisti mastelį pagal poreikį.

• Centrinis lygis

Centrinis Prometheus serveris prisijungia prie visų kaskadinių serverių ir atlieka galutinį duomenų agregavimą. Dėl patikimumo skirtingose ​​zonose buvo iškelti du centriniai Prometheus egzemplioriai, prijungti prie tų pačių kaskadinių serverių.

Ryžiai. 10. Pasaulinė kelių lygių stebėjimo architektūra, pagrįsta Prometheus federacijos mechanizmu

Santrauka

„Kubernetes“ debesies sprendimai ir toliau keičia mūsų pramonę. „Alibaba Cloud“ konteinerių paslauga užtikrina saugų, patikimą ir didelio našumo prieglobą – tai vienas geriausių „Kubernetes“ debesies prieglobos paslaugų. „Alibaba Cloud“ komanda tvirtai tiki atvirojo kodo ir atvirojo kodo bendruomenės principais. Tikrai ir toliau dalinsimės žiniomis debesų technologijų eksploatavimo ir valdymo srityje.

Šaltinis: www.habr.com