Por plene regi Kubernetes, vi devas koni malsamajn manierojn grimpi amasajn rimedojn: de , ĉi tiu estas unu el la ĉefaj taskoj de Kubernetes. Ni disponigis altnivelan superrigardon de horizontala kaj vertikala aŭtomata skalado kaj grap-regrandigo-mekanismoj, kaj ankaŭ rekomendojn pri kiel uzi ilin efike.
Artikolo tradukite de la teamo kiu efektivigis aŭtoskalon enen .
Kial gravas pensi pri skalo
- ilo por mastrumado kaj instrumentado de rimedoj. Kompreneble, estas agrable tuŝi la bonegajn funkciojn de deplojado, monitorado kaj administrado de podoj (podo estas grupo de ujoj, kiuj estas lanĉitaj responde al peto).
Tamen, vi ankaŭ devus pensi pri la sekvaj demandoj:
- Kiel grimpi modulojn kaj aplikojn?
- Kiel konservi ujojn funkciaj kaj efikaj?
- Kiel respondi al konstantaj ŝanĝoj en kodo kaj laborŝarĝoj de uzantoj?
Agordi Kubernetes-grupojn por ekvilibrigi rimedojn kaj efikecon povas esti malfacila kaj postulas spertan scion pri la interna funkciado de Kubernetes. La laborkvanto de via aplikaĵo aŭ servoj povas varii dum la tago aŭ eĉ dum unu horo, do ekvilibro estas plej bone konsiderata kiel daŭra procezo.
Kubernetes aŭtoskalaj niveloj
Efika aŭtoskalo postulas kunordigon inter du niveloj:
- Podnivelo, inkluzive de horizontala (Horizontal Pod Autoscaler, HPA) kaj vertikala aŭtoskaler (Vertical Pod Autoscaler, VPA). Ĉi tio skalas la disponeblajn rimedojn por viaj ujoj.
- Aretonivelo, kiu estas administrita fare de la Cluster Autoscaler (CA), kiu pliigas aŭ malpliigas la nombron da nodoj ene de la areto.
Horizontala Autoscaler (HPA) modulo
Kiel la nomo sugestas, HPA skalas la nombron da podkopioj. Plej multaj devopoj uzas CPU kaj memorŝarĝon kiel ellasilon por ŝanĝi la nombron da kopioj. Tamen, eblas grimpi la sistemon bazitan sur , ilin aŭ eĉ .
Altnivela HPA-funkciiga diagramo:
- La HPA kontinue kontrolas la metrikajn valorojn specifitajn dum instalado je defaŭlta intervalo de 30 sekundoj.
- La HPA provas pliigi la nombron da moduloj se la specifita sojlo estas atingita.
- La HPA ĝisdatigas la nombron da kopioj ene de la deplojo/reprodukta regilo.
- La deplojo/reprodukta regilo tiam deplojas iujn ajn necesajn kromajn modulojn.
HPA komencas la modulan deplojprocezon kiam metrika sojlo estas atingita
Kiam vi uzas HPA, konsideru la jenajn:
- La defaŭlta HPA-kontrolintervalo estas 30 sekundoj. Ĝi estas starigita de la flago horizontala-pod-autoscaler-sync-period en la regilo-manaĝero.
- La defaŭlta relativa eraro estas 10%.
- Post la lasta pliiĝo en la nombro da moduloj, HPA atendas, ke la metrikoj stabiliĝu ene de tri minutoj. Ĉi tiu intervalo estas fiksita de la flago horizontala-pod-autoscaler-upscale-delay.
- Post la lasta redukto de la nombro da moduloj, la HPA atendas kvin minutojn por stabiligi. Ĉi tiu intervalo estas fiksita de la flago horizontala-pod-autoscaler-downscale-delay.
- HPA funkcias plej bone kun deplojobjektoj prefere ol reproduktaj regiloj. Horizontala aŭtoskalado estas malkongrua kun ruliĝanta ĝisdatigo, kiu rekte manipulas reproduktajn regilojn. Kun deplojo, la nombro da kopioj dependas rekte de la deplojobjektoj.
Vertikala aŭtoskalo de podoj
Vertikala aŭtoskalado (VPA) asignas pli (aŭ malpli) CPU-tempon aŭ memoron al ekzistantaj podoj. Taŭga por ŝtataj aŭ sennaciaj podoj, sed ĉefe celita por ŝtataj servoj. Tamen, vi ankaŭ povas uzi VPA por sennaciaj moduloj se vi bezonas aŭtomate ĝustigi la kvanton de komence asignitaj rimedoj.
VPA ankaŭ respondas al OOM (sen memoro) okazaĵoj. Ŝanĝi CPU-tempon kaj memoron postulas rekomenci la podojn. Kiam rekomencita, la VPA respektas la asignobuĝeton () por garantii la minimuman postulatan nombron da moduloj.
Vi povas agordi la minimumajn kaj maksimumajn rimedojn por ĉiu modulo. Tiel, vi povas limigi la maksimuman kvanton de asignita memoro al 8 GB. Ĉi tio estas utila se la nunaj nodoj certe ne povas asigni pli ol 8 GB da memoro per ujo. Detalaj specifoj kaj operaciumo estas priskribitaj en .
Krome, VPA havas interesan rekomendan funkcion (VPA Recommender). Ĝi kontrolas uzadon de rimedoj kaj OOM-okazaĵojn de ĉiuj moduloj por sugesti novajn memorajn kaj CPU-tempovalorojn bazitajn sur inteligenta algoritmo bazita sur historiaj metrikoj. Ekzistas ankaŭ API, kiu prenas podan tenilon kaj resendas proponitajn rimedvalorojn.
Indas noti, ke VPA Recommender ne spuras rimedon "limon". Ĉi tio povas rezultigi, ke la modulo monopoligas resursojn ene de nodoj. Pli bone estas agordi la limon ĉe la nomspaco por eviti grandegan memoron aŭ CPU-konsumon.
Altnivela VPA-operacia skemo:
- VPA kontinue kontrolas la metrikajn valorojn specifitajn dum instalado je defaŭlta intervalo de 10 sekundoj.
- Se la specifita sojlo estas atingita, la VPA provas ŝanĝi la asignitan kvanton da rimedoj.
- La VPA ĝisdatigas la nombron da resursoj ene de la deplojo/reprodukta regilo.
- Kiam moduloj estas rekomencitaj, ĉiuj novaj rimedoj estas aplikataj al la kreitaj petskriboj.
VPA aldonas la bezonatan kvanton da rimedoj
Bonvolu memori la jenajn punktojn kiam vi uzas VPA:
- Skalado postulas devigan rekomencon de la pod. Ĉi tio estas necesa por eviti malstabilan operacion post fari ŝanĝojn. Por fidindeco, moduloj estas rekomencitaj kaj distribuitaj trans nodoj surbaze de lastatempe asignitaj resursoj.
- VPA kaj HPA ankoraŭ ne kongruas unu kun la alia kaj ne povas funkcii per la samaj podoj. Se vi uzas ambaŭ skalmekanismojn en la sama areto, certigu, ke viaj agordoj malhelpas ilin esti aktivigitaj sur la samaj objektoj.
- VPA agordas ujajn petojn por rimedoj surbaze nur de pasinta kaj nuna uzado. Ĝi ne fiksas limojn pri uzado de rimedoj. Povas esti problemoj kun aplikaĵoj ne korekte funkcianta kaj komenci transpreni pli kaj pli da rimedoj, ĉi tio kondukos al Kubernetes malŝalti ĉi tiun podon.
- VPA ankoraŭ estas en frua stadio de evoluo. Estu preta, ke la sistemo eble suferos kelkajn ŝanĝojn en proksima estonteco. Vi povas legi pri и . Tiel, ekzistas planoj efektivigi la komunan funkciadon de VPA kaj HPA, same kiel la disfaldiĝon de moduloj kune kun vertikala aŭtoskala politiko por ili (ekzemple, speciala etikedo "postulas VPA").
Aŭtoskalo de Kubernetes-areto
Cluster Autoscaler (CA) ŝanĝas la nombron da nodoj surbaze de la nombro da atendkaptoj. La sistemo periode kontrolas pri pritraktataj moduloj - kaj pliigas la aretograndecon se pli da rimedoj estas necesaj kaj se la areto ne superas la establitajn limojn. La CA komunikas kun la nuba servoprovizanto, petas pliajn nodojn de ĝi aŭ liberigas neaktivajn. La unua ĝenerale havebla versio de CA estis lanĉita en Kubernetes 1.8.
Altnivela skemo de SA-operacio:
- CA kontrolas pri atendataj moduloj je defaŭlta intervalo de 10 sekundoj.
- Se unu aŭ pluraj balgoj estas en ŝancatendoŝtato ĉar la areto ne havas sufiĉajn disponeblajn rimedojn por asigni ilin, ĝi provas provizi unu aŭ plurajn kromajn nodojn.
- Kiam la provizanto de nuba servo asignas la bezonatan nodon, ĝi aliĝas al la areto kaj pretas servi la podojn.
- La planilo de Kubernetes distribuas atendatajn podojn al nova nodo. Se post tio kelkaj moduloj ankoraŭ restas en atenda stato, la procezo estas ripetita kaj novaj nodoj estas aldonitaj al la areto.
Aŭtomata provizo de grapolnodoj en la nubo
Konsideru la jenon kiam vi uzas CA:
- CA certigas, ke ĉiuj podoj en la areto havas spacon por funkcii, sendepende de CPU-ŝarĝo. Ĝi ankaŭ provas certigi, ke ne estas nenecesaj nodoj en la areto.
- CA registras la bezonon grimpi post proksimume 30 sekundoj.
- Post kiam nodo ne plu estas bezonata, la CA defaŭlte atendas 10 minutojn antaŭ malpligrandigi la sistemon.
- La aŭtoskala sistemo havas la koncepton de ekspansiiloj. Ĉi tiuj estas malsamaj strategioj por elekti grupon de nodoj al kiuj novaj nodoj estos aldonitaj.
- Uzu la opcion respondece cluster-autoscaler.kubernetes.io/safe-to-evict (vera). Se vi instalas multajn podojn, aŭ se multaj el ili estas disigitaj tra ĉiuj nodoj, vi plejparte perdos la kapablon malgrandigi la areton.
- Uzu por malebligi ke podoj estu forigitaj, kio povus kaŭzi ke partoj de via aplikaĵo tute malsukcesu.
Kiel Kubernetes aŭtoskaliloj interagas unu kun la alia
Por perfekta harmonio, aŭtoskalo devus esti aplikita kaj la podnivelo (HPA/VPA) kaj la grapolnivelo. Ili interagas unu kun la alia relative simple:
- HPAoj aŭ VPAoj ĝisdatigas podkopiojn aŭ rimedojn asignitajn al ekzistantaj podoj.
- Se ne estas sufiĉe da nodoj por la planita skalo, la CA rimarkas la ĉeeston de balgoj en atendanta stato.
- La CA asignas novajn nodojn.
- Moduloj estas distribuitaj al novaj nodoj.
Kunlabora Kubernetes-skalelsistemo
Oftaj eraroj en aŭtoskalado de Kubernetes
Estas pluraj oftaj problemoj, kiujn devops renkontas kiam ili provas efektivigi aŭtomatan skalon.
HPA kaj VPA dependas de metrikoj kaj iuj historiaj datumoj. Se nesufiĉaj rimedoj estas asignitaj, la moduloj estos minimumigitaj kaj ne povos generi metrikojn. En ĉi tiu kazo, aŭtoskalo neniam okazos.
La skala operacio mem estas temposentema. Ni volas, ke la moduloj kaj areto rapide skalu - antaŭ ol uzantoj rimarkos problemojn aŭ fiaskojn. Tial, la averaĝa skaltempo por gusoj kaj la areto devus esti konsiderata.
Ideala scenaro - 4 minutoj:
- 30 sekundoj. Ĝisdatigu celajn mezurojn: 30−60 sekundoj.
- 30 sekundoj. HPA kontrolas metrikajn valorojn: 30 sekundoj.
- Malpli ol 2 sekundoj. Pods estas kreitaj kaj iras en atendan staton: 1 sekundo.
- Malpli ol 2 sekundoj. CA vidas atendantajn modulojn kaj sendas vokojn al provizonodoj: 1 sekundo.
- 3 minutoj. La nuba provizanto asignas nodojn. K8s atendas ĝis ili estas pretaj: ĝis 10 minutoj (depende de pluraj faktoroj).
Plej malbona kazo (pli realisma) scenaro - 12 minutoj:
- 30 sekundoj. Ĝisdatigu celajn metrikojn.
- 30 sekundoj. HPA kontrolas la metrikajn valorojn.
- Malpli ol 2 sekundoj. La balgoj estas kreitaj kaj eniras la standby staton.
- Malpli ol 2 sekundoj. La CA vidas la atendantajn modulojn kaj faras vokojn por provizi la nodojn.
- 10 minutoj. La nuba provizanto asignas nodojn. K8s atendas ĝis ili estas pretaj. La atendotempo dependas de pluraj faktoroj, kiel vendoprokrasto, OS-prokrasto kaj subtenaj iloj.
Ne konfuzu la skalmekanismojn de nubaj provizantoj kun nia CA. Ĉi-lasta funkcias ene de Kubernetes-areto, dum la nuba provizanta motoro funkcias laŭ noda distribuobazo. Ĝi ne scias kio okazas kun viaj podoj aŭ aplikaĵo. Ĉi tiuj sistemoj funkcias paralele.
Kiel administri skaladon en Kubernetes
- Kubernetes estas ilo pri administrado de rimedoj kaj instrumentado. Operacioj por administri podojn kaj areto-resursojn estas ŝlosila mejloŝtono en majstrado de Kubernetes.
- Komprenu la logikon de podskaleblo konsiderante HPA kaj VPA.
- CA devus esti uzata nur se vi bone komprenas la bezonojn de viaj podoj kaj ujoj.
- Por optimume agordi areton, vi devas kompreni kiel malsamaj skalsistemoj funkcias kune.
- Dum taksado de skalotempo, memoru la plej malbonajn kaj plej bonajn okazojn.
fonto: www.habr.com