Teningur á teningur, metaþyrpingar, hunangsseimur, auðlindadreifing

Hrísgrjón. 1. Kubernetes vistkerfi á Alibaba Cloud

Síðan 2015 hefur Alibaba Cloud Container Service fyrir Kubernetes (ACK) verið ein ört vaxandi skýjaþjónusta í Alibaba Cloud. Það þjónar fjölmörgum viðskiptavinum og styður einnig innri innviði Alibaba og aðra skýjaþjónustu fyrirtækisins.

Eins og með svipaða gámaþjónustu frá heimsklassa skýjaveitum, eru forgangsverkefni okkar áreiðanleiki og framboð. Þess vegna hefur stigstærð og aðgengilegur vettvangur verið búinn til fyrir tugþúsundir Kubernetes klasa.

Í þessari grein munum við deila reynslu okkar af því að stjórna miklum fjölda Kubernetes þyrpinga á skýjainnviðum, sem og arkitektúr undirliggjandi vettvangs.

Færslu

Kubernetes er orðinn raunverulegur staðall fyrir margs konar vinnuálag í skýinu. Eins og sýnt er á mynd. 1 hér að ofan, fleiri og fleiri Alibaba Cloud forrit eru nú í gangi á Kubernetes klösum: ríkjandi og ríkisfangslaus forrit, sem og forritastjórar. Stjórnun Kubernetes hefur alltaf verið áhugavert og alvarlegt umræðuefni fyrir verkfræðinga sem byggja og viðhalda innviðum. Þegar kemur að skýjaveitum eins og Alibaba Cloud, kemur spurningin um stærðarstærð upp á yfirborðið. Hvernig á að stjórna Kubernetes klasa á þessum mælikvarða? Við höfum þegar farið yfir bestu starfsvenjur til að stjórna risastórum 10 hnúta Kubernetes þyrpingum. Auðvitað er þetta áhugavert stærðarvandamál. En það er annar kvarði: magn klasarnir sjálfir.

Við höfum rætt þetta efni við marga ACK notendur. Flestir þeirra velja að reka tugi, ef ekki hundruð, lítilla eða meðalstórra Kubernetes-þyrpinga. Það eru góðar ástæður fyrir þessu: takmarka hugsanlegan skaða, aðgreina klasa fyrir mismunandi teymi, búa til sýndarklasa til að prófa. Ef ACK miðar að því að þjóna alþjóðlegum áhorfendum með þessu notkunarlíkani, verður það að stjórna fjölda klasa á meira en 20 svæðum á áreiðanlegan og skilvirkan hátt.

Hrísgrjón. 2. Vandamál við að stjórna miklum fjölda Kubernetes klasa

Hver eru helstu áskoranir við að stjórna klasa á þessum mælikvarða? Eins og sést á myndinni eru fjögur atriði sem þarf að takast á við:

• Misleitni

ACK ætti að styðja ýmsar gerðir af klösum, þar á meðal staðlaða, miðlaralausa, Edge, Windows og nokkra aðra. Mismunandi klasar þurfa mismunandi valkosti, íhluti og hýsingarlíkön. Sumir viðskiptavinir þurfa aðstoð við að sérsníða fyrir sín sérstöku tilvik.

• Ýmsar klasastærðir

Klasar eru mismunandi að stærð, allt frá nokkrum hnútum með nokkrum fræbelgjum til tugþúsunda hnúta með þúsundum fræbelgja. Auðlindaþörf er líka mjög mismunandi. Óviðeigandi úthlutun fjármagns getur haft áhrif á frammistöðu eða jafnvel valdið bilun.

• Mismunandi útgáfur

Kubernetes er að þróast mjög hratt. Nýjar útgáfur eru gefnar út á nokkurra mánaða fresti. Viðskiptavinir eru alltaf tilbúnir að prófa nýja eiginleika. Þannig að þeir vilja setja prófunarálagið á nýju útgáfurnar af Kubernetes og framleiðsluálagið á þær stöðugu. Til að uppfylla þessa kröfu verður ACK stöðugt að afhenda viðskiptavinum nýjar útgáfur af Kubernetes en viðhalda stöðugum útgáfum.

• Öryggisreglur

Klösum er dreift á mismunandi svæði. Sem slík verða þau að uppfylla ýmsar öryggiskröfur og opinberar reglur. Til dæmis, þyrping í Evrópu verður að vera í samræmi við GDPR, á meðan fjármálaský í Kína verður að hafa viðbótarlög af vernd. Þessar kröfur eru lögboðnar og það er óviðunandi að hunsa þær, þar sem þetta skapar mikla áhættu fyrir viðskiptavini skýjapallsins.

ACK pallurinn er hannaður til að leysa flest ofangreind vandamál. Það stýrir nú áreiðanlega og stöðugt meira en 10 þúsund Kubernetes þyrpingar um allan heim. Við skulum skoða hvernig þetta var náð, þar á meðal með nokkrum helstu hönnunar-/arkitektúrreglum.

Hönnun

Teningur á teningur og hunangsseimur

Ólíkt miðstýrðu stigveldi er frumubyggð arkitektúr venjulega notaður til að stækka vettvang út fyrir eina gagnaver eða til að auka umfang hamfarabata.

Hvert svæði í Alibaba Cloud samanstendur af nokkrum svæðum (AZ) og samsvarar venjulega tilteknu gagnaveri. Á stóru svæði (t.d. Huangzhou) eru oft þúsundir Kubernetes viðskiptavinaklasa sem keyra ACK.

ACK stjórnar þessum Kubernetes þyrpingum með því að nota Kubernetes sjálft, sem þýðir að við erum með Kubernetes metacluster í gangi til að stjórna Kubernetes þyrpingum viðskiptavinarins. Þessi arkitektúr er einnig kallaður „kube-on-kube“ (KoK). KoK arkitektúrinn einfaldar stjórnun viðskiptavinaklasa vegna þess að uppsetning klasa er einföld og ákveðin. Meira um vert, við getum endurnýtt innfædda Kubernetes eiginleika. Til dæmis að stjórna API netþjónum í gegnum uppsetningu, nota etcd rekstraraðila til að stjórna mörgum etcds. Slík endurtekning veitir alltaf sérstaka ánægju.

Nokkrir Kubernetes metaþyrpingar eru settir á markað innan eins svæðis, allt eftir fjölda viðskiptavina. Við köllum þessa metaþyrpinga frumur. Til að vernda gegn bilun á heilu svæði styður ACK fjölvirka dreifingu á einu svæði: Metacluster dreifir Kubernetes viðskiptavinaklasa aðalhlutum yfir mörg svæði og keyrir þá samtímis, það er í fjölvirkum ham. Til að tryggja áreiðanleika og skilvirkni meistarans, hámarkar ACK staðsetningu íhluta og tryggir að API þjónninn og etcd séu nálægt hvort öðru.

Þetta líkan gerir þér kleift að stjórna Kubernetes á skilvirkan, sveigjanlegan og áreiðanlegan hátt.

Metacluster auðlindaáætlun

Eins og áður hefur komið fram fer fjöldi metaþyrpinga á hverju svæði eftir fjölda viðskiptavina. En á hvaða tímapunkti á að bæta við nýjum metaþyrpingum? Þetta er dæmigert auðlindaskipulagsvandamál. Að jafnaði er venjan að búa til nýjan þegar núverandi metaþyrpingar hafa tæmt allar auðlindir sínar.

Tökum til dæmis netauðlindir. Í KoK arkitektúrnum eru Kubernetes íhlutir úr viðskiptavinaþyrpingum settir upp sem belg í metaþyrpingu. Við notum Terway (Mynd 3) er afkastamikil viðbót þróuð af Alibaba Cloud fyrir gámakerfisstjórnun. Það býður upp á mikið sett af öryggisstefnu og gerir þér kleift að tengjast sýndar einkaskýjum viðskiptavina (VPC) í gegnum Alibaba Cloud Elastic Networking Interface (ENI). Til að dreifa netauðlindum á áhrifaríkan hátt yfir hnúta, belg og þjónustu í metaþyrpingum, verðum við að fylgjast vandlega með notkun þeirra innan metaþyrpingar sýndar einkaskýja. Þegar nettilföng lýkur er nýr klefi búinn til.

Til að ákvarða ákjósanlegan fjölda viðskiptavinaklasa í hverjum metaklasa tökum við einnig tillit til kostnaðar okkar, þéttleikakröfur, auðlindakvóta, áreiðanleikakröfur og tölfræði. Ákvörðun um að búa til nýjan metaþyrping er tekin á grundvelli allra þessara upplýsinga. Athugið að litlir klasar geta stækkað mikið í framtíðinni og því eykst auðlindanotkun þó fjöldi klasa haldist óbreyttur. Venjulega skiljum við eftir nóg laust pláss fyrir hvern klasa til að vaxa.

Hrísgrjón. 3. Terway net arkitektúr

Stærð töfraþátta yfir viðskiptavinaklasa

Wizard hlutir hafa mismunandi auðlindaþarfir. Þeir eru háðir fjölda hnúta og fræbelgs í þyrpingunni, fjölda óstöðluðu stýrimanna/rekstraraðila sem hafa samskipti við APIServer.

Í ACK er hver Kubernetes biðlaraklasi mismunandi að stærð og kröfum um keyrslutíma. Það er engin alhliða uppsetning til að setja íhluti töframanns. Ef við settum fyrir mistök lágt auðlindamörk fyrir stóran viðskiptavin, þá mun þyrping hans ekki geta tekist á við álagið. Ef þú setur varlega há mörk fyrir alla klasa munu auðlindir fara til spillis.

Til að finna lúmskur málamiðlun milli áreiðanleika og kostnaðar notar ACK tegundakerfi. Við skilgreinum nefnilega þrjár tegundir klasa: litla, miðlungs og stóra. Hver tegund hefur sérstakt tilfangaúthlutunarsnið. Gerðin er ákvörðuð út frá álagi töfraþátta, fjölda hnúta og öðrum þáttum. Gerð klasans getur breyst með tímanum. ACK fylgist stöðugt með þessum þáttum og getur upp/niður slegið í samræmi við það. Þegar klasagerðinni hefur verið breytt er úthlutun tilfanga uppfærð sjálfkrafa með lágmarks íhlutun notenda.

Við erum að vinna að því að bæta þetta kerfi með fínni mælikvarða og nákvæmari gerð uppfærslu þannig að þessar breytingar gangi snurðulaust fyrir sig og séu hagkvæmari.

Hrísgrjón. 4. Greindur fjölþrepa tegundarskipti

Þróun viðskiptavinaklasa í mælikvarða

Fyrri hlutar fjölluðu um nokkra þætti varðandi stjórnun á miklum fjölda Kubernetes þyrpinga. Hins vegar er annað vandamál sem þarf að leysa: þróun klasa.

Kubernetes er „Linux“ skýjaheimsins. Það er stöðugt uppfært og verður mát. Við verðum stöðugt að afhenda viðskiptavinum okkar nýjar útgáfur, laga veikleika og uppfæra núverandi klasa, auk þess að stjórna miklum fjölda tengdra íhluta (CSI, CNI, Device Plugin, Scheduler Plugin og margir aðrir).

Tökum Kubernetes íhlutastjórnun sem dæmi. Til að byrja með þróuðum við miðstýrt kerfi til að skrá og stjórna öllum þessum tengdu íhlutum.

Hrísgrjón. 5. Sveigjanlegir og tengdir íhlutir

Áður en þú heldur áfram þarftu að ganga úr skugga um að uppfærslan hafi tekist. Til að gera þetta höfum við þróað kerfi til að athuga virkni íhluta. Athugunin er framkvæmd fyrir og eftir uppfærsluna.

Hrísgrjón. 6. Forathugun á klasaíhlutum

Til að uppfæra þessa hluti á fljótlegan og áreiðanlegan hátt vinnur stöðugt dreifingarkerfi með stuðningi við framfarir að hluta (grátóna), hlé og aðrar aðgerðir. Hefðbundnir Kubernetes stýringar henta ekki vel fyrir þetta notkunartilvik. Þess vegna, til að stjórna klasaíhlutum, höfum við þróað hóp sérhæfðra stýringa, þar á meðal viðbót og aukastýringareiningu (hliðarvagnastjórnun).

Til dæmis er BroadcastJob stjórnandi hannaður til að uppfæra íhluti á hverri vinnuvél eða athuga hnúta á hverri vél. Útsendingarstarfið keyrir belg á hverjum hnút í þyrpingunni, eins og DaemonSet. Hins vegar heldur DaemonSet belgnum alltaf í gangi í langan tíma á meðan BroadcastJob fellur það saman. Útsendingarstýringin setur einnig af stað belg á nýlega tengdum hnútum og frumstillir hnútana með nauðsynlegum íhlutum. Í júní 2019 opnuðum við frumkóða OpenKruise sjálfvirknivélarinnar sem við sjálf notum innan fyrirtækisins.

Hrísgrjón. 7. OpenKurise skipuleggur framkvæmd Broadcast verkefnisins á öllum hnútum

Til að hjálpa viðskiptavinum að velja réttar klasastillingar, bjóðum við einnig upp á sett af fyrirfram skilgreindum sniðum, þar á meðal Serverless, Edge, Windows og Bare Metal sniðum. Eftir því sem landslagið stækkar og þarfir viðskiptavina okkar vaxa, munum við bæta við fleiri prófílum til að einfalda leiðinlegt uppsetningarferlið.

Hrísgrjón. 8. Ítarleg og sveigjanleg klasasnið fyrir ýmsar aðstæður

Alheims athugun þvert á gagnaver

Eins og sýnt er á mynd hér að neðan. 9, Alibaba Cloud Container skýjaþjónusta hefur verið send á tuttugu svæðum um allan heim. Miðað við þennan mælikvarða er eitt af lykilmarkmiðum ACK að fylgjast auðveldlega með stöðu keyrandi klasa þannig að ef viðskiptavinaklasi lendir í vandamálum getum við fljótt brugðist við ástandinu. Með öðrum orðum, þú þarft að koma með lausn sem gerir þér kleift að safna tölfræði í rauntíma á skilvirkan og öruggan hátt frá viðskiptavinaklasa á öllum svæðum - og sýna niðurstöðurnar sjónrænt.

Hrísgrjón. 9. Alheimsdreifing Alibaba Cloud Container þjónustu á tuttugu svæðum

Eins og mörg Kubernetes eftirlitskerfi notum við Prometheus sem okkar aðalverkfæri. Fyrir hvern metacluster safna Prometheus umboðsmenn eftirfarandi mæligildum:

• Stýrikerfismælingar eins og hýsilauðlindir (CPU, minni, diskur osfrv.) og netbandbreidd.
• Mælingar fyrir metacluster og viðskiptavinaklasastjórnunarkerfið, svo sem kube-apiserver, kube-controller-manager og kube-scheduler.
• Mælingar frá kubernetes-state-metrics og cadvisor.
• etcd mæligildi eins og skriftíma disks, stærð gagnagrunns, afköst tenginga milli hnúta osfrv.

Alþjóðlegum tölfræði er safnað með dæmigerðu fjöllaga samsöfnunarlíkani. Vöktunargögnum úr hverjum metacluster er fyrst safnað saman á hverju svæði og síðan send á miðlægan netþjón sem sýnir heildarmyndina. Allt virkar í gegnum sambandskerfið. Prometheus þjónn í hverri gagnaver safnar mælingum frá þeirri gagnaver og miðlægi Prometheus þjónninn ber ábyrgð á því að safna vöktunargögnum. AlertManager tengist miðlægum Prometheus og sendir, ef nauðsyn krefur, viðvaranir í gegnum DingTalk, tölvupóst, SMS o.s.frv. Visualization - með Grafana.

Á mynd 10 má skipta eftirlitskerfinu í þrjú stig:

• Mörkin stig

Lagið lengst frá miðju. Prometheus Edge Server keyrir í hverjum metacluster og safnar mælingum frá meta- og biðlaraklösum innan sama netléns.

• Cascade stig

Hlutverk Prometheus fossalagsins er að safna vöktunargögnum frá mörgum svæðum. Þessir netþjónar starfa á stigi stærri landfræðilegra eininga eins og Kína, Asíu, Evrópu og Ameríku. Eftir því sem klasar stækka er hægt að skipta svæðinu og þá mun Prometheus þjónn á hverju nýju stóru svæði birtast. Með þessari stefnu geturðu slétt skalað eftir þörfum.

• Miðhæð

Miðlægi Prometheus þjónninn tengist öllum cascade netþjónum og framkvæmir endanlega gagnasöfnun. Til að tryggja áreiðanleika voru tvö miðlæg Prometheus tilvik sett upp á mismunandi svæðum, tengd við sömu fossþjóna.

Hrísgrjón. 10. Alheims fjölþrepa vöktunararkitektúr byggður á Prometheus sambandskerfi

Yfirlit

Kubernetes-undirstaða skýjalausnir halda áfram að umbreyta iðnaði okkar. Fjarvistarsönnun Cloud gámaþjónusta veitir örugga, áreiðanlega og afkastamikla hýsingu - hún er ein besta Kubernetes skýhýsingin. Alibaba Cloud teymið trúir mjög á meginreglur Open Source og opinn uppspretta samfélagsins. Við munum örugglega halda áfram að miðla þekkingu okkar á sviði rekstri og stjórnun skýjatækni.

Heimild: www.habr.com