Kubus-op-kubus, metaclusters, heuningkoeke, hulpbrontoewysing

Rys. 1. Kubernetes Ekostelsel op Alibaba Wolk

Sedert 2015 is Alibaba Cloud Container Service for Kubernetes (ACK) een van die vinnigste groeiende wolkdienste in Alibaba Cloud. Dit bedien talle kliënte en onderhou ook Alibaba se interne infrastruktuur en ander wolkdienste van die maatskappy.

Soos met soortgelyke houerdienste van wêreldklas-wolkverskaffers, is ons topprioriteite betroubaarheid en beskikbaarheid. Daarom is 'n skaalbare en wêreldwyd beskikbare platform geskep vir tienduisende Kubernetes-klusters.

In hierdie artikel sal ons die ervaring deel van die bestuur van 'n groot aantal Kubernetes-klusters op 'n wolkinfrastruktuur, sowel as die argitektuur van die onderliggende platform.

Entry

Kubernetes het die de facto-standaard geword vir verskeie werkladings in die wolk. Soos in fig. 1 hierbo loop meer en meer Alibaba Wolk-toepassings nou op Kubernetes-klusters: staatsvolle/staatlose toepassings en toepassingsbestuurders. Kubernetes-bestuur was nog altyd 'n interessante en ernstige onderwerp van bespreking vir ingenieurs wat infrastruktuur bou en in stand hou. Wat wolkverskaffers soos Alibaba Cloud betref, kom die kwessie van skaal na vore. Hoe om Kubernetes-klusters op hierdie skaal te bestuur? Ons het reeds beste praktyke gedek vir die bestuur van groot Kubernetes-klusters met 10 000 nodusse. Natuurlik is dit 'n interessante skaalprobleem. Maar daar is 'n ander skaal: die getal die trosse self.

Ons het hierdie onderwerp met baie ACK-gebruikers bespreek. Die meeste van hulle verkies om dosyne, indien nie honderde, klein of mediumgrootte Kubernetes-klusters te laat loop. Daar is goeie redes hiervoor: die beperking van potensiële skade, die skeiding van groepe vir verskillende spanne, die skep van virtuele groepe vir toetsing. As ACK daarop gemik is om 'n globale gehoor met hierdie gebruiksmodel te bedien, moet dit 'n groot aantal groepe in meer as 20 streke betroubaar en doeltreffend bestuur.

Rys. 2. Probleme met die bestuur van 'n groot aantal Kubernetes-klusters

Wat is die belangrikste uitdagings van die bestuur van groepe op hierdie skaal? Soos in die figuur getoon, is daar vier probleme wat hanteer moet word:

• Heterogeniteit

ACK moet verskeie tipes groepe ondersteun, insluitend standaard, bedienerloos, Edge, Windows en 'n paar ander. Verskillende groepe benodig verskillende parameters, komponente en gasheermodelle. Sommige kliënte het hulp nodig met aanpassing vir hul spesifieke behoeftes.

• Verskillende grootte van trosse

Groepe wissel in grootte, van 'n paar nodusse met 'n paar peule tot tienduisende nodusse met duisende peule. Hulpbronvereistes verskil ook baie. Verkeerde hulpbrontoewysing kan prestasie beïnvloed of selfs 'n ineenstorting veroorsaak.

• verskillende weergawes

Kubernetes groei baie vinnig. Nuwe weergawes word elke paar maande vrygestel. Kliënte is altyd gereed om nuwe funksies te probeer. Hulle wil dus die toetslading op nuwe weergawes van Kubernetes en die werklading op die stabiele aanbied. Om aan hierdie vereiste te voldoen, moet ACK voortdurend nuwe weergawes van Kubernetes aan kliënte lewer, terwyl stabiele weergawes gehandhaaf word.

• Veiligheidsnakoming

Klusters is oor verskillende streke versprei. Hulle moet dus aan verskeie veiligheidsvereistes en amptelike regulasies voldoen. 'n Groepering in Europa moet byvoorbeeld aan die GDPR voldoen, terwyl 'n finansiële wolk in China bykomende lae van beskerming moet hê. Hierdie vereistes is verpligtend, dit is onaanvaarbaar om dit te ignoreer, aangesien dit groot risiko's vir kliënte van die wolkplatform skep.

Die ACK-platform is ontwerp om die meeste van die bogenoemde probleme op te los. Dit bestuur tans meer as 10 XNUMX Kubernetes-klusters regoor die wêreld veilig en konsekwent. Kom ons kyk hoe ons dit reggekry het, insluitend danksy verskeie sleutelbeginsels van ontwerp/argitektuur.

Design

Kubus-op-kubus en heuningkoeke

Anders as 'n gesentraliseerde hiërargie, word 'n selgebaseerde argitektuur gewoonlik gebruik om 'n platform verder as 'n enkele datasentrum te skaal of om die rampherstelgebied uit te brei.

Elke streek in die Alibaba-wolk bestaan ​​uit veelvuldige sones (AZ) en stem gewoonlik ooreen met 'n spesifieke datasentrum. In 'n groot streek (soos Huangzhou) is daar dikwels duisende Kubernetes-kliëntklusters wat ACK's gebruik.

ACK bestuur hierdie Kubernetes-klusters saam met Kubernetes self, wat beteken dat ons 'n Kubernetes-metakluster het wat loop om Kubernetes-klusters van kliënte te bestuur. Hierdie argitektuur word ook "kubus-op-kubus" (kube-op-kube, KoK) genoem. Die KoK-argitektuur vereenvoudig die bestuur van kliëntklusters namate trosontplooiing eenvoudig en deterministies word. Nog belangriker, ons kan inheemse Kubernetes-kenmerke hergebruik. Byvoorbeeld, die bestuur van API-bedieners deur ontplooiing, die gebruik van die etcd-stelling om verskeie etcd's te bestuur. Sulke rekursie bring altyd spesiale plesier.

Binne dieselfde streek word verskeie Kubernetes-metaklusters ontplooi, afhangende van die aantal kliënte. Ons noem hierdie metaklusters selle. Om teen 'n hele sone-mislukking te beskerm, ondersteun ACK multi-aktiewe ontplooiings in dieselfde streek: die metacluster versprei die Kubernetes Client Cluster Master-komponente oor verskeie sones en laat dit gelyktydig loop, dit wil sê in multi-aktiewe modus. Om die betroubaarheid en doeltreffendheid van die meester te verseker, optimaliseer ACK komponentplasing en verseker dat die API-bediener en ens naby mekaar is.

Hierdie model laat doeltreffende, buigsame en betroubare bestuur van Kubernetes toe.

Metacluster Hulpbronbeplanning

Soos ons reeds genoem het, hang die aantal metaklusters in elke streek af van die aantal kliënte. Maar op watter punt om 'n nuwe metakluster by te voeg? Dit is 'n tipiese hulpbronbeplanningsprobleem. As 'n reël is dit gebruiklik om 'n nuwe een te skep wanneer die bestaande metaklusters al hul hulpbronne uitgeput het.

Neem byvoorbeeld netwerkhulpbronne. In die KoK-argitektuur word Kubernetes-komponente van kliëntklusters as peule in 'n metakluster ontplooi. Ons gebruik Terway (Figuur 3) is 'n hoëprestasie-inprop wat deur Alibaba Cloud ontwikkel is vir houernetwerkbestuur. Dit bied 'n ryk stel sekuriteitsbeleide en stel jou in staat om aan kliënte se virtuele private wolke (VPC's) te koppel deur die Alibaba Cloud Elastic Networking Interface (ENI). Om netwerkhulpbronne effektief oor nodusse, peule en dienste in 'n metakluster toe te wys, moet ons hul gebruik noukeurig naspoor binne die virtuele private wolk-metacluster. Wanneer netwerkhulpbronne opraak, word 'n nuwe sel geskep.

Om die optimale aantal kliënteklusters in elke metakluster te bepaal, oorweeg ons ook ons ​​koste, digtheidsvereistes, hulpbronkwota, betroubaarheidsvereistes en statistieke. Die besluit om 'n nuwe metakluster te skep, word geneem op grond van al hierdie inligting. Neem asseblief kennis dat klein groepe in die toekoms baie kan uitbrei, dus neem hulpbronverbruik selfs met dieselfde aantal trosse toe. Ons laat gewoonlik genoeg vrye spasie vir elke tros om te groei.

Rys. 3. Terway netwerk argitektuur

Skaalassistentkomponente op kliëntklusters

Wizard-komponente het verskillende hulpbronvereistes. Hulle hang af van die aantal nodusse en peule in die groep, die aantal nie-standaard beheerders / operateurs wat interaksie met die APIServer.

In die ACK verskil elke kliënt Kubernetes-kluster in grootte en looptydvereistes. Daar is geen universele konfigurasie vir die aanbieding van towenaarkomponente nie. As ons verkeerdelik 'n lae hulpbronlimiet vir 'n groot kliënt stel, sal sy groep nie die las hanteer nie. As jy 'n konserwatief hoë limiet vir alle groepe stel, sal hulpbronne vermors word.

Om 'n subtiele kompromie tussen betroubaarheid en koste te vind, gebruik ACK 'n tipe stelsel. Ons definieer naamlik drie tipes trosse: klein, medium en groot. Elke tipe het 'n aparte hulpbrontoewysingsprofiel. Die tipe word bepaal op grond van die laai van die towenaarkomponente, die aantal nodusse en ander faktore. Die groep tipe kan met verloop van tyd verander. ACK monitor voortdurend hierdie faktore en kan dienooreenkomstig opgradeer/afgradeer. Nadat die groeptipe verander is, word hulpbrontoewysing outomaties opgedateer met minimale gebruikeringryping.

Ons werk daaraan om hierdie stelsel te verbeter met fyner skaal en meer akkurate tipe opdaterings sodat hierdie veranderinge gladder is en meer ekonomies sin maak.

Rys. 4. Intelligente multi-stadium tipe skakeling

Die evolusie van kliëntklusters op skaal

Die vorige afdelings het sommige aspekte van die bestuur van 'n groot aantal Kubernetes-klusters gedek. Daar is egter nog een probleem wat opgelos moet word: die evolusie van trosse.

Kubernetes is die "Linux" van die wolkwêreld. Dit word voortdurend opgedateer en word meer modulêr. Ons moet voortdurend nuwe weergawes aan ons kliënte lewer, kwesbaarhede regstel en bestaande clusters bywerk, en 'n groot aantal verwante komponente bestuur (CSI, CNI, Device Plugin, Scheduler Plugin en vele ander).

Kom ons neem Kubernetes-komponentbestuur as 'n voorbeeld. Om mee te begin, het ons 'n gesentraliseerde registrasie- en bestuurstelsel vir al hierdie inproppe ontwikkel.

Rys. 5. Buigsame en inpropbare komponente

Voordat u verder gaan, moet u seker maak dat die opdatering suksesvol was. Om dit te doen, het ons 'n komponent gesondheidskontrolestelsel ontwikkel. Die kontrole word voor en na die opdatering uitgevoer.

Rys. 6. Voorlopige kontrole van troskomponente

Vir vinnige en betroubare opdaterings van hierdie komponente werk 'n deurlopende ontplooiingstelsel met ondersteuning vir gedeeltelike vordering (grysskaal), pouses en ander funksies. Standaard Kubernetes-beheerders is nie goed geskik vir hierdie gebruiksgeval nie. Daarom, om die groepkomponente te bestuur, het ons 'n stel gespesialiseerde beheerders ontwikkel, insluitend 'n inprop en 'n hulpbestuursmodule (syspanbestuur).

Byvoorbeeld, die BroadcastJob-beheerder is ontwerp om komponente op elke werkmasjien op te dateer of nodusse op elke masjien na te gaan. Die uitsaai-taak laat 'n peul op elke groepknoop loop soos 'n DaemonSet. Die DaemonSet hou egter altyd die peul lewendig terwyl die BroadcastJob dit ineenstort. Die uitsaaibeheerder begin ook peule op nuut gevoegde nodusse en inisialiseer die nodusse met die vereiste komponente. In Junie 2019 het ons die bronkode vir die OpenKruise-outomatiseringsenjin oopgemaak, wat ons self intern gebruik.

Rys. 7. OpenKurise organiseer die uitvoering van die Broadcast-taak op alle nodusse

Om kliënte te help om die regte groepkonfigurasies te kies, verskaf ons ook 'n stel voorafbepaalde profiele, insluitend Serverless-, Edge-, Windows- en Bare Metal-profiele. Soos die landskap uitbrei en ons kliënte se behoeftes groei, sal ons meer profiele byvoeg om die vervelige opstellingsproses te vergemaklik.

Rys. 8. Gevorderde en buigsame groepprofiele vir verskeie scenario's

Globale waarneembaarheid deur datasentrum

Soos hieronder in fig. 9, Alibaba Cloud Container-wolkdiens word in twintig streke van die wêreld ontplooi. Gegewe hierdie skaal, is een van die sleuteldoelwitte van ACK om die status van lopende groepe maklik te monitor: as 'n kliëntgroepering 'n probleem teëkom, kan ons vinnig op die situasie reageer. Met ander woorde, jy moet met 'n oplossing vorendag kom wat jou in staat sal stel om doeltreffend en veilig intydse statistieke van kliënteklusters in alle streke in te samel - en die resultate visueel aan te bied.

Rys. 9. Wêreldwye ontplooiing van Alibaba Wolkhouer-diens in twintig streke

Soos met baie Kubernetes-moniteringstelsels, het ons Prometheus as ons hoofinstrument. Vir elke metakluster versamel Prometheus-agente die volgende statistieke:

• OS-metrieke soos gasheerhulpbronne (SVE, geheue, skyf, ens.) en netwerkbandwydte.
• Metrieke vir die bestuur van metaklusters en kliëntklusters, soos kube-apiserver, kube-beheerder-bestuurder en kube-skeduleerder.
• Metrieke van kubernetes-staat-metrieke en cadvisor.
• Ens-metrieke soos skyfskryftyd, databasisgrootte, deurset van skakels tussen nodusse, ens.

Die versameling van globale statistieke word uitgevoer volgens 'n tipiese multilaag-aggregasiemodel. Moniteringsdata van elke metakluster word eers in elke streek saamgevoeg en dan na 'n sentrale bediener gestuur wat die groot prentjie toon. Alles werk deur die federasiemeganisme. Die Prometheus-bediener in elke datasentrum samel datasentrumstatistieke in, en die sentrale Prometheus-bediener is verantwoordelik vir die samevoeging van die moniteringsdata. AlertManager koppel aan die sentrale Prometheus en, indien nodig, stuur waarskuwings via DingTalk, e-pos, SMS, ens. Visualisering - met behulp van Grafana.

In Figuur 10 kan die moniteringstelsel in drie vlakke verdeel word:

• grensvlak

Die laag verste van die middel. Die Prometheus edge-bediener loop in elke metakluster en versamel meta- en kliëntklusterstatistieke binne dieselfde netwerkdomein.

• Cascade vlak

Die funksie van die Prometheus-kaskadelaag is om moniteringsdata van verskeie streke in te samel. Hierdie bedieners werk op die vlak van groter geografiese gebiede soos China, Asië, Europa en Amerika. Soos trosse groei, kan 'n streek verdeel word, en dan sal 'n waterval Prometheus-bediener in elke nuwe groot streek verskyn. Met hierdie strategie kan jy naatloos skaal soos nodig.

• Sentrale vlak

Die sentrale Prometheus-bediener koppel aan alle kaskade-bedieners en voer die finale data-aggregasie uit. Vir betroubaarheid is twee sentrale Prometheus-gevalle wat aan dieselfde kaskade-bedieners gekoppel is, in verskillende sones geopper.

Rys. 10. Globale multi-vlak monitering argitektuur gebaseer op die Prometheus federasie meganisme

Opsomming

Kubernetes-gebaseerde wolkoplossings gaan voort om ons bedryf te transformeer. Alibaba Cloud Container Service bied veilige, betroubare en hoëprestasie-gasheer en is een van die beste Kubernetes-wolkhosting. Die Alibaba Cloud-span glo sterk in die beginsels van Open Source en die oopbron-gemeenskap. Ons sal beslis voortgaan om ons kennis op die gebied van bedryf en bestuur van wolktegnologie te deel.

Bron: will.com