Kocka na kocki, metagruče, satovje, porazdelitev virov

riž. 1. Ekosistem Kubernetes v oblaku Alibaba

Od leta 2015 je storitev Alibaba Cloud Container za Kubernetes (ACK) ena najhitreje rastočih storitev v oblaku v oblaku Alibaba. Služi številnim strankam in podpira tudi notranjo infrastrukturo Alibabe in druge storitve v oblaku podjetja.

Tako kot pri podobnih vsebniških storitvah vrhunskih ponudnikov oblakov sta naši glavni prednostni nalogi zanesljivost in razpoložljivost. Zato je bila ustvarjena razširljiva in globalno dostopna platforma za več deset tisoč gruč Kubernetes.

V tem članku bomo delili naše izkušnje z upravljanjem velikega števila gruč Kubernetes na infrastrukturi v oblaku, pa tudi o arhitekturi osnovne platforme.

Začetek

Kubernetes je postal de facto standard za različne delovne obremenitve v oblaku. Kot je prikazano na sl. 1 zgoraj, vedno več aplikacij Alibaba Cloud se zdaj izvaja v gručah Kubernetes: aplikacije s stanjem in brez stanja ter upravitelji aplikacij. Upravljanje Kubernetesa je bilo vedno zanimiva in resna tema za razpravo inženirjev, ki gradijo in vzdržujejo infrastrukturo. Ko gre za ponudnike oblakov, kot je Alibaba Cloud, pride v ospredje vprašanje skaliranja. Kako upravljati gruče Kubernetes v tem obsegu? Zajeli smo že najboljše prakse za upravljanje ogromnih gruč Kubernetes z 10 vozlišči. Seveda je to zanimiv problem skaliranja. Obstaja pa še ena lestvica: količina sami grozdi.

O tej temi smo razpravljali s številnimi uporabniki ACK. Večina se jih odloči za zagon na desetine, če ne na stotine, majhnih ali srednje velikih gruč Kubernetes. Za to obstajajo dobri razlogi: omejevanje potencialne škode, ločevanje grozdov za različne ekipe, ustvarjanje virtualnih grozdov za testiranje. Če želi ACK s tem modelom uporabe služiti globalnemu občinstvu, mora zanesljivo in učinkovito upravljati veliko število gruč v več kot 20 regijah.

riž. 2. Težave pri upravljanju velikega števila gruč Kubernetes

Kateri so glavni izzivi upravljanja grozdov v tem obsegu? Kot je prikazano na sliki, je treba obravnavati štiri težave:

• Heterogenost

ACK bi moral podpirati različne vrste gruč, vključno s standardnimi, brezstrežniškimi, Edge, Windows in nekaterimi drugimi. Različni grozdi zahtevajo različne možnosti, komponente in modele gostovanja. Nekatere stranke potrebujejo pomoč pri prilagajanju za svoje posebne primere.

• Različne velikosti grozdov

Grozdi se razlikujejo po velikosti: od nekaj vozlišč z več podi do več deset tisoč vozlišč s tisoči podov. Tudi zahteve po virih so zelo različne. Nepravilna dodelitev virov lahko vpliva na zmogljivost ali celo povzroči okvaro.

• Različne različice

Kubernetes se zelo hitro razvija. Nove različice se izdajo vsakih nekaj mesecev. Stranke so vedno pripravljene preizkusiti nove funkcije. Zato želijo preskusno obremenitev naložiti na nove različice Kubernetesa, proizvodno obremenitev pa na stabilne. Da bi izpolnil to zahtevo, mora ACK strankam nenehno dostavljati nove različice Kubernetesa, hkrati pa ohranjati stabilne različice.

• Varnostna skladnost

Grozdi so razporejeni po različnih regijah. Kot taki morajo izpolnjevati različne varnostne zahteve in uradne predpise. Na primer, grozd v Evropi mora biti skladen z GDPR, medtem ko mora imeti finančni oblak na Kitajskem dodatne plasti zaščite. Te zahteve so obvezne in jih je nesprejemljivo zanemariti, saj to ustvarja velika tveganja za stranke platforme v oblaku.

Platforma ACK je zasnovana za reševanje večine zgornjih težav. Trenutno zanesljivo in stabilno upravlja več kot 10 tisoč gruč Kubernetes po vsem svetu. Poglejmo, kako je bilo to doseženo, vključno z več ključnimi načeli oblikovanja/arhitekture.

Oblikovanje

Kocka na kocko in satje

Za razliko od centralizirane hierarhije se arhitektura, ki temelji na celicah, običajno uporablja za razširitev platforme prek enega samega podatkovnega centra ali za razširitev obsega obnovitve po katastrofi.

Vsaka regija v oblaku Alibaba je sestavljena iz več con (AZ) in običajno ustreza določenemu podatkovnemu centru. V veliki regiji (npr. Huangzhou) je pogosto na tisoče gruč odjemalcev Kubernetes, ki izvajajo ACK.

ACK upravlja te gruče Kubernetes s samim Kubernetesom, kar pomeni, da imamo metagručo Kubernetes, ki se izvaja za upravljanje odjemalskih gruč Kubernetes. Ta arhitektura se imenuje tudi "kube-on-kube" (KoK). Arhitektura KoK poenostavlja upravljanje gruč strank, ker je uvedba gruč preprosta in deterministična. Še pomembneje je, da lahko ponovno uporabimo izvorne funkcije Kubernetes. Na primer, upravljanje strežnikov API prek uvajanja, uporaba operaterja etcd za upravljanje več etcd-jev. Takšna rekurzija vedno prinaša posebno zadovoljstvo.

V eni regiji je nameščenih več metagruč Kubernetes, odvisno od števila strank. Te metaskupine imenujemo celice. Za zaščito pred odpovedjo celotnega območja ACK podpira večaktivne uvedbe v eni sami regiji: metagruča razdeli glavne komponente odjemalske gruče Kubernetes po več območjih in jih izvaja hkrati, to je v večaktivnem načinu. Za zagotovitev zanesljivosti in učinkovitosti masterja ACK optimizira postavitev komponent in zagotavlja, da sta strežnik API in etcd blizu drug drugega.

Ta model vam omogoča učinkovito, prilagodljivo in zanesljivo upravljanje Kubernetesa.

Načrtovanje virov metagrozdov

Kot smo že omenili, je število metagrozdov v posamezni regiji odvisno od števila strank. Toda kdaj dodati novo metagručo? To je tipičen problem načrtovanja virov. Praviloma je običajno, da ustvarite novega, ko obstoječi metaclusterji izčrpajo vse svoje vire.

Vzemimo za primer omrežne vire. V arhitekturi KoK so komponente Kubernetes iz gruč odjemalcev razporejene kot pods v metagruči. Uporabljamo Terway (Slika 3) je visoko zmogljiv vtičnik, ki ga je razvil Alibaba Cloud za upravljanje omrežja vsebnikov. Zagotavlja bogat nabor varnostnih politik in vam omogoča povezavo z virtualnimi zasebnimi oblaki strank (VPC) prek Alibaba Cloud Elastic Networking Interface (ENI). Za učinkovito distribucijo omrežnih virov po vozliščih, podih in storitvah v metagruči moramo skrbno spremljati njihovo uporabo znotraj metagruče navideznih zasebnih oblakov. Ko se omrežni viri končajo, se ustvari nova celica.

Za določitev optimalnega števila gruč strank v vsaki metagruči upoštevamo tudi naše stroške, zahteve glede gostote, kvoto virov, zahteve glede zanesljivosti in statistiko. Na podlagi vseh teh informacij je sprejeta odločitev o ustvarjanju novega metagrozda. Upoštevajte, da se lahko majhni grozdi v prihodnosti močno razširijo, zato se poraba virov poveča, tudi če število grozdov ostane nespremenjeno. Vsakemu grozdu običajno pustimo dovolj prostega prostora za rast.

riž. 3. Arhitektura omrežja Terway

Komponente čarovnika za skaliranje v gručah odjemalcev

Komponente čarovnika imajo različne potrebe po virih. Odvisne so od števila vozlišč in podov v gruči, števila nestandardnih krmilnikov/operaterjev, ki komunicirajo z APIServerjem.

V ACK se vsaka gruča odjemalcev Kubernetes razlikuje po velikosti in zahtevah glede časa izvajanja. Univerzalne konfiguracije za namestitev komponent čarovnika ni. Če pomotoma nastavimo nizko omejitev virov za velikega odjemalca, potem njegova gruča ne bo kos obremenitvi. Če nastavite konzervativno visoko mejo za vse gruče, bodo viri izgubljeni.

Za iskanje subtilnega kompromisa med zanesljivostjo in ceno ACK uporablja tipski sistem. Definiramo namreč tri vrste grozdov: majhne, ​​srednje in velike. Vsaka vrsta ima ločen profil dodeljevanja virov. Vrsta je določena na podlagi obremenitve komponent čarovnika, števila vozlišč in drugih dejavnikov. Vrsta gruče se lahko sčasoma spremeni. ACK nenehno spremlja te dejavnike in lahko ustrezno tipka gor/dol. Ko se tip gruče spremeni, se dodelitev virov samodejno posodobi z minimalnim posredovanjem uporabnika.

Prizadevamo si izboljšati ta sistem z natančnejšim skaliranjem in natančnejšim posodabljanjem vrste, tako da bodo te spremembe potekale bolj gladko in da bodo bolj ekonomsko smiselne.

riž. 4. Inteligentno večstopenjsko preklapljanje

Razvoj grozdov strank v velikem obsegu

Prejšnji razdelki so pokrivali nekatere vidike upravljanja velikega števila gruč Kubernetes. Vendar pa obstaja še en problem, ki ga je treba rešiti: razvoj grozdov.

Kubernetes je »Linux« sveta oblakov. Nenehno se posodablja in postaja bolj modularen. Našim strankam moramo nenehno dostavljati nove različice, odpravljati ranljivosti in posodabljati obstoječe gruče ter upravljati veliko število povezanih komponent (CSI, CNI, Device Plugin, Scheduler Plugin in mnoge druge).

Vzemimo za primer upravljanje komponent Kubernetes. Za začetek smo razvili centraliziran sistem za registracijo in upravljanje vseh teh povezanih komponent.

riž. 5. Prilagodljive in vtične komponente

Preden nadaljujete, se morate prepričati, da je bila posodobitev uspešna. Za to smo razvili sistem za preverjanje funkcionalnosti komponent. Preverjanje se izvede pred in po posodobitvi.

riž. 6. Predhodni pregled komponent grozda

Za hitro in zanesljivo posodobitev teh komponent deluje sistem neprekinjenega uvajanja s podporo za delno napredovanje (sivine), premore in druge funkcije. Standardni krmilniki Kubernetes niso najbolj primerni za ta primer uporabe. Zato smo za upravljanje komponent gruče razvili nabor specializiranih krmilnikov, vključno z vtičnikom in pomožnim nadzornim modulom (sidecar management).

Krmilnik BroadcastJob je na primer zasnovan za posodabljanje komponent na vsakem delovnem stroju ali preverjanje vozlišč na vsakem stroju. Opravilo Broadcast zažene pod na vsakem vozlišču v gruči, kot je DaemonSet. Vendar pa DaemonSet vedno ohranja pod v teku dolgo časa, medtem ko ga BroadcastJob zruši. Krmilnik Broadcast prav tako zažene pode na novo združenih vozliščih in inicializira vozlišča s potrebnimi komponentami. Junija 2019 smo odprli izvorno kodo mehanizma za avtomatizacijo OpenKruise, ki ga tudi sami uporabljamo v podjetju.

riž. 7. OpenKurise organizira izvajanje naloge Broadcast na vseh vozliščih

Za pomoč strankam pri izbiri pravih konfiguracij gruče nudimo tudi niz vnaprej določenih profilov, vključno s profili brez strežnika, Edge, Windows in Bare Metal. Ko se krajina širi in potrebe naših strank rastejo, bomo dodali več profilov, da poenostavimo dolgočasen postopek namestitve.

riž. 8. Napredni in prilagodljivi profili gruče za različne scenarije

Globalna opazljivost v podatkovnih centrih

Kot je prikazano na spodnji sl. 9 je bila storitev v oblaku Alibaba Cloud Container uvedena v dvajsetih regijah po vsem svetu. Glede na to lestvico je eden od ključnih ciljev ACK preprosto spremljanje stanja delujočih gruč, tako da se lahko hitro odzovemo na situacijo, če gruča odjemalcev naleti na težavo. Z drugimi besedami, najti morate rešitev, ki vam bo omogočila učinkovito in varno zbiranje statističnih podatkov v realnem času iz grozdov strank v vseh regijah – in vizualno predstavitev rezultatov.

riž. 9. Globalna uvedba storitve Alibaba Cloud Container v dvajsetih regijah

Kot mnogi sistemi za spremljanje Kubernetes uporabljamo Prometheus kot glavno orodje. Za vsako metagručo agenti Prometheus zbirajo naslednje meritve:

• Meritve OS, kot so viri gostitelja (CPU, pomnilnik, disk itd.) in pasovna širina omrežja.
• Meritve za sistem za upravljanje gruče metagruče in odjemalca, kot so kube-apiserver, kube-controller-manager in kube-scheduler.
• Meritve iz kubernetes-state-metrics in cadvisor.
• etcd meritve, kot so čas pisanja na disk, velikost baze podatkov, prepustnost povezav med vozlišči itd.

Globalna statistika se zbira z uporabo tipičnega večplastnega modela združevanja. Podatki o spremljanju iz vsake metagruče so najprej združeni v vsaki regiji in nato poslani v osrednji strežnik, ki prikazuje celotno sliko. Vse deluje prek mehanizma federacije. Strežnik Prometheus v vsakem podatkovnem centru zbira metrike iz tega podatkovnega centra, osrednji strežnik Prometheus pa je odgovoren za združevanje podatkov spremljanja. AlertManager se poveže s centralnim Prometheusom in po potrebi pošilja opozorila prek DingTalk, e-pošte, SMS-a itd. Vizualizacija - uporaba Grafana.

Na sliki 10 lahko nadzorni sistem razdelimo na tri ravni:

• Mejna raven

Plast, ki je najbolj oddaljena od središča. Prometheus Edge Server deluje v vsaki metagruči in zbira metrike iz meta in odjemalskih gruč znotraj iste omrežne domene.

• Kaskadna raven

Funkcija kaskadne plasti Prometheus je zbiranje podatkov spremljanja iz več regij. Ti strežniki delujejo na ravni večjih geografskih enot, kot so Kitajska, Azija, Evropa in Amerika. Ko grozdi rastejo, je mogoče regijo razdeliti, nato pa se bo v vsaki novi veliki regiji pojavil strežnik Prometheus na kaskadni ravni. S to strategijo lahko po potrebi gladko spreminjate obseg.

• Centralna raven

Centralni strežnik Prometheus se poveže z vsemi kaskadnimi strežniki in izvede končno združevanje podatkov. Zaradi zanesljivosti sta bili v različnih conah postavljeni dve osrednji instanci Prometheus, povezani z istimi kaskadnimi strežniki.

riž. 10. Globalna večnivojska nadzorna arhitektura, ki temelji na zveznem mehanizmu Prometheus

Povzetek

Rešitve v oblaku, ki temeljijo na Kubernetesu, še naprej spreminjajo našo industrijo. Vsebniška storitev Alibaba Cloud zagotavlja varno, zanesljivo in visoko zmogljivo gostovanje – je eno najboljših gostovanj v oblaku Kubernetes. Ekipa Alibaba Cloud močno verjame v načela odprte kode in odprtokodne skupnosti. Svoje znanje s področja delovanja in upravljanja oblačnih tehnologij bomo zagotovo delili še naprej.

Vir: www.habr.com