Kolm automaatse skaleerimise taset Kuberneteses: kuidas neid efektiivselt kasutada

Kubernetesi täielikuks mõistmiseks tuleb teada erinevaid meetodeid klastrite ressursside skaleerimiseks: süsteemi arendajate sõnul,on see üks Kubernetes'e peamisi ülesandeid. Oleme valmistanud ette kõrgetasemelise ülevaate horisontaalsest ja vertikaalsest automaatse skaleerimise ning klastrite suurendamise mehhanismidest, samuti soovitusi, kuidas neid tõhusalt kasutada.

Artiklit Kubernetesi automaatse skaleerimise 101: klastrite automaatne skaleerija, horisontaalne skaleerija ja vertikaalne pod'i skaleerija tõlkis meeskond, kes rakendas automaatse skaleerimise Mail.ru Kubernetes aaS.

Miks on oluline mõelda skaleerimisele

Kubernetes — vahend ressursside haldamiseks ja orkestreerimiseks. Muidugi on tore mängida lahedate juurutamise, jälgimise ja pod'ide (pod on konteinerite grupp, mis käivitatakse vastusena päringule) haldamise funktsioonidega.

Kuid tuleks mõelda ka sellistele küsimustele:

1. Kuidas skaleerida mooduleid ja rakendusi?
2. Kuidas hoida anumaid töös ja efektiivsetena?
3. Kuidas reageerida pidevatele muudatustele koodis ja kasutajate koormustes?

Kubernetesi klastrite seadistamine ressursside ja jõudluse tasakaalustamiseks võib olla keeruline ülesanne, mis nõuab sügavaid teadmisi Kubernetesest. Teie rakenduse või teenuste koormus võib päeva või isegi tunni jooksul kõikuda, seetõttu tuleks tasakaalustamist käsitleda kui pidevat protsessi.

Kubernetes automaatse muutmise tasemed

Tõhus automaatne muutmine nõuab koordineerimist kahe tasandi vahel:

1. Podide tase, mis hõlmab horisontaalset (Horizontal Pod Autoscaler, HPA) ja vertikaalset automaatset muutmist (Vertical Pod Autoscaler, VPA). See on olemasolevate ressursside suurendamine teie konteinerite jaoks.
2. Klastri tase, mida haldab klastrite automaatse muutmise süsteem (Cluster Autoscaler, CA), mis suurendab või vähendab klastris olevate sõlmede arvu.

Horisontaalne automaatse muutmise moodul (HPA)

Nagu nimigi ütleb, skaleerib HPA podide replikate arvu. Replikate arvu muutmise kõige levinumateks käivitajateks on protsessori ja mälu koormus. Kuid süsteemi saab skaleerida ka põhinedes kasutaja määratud metrikatele, nende kombinatsioonile või isegi välised mõõdikud.

HPA töö kõrge taseme skeem:

1. HPA kontrollib pidevalt installimisel määratud mõõdikute väärtusi vaikimisi 30-sekundiliste intervallidega.
2. HPA püüab suurendada moodulite arvu, kui saavutatakse määratud lävend.
3. HPA uuendab replikate arvu juurutamise/replikatsiooni kontrollija sees.
4. Juurutamise/replikatsiooni kontrollija seejärel juurutab kõik vajalikud täiendavad moodulid.

HPA käivitab moodulite juurutamisprotsessi, kui mõõdikute lävend saavutatakse.

HPA kasutamisel arvestage järgmist:

• HPA vaikimisi kontrollimise intervall on 30 sekundit. See on määratud lipuga horizontal-pod-autoscaler-sync-period kontrolleri halduris.
• Vaikimisi suhteline viga on 10%.
• Pärast viimast moodulite arvu suurendamist ootab HPA mõõdikute stabiliseerumist kolme minuti jooksul. See intervall on määratud lipuga horizontal-pod-autoscaler-upscale-delay.
• Pärast viimast moodulite arvu vähendamist ootab HPA stabiliseerumist viie minuti jooksul. See intervall on määratud lipuga horizontal-pod-autoscaler-downscale-delay.
• HPA töötab kõige paremini juurutusobjektidega, mitte replikatsiooni kontrolleritega. Horisontaalne automaatskalaarimine ei ühildu järkjärgulise värskendamisega (rolling update), mis manipuleerib otse replikatsiooni kontrolleritega. Juhtimisel sõltub replikate arvu vahetus otse juurutusobjektidest.

Pod'ide vertikaalne automaatskalaarimine

Vertikaalne automaatskalaarimine (VPA) eraldab rohkem (või vähem) protsessori aega või mälu olemasolevatele pod'idele. Sobib nii olekut säilitavatele (stateful) kui ka olekuta (stateless) pod'idele, kuid on peamiselt mõeldud stateful teenustele. Siiski võite VPA-d rakendada ka olekuta moodulitele, kui on vaja automaatselt kohandada algselt eraldatud ressursside mahtu.

VPA reageerib ka OOM (out of memory, mälu puudus) sündmustele. Protsessori aja ja mälu mahu muutmiseks on vajalik pod'ide taaskäivitamine. Taaskäivitamisel järgib VPA jaotuse eelarvet (pods distribution budget, PDB), et tagada minimaalne vajalik moodulite arv.

Saate iga mooduli jaoks määrata ressursi minimaalset ja maksimaalset mahtu. Näiteks on võimalik piirata eraldatud mälu maksimaalne maht 8 GB piirini. See on kasulik, kui praegused sõlmed lihtsalt ei saa eraldada rohkem kui 8 GB mälu konteinerile. Üksikasjalikud spetsifikatsioonid ja töömehhanism on kirjeldatud ametlikus VPA wikisse.

Lisaks on VPA-l huvitav soovituste funktsioon (VPA Recommender). See jälgib ressursside kasutamist ja OOM-i sündmusi kõigis moodulites, et pakkuda uusi mälu ja protsessori ajakulu väärtusi, põhinedes intelligentsele algoritmile, mis arvestab ajaloolisi mõõdikuid. Samuti on saadaval API, mis võtab vastu podi deskriptorit ja tagastab soovitatud ressursi väärtused.

Märkimisväärne on see, et VPA Recommender ei jälgi „piirangut” ressurssides. See võib põhjustada mooduli ressursside monopoliseerimise sõlmede sees. Paremini on seada piirväärtus nimede tasemel, et vältida tohutut mälu või protsessori ajakulu.

VPA töö kõrgtaseme skeem:

1. VPA kontrollib pidevalt installimisel määratud mõõdikute väärtusi, vaikimisi iga 10 sekundi järel.
2. Kui määratud lävi on saavutatud, üritab VPA määratud ressursse muuta.
3. VPA värskendab ressursi arvu juurutamise/replikatsiooni kontrolleris.
4. Modulite taaskäivitamisel rakendatakse kõiki uusi ressursse loodud instantsidesse.

VPA lisab vajalikud ressursid.

VPA kasutamisel arvestage järgmisega:

• Suurendamine nõuab pod'i kohustuslikku taaskäivitamist. See on vajalik, et vältida kohanduste järgselt ebastabiilset tööd. Usaldusväärsuse tagamiseks taaskäivitavad moodulid ja jaotavad node'ide vahel vastavalt uutele määratud ressurssidele.
• VPA ja HPA ei ole praegu omavahel ühilduvad ega saa töötada sama pod'i peal. Kui rakendate ühes klastris mõlemat skaleerimismehhanismi, veenduge, et seaded ei võimaldaks neil aktiveeruda sama objekti peal.
• VPA kohandab konteinerite ressursiküsitlusi, tuginedes ainult nende varasemale ja praegusele kasutamisele. Ta ei sea ressursikasutuse piire. See võib põhjustada probleeme rakenduste vale toimimisega, mis hakkavad tarbima järjest rohkem ressursse, mis toob kaasa selle, et Kubernetes sulgeb vastava podi.
• VPA on praegu arenduse varajases staadiumis. Olge valmis, et lähitulevikus võib süsteem kogeda teatud muudatusi. Lisainfot leiate tuntud piirangute ja arendusplaanide. Näiteks on plaanis rakendada VPA ja HPA koostööd, samuti moodulite juurutamine koos nende jaoks väljapakutud vertikaalse automaatse suurendamise poliitikaga (nt eriline silt 'requires VPA').

Kubernetes'e klastrite automaatne suurendamine

Klastri automaatne skaleerimine (Cluster Autoscaler, CA) muudab sõlmede arvu sõltuvalt ootel olevate pod-modulite arvust. Süsteem kontrollib perioodiliselt ootel olevaid mooduleid ja suurendab klastrite suurust, kui on rohkem ressursse vaja ja kui klass ei ületa seatud limiite. CA suhtleb pilveteenuse pakkujaga, taotleb täiendavate sõlmede saamist või vabastab inaktiivseid. CA esimene avalik versioon esitati Kubernetes 1.8.

CA töö kõrgema taseme skeem:

1. CA kontrollib ootel olevaid mooduleid vaikimisi intervalliga 10 sekundit.
2. Kui üks või mitu moodulit on ootel, sest klastris pole nende jagamiseks piisavalt ressursse, püüdleb see ühe või mitme täiendava sõlme ettevalmistamise poole.
3. Kui pilveteenuse pakkuja eraldab vajaliku sõlme, liitub see klassiga ja on valmis teenindama pod-mooduleid.
4. Kubernetesi planeerija jaotab ootavad moodulid uuele sõlmele. Kui mõned moodulid jäävad pärast seda siiski ootele, kordub protsess – ja klastrisse lisatakse uusi sõlmi.

Automaatne klastrisõlmede määramine pilves

Arvestage järgnevaga, kui kasutate CA:

• CA tagab, et kõigil klastris olevatel moodulitel on käivitamiseks piisavalt ruumi, sõltumata protsessori koormusest. Lisaks püüab see tagada, et klastris ei oleks tarbetuid sõlmi.
• CA registreerib skalaarimise vajaduse umbes 30 sekundi pärast.
• Pärast sõlme muutumist tarbetuks ootab CA vaikimisi 10 minutit, enne kui süsteemi skaleerib.
• Automaatse skaleerimise süsteemis on olemas laienajad (expanders). Need on erinevad strateegiad uute sõlmede rühma valimiseks, kuhu neid lisatakse.
• Kasuta vastutustundlikult valikut cluster-autoscaler.kubernetes.io/safe-to-evict (true). Kui seadistate palju pod’e või kui need on laiali kõikides sõlmedes, kaotate ulatuslikult võimaluse klastrit vähendada.
• Kasutage PodDisruptionBudgets, et vältida pod’ide eemaldamist, mis võib viia teie rakenduse täieliku töökatkestuseni.

Kuidas Kubernetes’i automaatsustamissüsteemid omavahel suhtlevad

Ideaalse tasakaalu saavutamiseks tuleks rakendada automaatsustamist nii pod’ide (HPA/VPA) kui ka klastri tasemel. Need suhtlevad omavahel suhteliselt lihtsalt:

1. HPA või VPA uuendavad pod’ide replikaid või olemasolevatele pod’idele eraldatud ressursse.
2. Kui planeeritud skaleerimiseks jääb sõlmedest puudu, tuvastab CA ootel olevaid pod’e.
3. CA eraldab uusi sõlmi.
4. Modulid jaotatakse uutele sõlmedele.

Kubernetes’i skaleerimise süsteemide koostöö

Tüüpilised vead Kubernetes’i automaatsustamisel

On mitmeid tüüpilisi probleeme, millega DevOps-töötajad silmitsi seisavad, kui nad proovivad automaatsustamist rakendada.

HPA ja VPA sõltuvad mõõdikutest ja mõningatest ajaloolistest andmetest. Kui ressursse on eraldatud liiga vähe, siis moodulid volditakse kokku ja ei suuda mõõdikut genereerida. Sellisel juhul ei toimu automaatsustamine kunagi.

Skaleerimisprotsess on ajasensitiivne. Soovime, et moodulid ja klaster skaleeruks kiiresti — enne, kui kasutajad märkavad probleeme ja tõrkeid. Seetõttu tuleks arvesse võtta pod'ide ja klastrite keskmist skaleerimisaega.

Ideaalne stsenaarium — 4 minutit:

1. 30 sekundit. Sihtmetrikate uuendamine: 30−60 sekundit.
2. 30 sekundit. HPA kontrollib metrikate väärtusi: 30 sekundit.
3. Alla 2 sekundi. Pod moodulid on loodud ja lähevad ooteseisundisse: 1 sekund.
4. Alla 2 sekundi. CA näeb ooteseisundis mooduleid ja saadab kutseid sõlmede ettevalmistamiseks: 1 sekund.
5. 3 minutit. Pilveteenus omab sõlmi. K8s ootab, kuni need on valmis: kuni 10 minutit (sõltub mitmest tegurist).

Halvim (reaalsem) stsenaarium — 12 minutit:

1. 30 sekundit. Sihtmetrikate uuendamine.
2. 30 sekundit. HPA kontrollib metrikate väärtusi.
3. Alla 2 sekundi. Pod moodulid on loodud ja lähevad ooteseisundisse.
4. Alla 2 sekundi. CA näeb ooteseisundis mooduleid ja saadab kutseid sõlmede ettevalmistamiseks.
5. 10 minutit. Pilveteenuse pakkuja eraldab sõlmed. K8s ootab, kuni need on valmis. Ooteaeg sõltub mitmest tegurist, näiteks pakkuja viivitusest, operatsioonisüsteemi viivitusest ja abivahendite toimimisest.

Ärge segage pilveteenuse pakkujate skaleerimise mehhanisme meie CA-ga. Viimane töötab Kubernetes'i klastris, samas kui pilveteenuse pakkuja mehhanism töötab sõlmede jaotamise alusel. See ei tea, mis teie pod'ide või rakendusega toimub. Need süsteemid töötavad paralleelselt.

Kuidas hallata skaleerimist Kubernetes's

1. Kubernetes on ressursside haldamise ja orkestreerimise tööriist. Pod'ide ja klastrite ressursside haldamise toimingud on Kubernetes'e õppimise peamine verstapost.
2. Mõistke pod'ide skaleeritavuse loogikat, arvestades HPA-d ja VPA-d.
3. CA-d tasub kasutada ainult siis, kui mõistate hästi oma pod'ide ja konteinerite vajadusi.
4. Klastri optimaalse seadistamise jaoks on vaja mõista, kuidas erinevad skaleerimissüsteemid koos töötavad.
5. Skaleerimise aja hindamisel pidage silmas halvimat ja parimat stsenaariumi.

Allikas: habr.com