Om Kubernetes ten volle te bemeester, moet jy verskillende maniere ken om groephulpbronne te skaal: deur , dit is een van die hooftake van Kubernetes. Ons het 'n hoëvlak-oorsig verskaf van horisontale en vertikale outoskaling en meganismes vir groepsverandering, sowel as aanbevelings oor hoe om dit effektief te gebruik.
Artikel vertaal deur die span wat outoskaal in geïmplementeer het .
Waarom dit belangrik is om oor skaal te dink
- 'n hulpmiddel vir hulpbronbestuur en orkestrasie. Natuurlik is dit lekker om te peuter met die koel kenmerke van die ontplooiing, monitering en bestuur van peule ('n peul is 'n groep houers wat in reaksie op 'n versoek bekendgestel word).
Jy moet egter ook oor die volgende vrae dink:
- Hoe om modules en toepassings te skaal?
- Hoe om houers operasioneel en doeltreffend te hou?
- Hoe om te reageer op konstante veranderinge in kode en werkladings van gebruikers?
Die opstel van Kubernetes-klusters om hulpbronne en prestasie te balanseer, kan uitdagend wees en vereis kundige kennis van die innerlike werking van Kubernetes. Die werklading van jou toepassing of dienste kan deur die loop van die dag of selfs oor 'n uur wissel, dus kan balansering die beste beskou word as 'n deurlopende proses.
Kubernetes-outoskaalvlakke
Effektiewe outoskaling vereis koördinasie tussen twee vlakke:
- Peulvlak, insluitend horisontale (Horizontal Pod Autoscaler, HPA) en vertikale outoscaler (Vertical Pod Autoscaler, VPA). Dit is besig om die beskikbare hulpbronne vir jou houers te skaal.
- Klustervlak, wat deur die Cluster Autoscaler (CA) bestuur word, wat die aantal nodusse binne die cluster verhoog of verminder.
Horisontale Autoscaler (HPA) module
Soos die naam aandui, skaal HPA die aantal peul-replikas. Die meeste devops gebruik CPU- en geheuelading as snellers om die aantal replikas te verander. Dit is egter moontlik om die stelsel te skaal op grond van , hulle of selfs .
Hoëvlak HPA-bedryfsdiagram:
- Die HPA kontroleer voortdurend die metrieke waardes wat tydens installasie gespesifiseer is, teen 'n verstekinterval van 30 sekondes.
- Die HPA poog om die aantal modules te vermeerder as die gespesifiseerde drempel bereik word.
- Die HPA dateer die aantal replikas binne die ontplooiing/replikasiebeheerder op.
- Die ontplooiing/replikasiebeheerder ontplooi dan enige nodige bykomende modules.
HPA begin die module-ontplooiingsproses wanneer 'n metrieke drempel bereik word
Wanneer jy HPA gebruik, oorweeg die volgende:
- Die verstek HPA-kontrole-interval is 30 sekondes. Dit word deur die vlag gestel horisontale-peul-outoskaaler-sinkroniseringsperiode in die beheerderbestuurder.
- Die verstek relatiewe fout is 10%.
- Ná die laaste toename in die aantal modules, verwag HPA dat die maatstawwe binne drie minute sal stabiliseer. Hierdie interval word deur die vlag bepaal horisontale-peul-autoscaler-upscale-vertraging.
- Na die laaste vermindering in die aantal modules, wag die HPA vir vyf minute om te stabiliseer. Hierdie interval word deur die vlag bepaal horisontale-peul-outoskaaler-afskaal-vertraging.
- HPA werk die beste met ontplooiingsvoorwerpe eerder as replikasiebeheerders. Horisontale outoskaling is onversoenbaar met rollende opdatering, wat replikasiebeheerders direk manipuleer. Met ontplooiing hang die aantal replikas direk af van die ontplooiingsvoorwerpe.
Vertikale outoskaling van peule
Vertikale outoskaling (VPA) ken meer (of minder) SVE tyd of geheue toe aan bestaande peule. Geskik vir statige of staatlose peule, maar hoofsaaklik bedoel vir statige dienste. U kan egter ook VPA vir staatlose modules gebruik as u die hoeveelheid aanvanklik toegekende hulpbronne outomaties moet aanpas.
VPA reageer ook op OOM (buite geheue) gebeure. Die verandering van SVE tyd en geheue vereis dat die peule herbegin word. Wanneer dit weer begin word, respekteer die VPA die toekenningsbegroting () om die minimum vereiste aantal modules te waarborg.
Jy kan die minimum en maksimum hulpbronne vir elke module stel. U kan dus die maksimum hoeveelheid toegewese geheue tot 8 GB beperk. Dit is nuttig as die huidige nodusse beslis nie meer as 8 GB geheue per houer kan toeken nie. Gedetailleerde spesifikasies en bedryfsmeganisme word beskryf in .
Daarbenewens het VPA 'n interessante aanbevelingsfunksie (VPA Aanbeveling). Dit monitor hulpbrongebruik en OOM-gebeure van alle modules om nuwe geheue- en SVE-tydwaardes voor te stel gebaseer op 'n intelligente algoritme gebaseer op historiese statistieke. Daar is ook 'n API wat 'n pod-handvatsel neem en voorgestelde hulpbronwaardes terugstuur.
Dit is die moeite werd om daarop te let dat VPA-aanbeveler nie hulpbron-“limiet” opspoor nie. Dit kan daartoe lei dat die module hulpbronne binne nodusse monopoliseer. Dit is beter om die limiet op die naamruimtevlak te stel om groot geheue- of SVE-verbruik te vermy.
Hoëvlak VPA-bedryfskema:
- VPA kontroleer voortdurend die metrieke waardes wat tydens installasie gespesifiseer is, met 'n verstekinterval van 10 sekondes.
- As die gespesifiseerde drempel bereik word, poog die VPA om die toegekende hoeveelheid hulpbronne te verander.
- Die VPA werk die aantal hulpbronne binne die ontplooiing/replikasiebeheerder op.
- Wanneer modules herbegin word, word alle nuwe hulpbronne op die geskepte gevalle toegepas.
VPA voeg die vereiste hoeveelheid hulpbronne by
Hou asseblief die volgende punte in gedagte wanneer jy VPA gebruik:
- Skaal vereis 'n verpligte herbegin van die peul. Dit is nodig om onstabiele werking te vermy nadat veranderinge gemaak is. Vir betroubaarheid word modules herbegin en oor nodusse versprei op grond van nuut-toegewysde hulpbronne.
- VPA en HPA is nog nie met mekaar versoenbaar nie en kan nie op dieselfde peule werk nie. As jy albei skaalmeganismes in dieselfde groepie gebruik, maak seker dat jou instellings verhoed dat hulle op dieselfde voorwerpe geaktiveer word.
- VPA pas houerversoeke vir hulpbronne net op grond van vorige en huidige gebruik. Dit stel nie hulpbrongebruiklimiete nie. Daar kan probleme wees met toepassings wat nie reg werk nie en al hoe meer hulpbronne begin oorneem, dit sal daartoe lei dat Kubernetes hierdie peul afskakel.
- VPA is nog in 'n vroeë stadium van ontwikkeling. Wees voorbereid dat die stelsel 'n paar veranderinge in die nabye toekoms kan ondergaan. Jy kan lees oor и . Daar is dus planne om die gesamentlike werking van VPA en HPA te implementeer, sowel as die ontplooiing van modules tesame met 'n vertikale outoskaalbeleid daarvoor (byvoorbeeld, 'n spesiale etiket 'vereis VPA').
Outoskaal van 'n Kubernetes-kluster
Cluster Autoscaler (CA) verander die aantal nodusse gebaseer op die aantal wagtende peule. Die stelsel kyk periodiek vir hangende modules - en vergroot die groepgrootte as meer hulpbronne benodig word en as die groepie nie die vasgestelde limiete oorskry nie. Die CA kommunikeer met die wolkdiensverskaffer, versoek bykomende nodusse van hom, of stel ledige vry. Die eerste algemeen beskikbare weergawe van CA is in Kubernetes 1.8 bekendgestel.
Hoëvlakskema van SA operasie:
- CA kyk vir hangende modules teen 'n verstekinterval van 10 sekondes.
- As een of meer peule in 'n bystandtoestand is omdat die groepie nie genoeg beskikbare hulpbronne het om hulle toe te wys nie, probeer dit om een of meer bykomende nodusse te voorsien.
- Wanneer die wolkdiensverskaffer die vereiste nodus toewys, sluit dit by die groep aan en is gereed om die peule te bedien.
- Die Kubernetes skeduleerder versprei hangende peule na die nuwe nodus. As sommige modules daarna nog in 'n wagtoestand bly, word die proses herhaal en nuwe nodusse word by die groepering gevoeg.
Outomatiese voorsiening van cluster nodusse in die wolk
Oorweeg die volgende wanneer jy CA gebruik:
- CA verseker dat alle peule in die groep ruimte het om te hardloop, ongeag die SVE-lading. Dit probeer ook verseker dat daar geen onnodige nodusse in die groep is nie.
- CA registreer die behoefte om te skaal na ongeveer 30 sekondes.
- Sodra 'n nodus nie meer nodig is nie, wag die CA verstek om 10 minute te wag voordat die stelsel uitgeskaal word.
- Die outoskaalstelsel het die konsep van uitbreidings. Dit is verskillende strategieë om 'n groep nodusse te kies waarby nuwe nodusse gevoeg sal word.
- Gebruik die opsie verantwoordelik cluster-autoscaler.kubernetes.io/safe-to-evict (true). As jy baie peule installeer, of as baie van hulle oor al die nodusse versprei is, sal jy grootliks die vermoë verloor om die groep uit te skaal.
- Gebruik om te verhoed dat peule uitgevee word, wat kan veroorsaak dat dele van jou toepassing heeltemal misluk.
Hoe Kubernetes-outoskaalers met mekaar omgaan
Vir perfekte harmonie moet outoskaling op beide die peulvlak (HPA/VPA) en die trosvlak toegepas word. Hulle het relatief eenvoudig interaksie met mekaar:
- HPA's of VPA's werk peul-replikas op of hulpbronne wat aan bestaande peule toegewys is.
- As daar nie genoeg nodusse vir die beplande skaal is nie, merk die CA die teenwoordigheid van peule in 'n wagtoestand op.
- Die CA ken nuwe nodusse toe.
- Modules word na nuwe nodusse versprei.
Samewerkende Kubernetes-afskaalstelsel
Algemene foute in Kubernetes-outoskaal
Daar is verskeie algemene probleme waarmee u te doen kry wanneer u probeer om outoskaal te implementeer.
HPA en VPA is afhanklik van statistieke en sommige historiese data. Indien onvoldoende hulpbronne toegewys word, sal die modules geminimaliseer word en sal nie metrieke kan genereer nie. In hierdie geval sal outoskaal nooit plaasvind nie.
Die skaalbewerking self is tydsensitief. Ons wil hê dat die modules en groepering vinnig moet skaal - voordat gebruikers enige probleme of mislukkings opmerk. Daarom moet die gemiddelde skaaltyd vir peule en die tros in ag geneem word.
Ideale scenario - 4 minute:
- 30 sekondes. Dateer teikenmaatstawwe op: 30-60 sekondes.
- 30 sekondes. HPA kontroleer metrieke waardes: 30 sekondes.
- Minder as 2 sekondes. Peule word geskep en gaan in wagtoestand: 1 sekonde.
- Minder as 2 sekondes. CA sien wagmodules en stuur oproepe na voorsieningsnodusse: 1 sekonde.
- 3 minute. Die wolkverskaffer ken nodusse toe. K8s wag totdat hulle gereed is: tot 10 minute (afhangende van verskeie faktore).
Ergste geval (meer realistiese) scenario - 12 minute:
- 30 sekondes. Dateer teikenmaatstawwe op.
- 30 sekondes. HPA kontroleer die metrieke waardes.
- Minder as 2 sekondes. Die peule word geskep en gaan in die standby-toestand.
- Minder as 2 sekondes. Die GR sien die wagmodules en maak oproepe om die nodusse te voorsien.
- 10 minute. Die wolkverskaffer ken nodusse toe. K8s wag totdat hulle gereed is. Die wagtyd hang af van verskeie faktore, soos verskaffer vertraging, OS vertraging, en ondersteuning gereedskap.
Moenie wolkverskaffers se skaalmeganismes met ons CA verwar nie. Laasgenoemde loop binne 'n Kubernetes-groepering, terwyl die wolkverskaffer-enjin op 'n nodusverspreidingsbasis werk. Dit weet nie wat aangaan met jou peule of toepassing nie. Hierdie stelsels werk parallel.
Hoe om skaal in Kubernetes te bestuur
- Kubernetes is 'n hulpbronbestuur- en orkestrasie-instrument. Bedrywighede vir die bestuur van peule en groeperingshulpbronne is 'n belangrike mylpaal in die bemeestering van Kubernetes.
- Verstaan die logika van peulskaalbaarheid met inagneming van HPA en VPA.
- CA moet slegs gebruik word as jy 'n goeie begrip het van die behoeftes van jou peule en houers.
- Om 'n groep optimaal op te stel, moet jy verstaan hoe verskillende skaalstelsels saamwerk.
- Wanneer u skaaltyd skat, hou slegste- en beste-geval-scenario's in gedagte.
Bron: will.com