Kolm automaatse skaleerimise taset Kuberneteses: kuidas neid tõhusalt kasutada

Kubernetesi täielikuks valdamiseks on oluline tundma õppida erinevaid klastrite ressursside skaleerimise meetodeid: süsteemi arendajate sõnul,on see üks Kubernetes'i peamisi ülesandeid. Oleme koostanud kõrgetasemelise ülevaate horisontaalsest ja vertikaalsest automaatse skaleerimisest ning klastrite suuruse muutmisest, samuti soovitusi nende tõhusaks kasutamiseks.

Artikkel Kubernetesi Automaatne Skaleerimine 101: Klastri Automaatne Skaleerija, Horisontaalne Automaatne Skaleerija ja Vertikaalne Pod Automaatne Skaleerija tõlkis meeskond, kes rakendas automaatset skaleerimist Kubernetes aaS Mail.ru-lt.

Miks on oluline mõelda skaleerimisele

Kubernetes — ressursside haldamise ja orkestreerimise tööriist. Loomulikult on tore katsetada võimalusi juurutamiseks, jälgimiseks ja pod'i haldamiseks (pod’i moodul — konteinerite rühm, mida käitatakse vastuseks päringule).

Siiski tuleb mõelda ka järgmistele küsimustele:

1. Kuidas skaleerida mooduleid ja rakendusi?
2. Kuidas hoida konteinereid töövalmis ja tõhusana?
3. Kuidas reageerida pidevatele muudatustele koodis ja kasutajate koormustes?

Kubernetes'i klastrite seadistamine ressursside ja jõudluse tasakaalu saavutamiseks võib olla keeruline ülesanne ning see nõuab ekspertteadmisi Kubernetes'i sisemisest toimimisest. Teie rakenduste või teenuste koormus võib päeva jooksul või isegi tunni jooksul kõikuda, seega on tasakaalustamist parem pidada pidevaks protsessiks.

Kubernetes'i automaatse skaleerimise tasemed

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

1. Pod'ide tase, mis hõlmab horisontaalset (Horisontaalne Pod Automaatne Skaleerija, HPA) ja vertikaalset skaleerimist (Vertikaalne Pod Automaatne Skaleerija, VPA). See on olemasolevate ressursside skaleerimine teie konteinereid.
2. Klastri tase, mida haldab klastrite automaatse skaleerimise süsteem (Klastri Automaatne Skaleerija, CA), mis suurendab või vähendab klastri sees olevate sõlmede arvu.

Horisontaalne automaatse skaleerimise moodul (HPA)

Nimi ütleb kõik, HPA skaleerib pod'ide replikate arvu. Enamik DevOps'dest kasutab replikate arvu muutmiseks protsessori ja mälu koormust. Siiski võib süsteemi skaleerida ka kasutajate metrika põhjal,nende kombinatsioonide või isegi välistest metrikatest..

HPA töö kõrgetasemeline skeem:

1. HPA jälgib pidevalt paigaldamisel määratud meetrikaid, mille vaikeintervall on 30 sekundit.
2. HPA proovib suurendada moodulite arvu, kui on saavutatud määratud läviväärtus.
3. HPA värskendab koopiate arvu juurutamis-/koopiajuhis.
4. Juurutus-/koopiajuhis seejärel juurutab kõik vajalikud täiendavad moodulid.

HPA käivitab moodulite juurutusprotsessi, kui meetrika läviväärtus on saavutatud.

HPA kasutamisel pidage meeles järgmist:

• HPA vaikimisi kontrollimise vahemaa on 30 sekundit. See seadistatakse lipuga. horizontal-pod-autoscaler-sync-period juhija süstemaatikas.
• Vaikimisi suhteline viga on 10%.
• Pärast viime suurendamist HPA ootab meetrikate stabiliseerumist kolm minutit. See vahemaa seadistatakse lipuga. horizontal-pod-autoscaler-upscale-delay.
• Pärast viimast vähendamist HPA ootab stabiliseerumist viie minuti jooksul. See vahemaa seadistatakse lipuga. horizontal-pod-autoscaler-downscale-delay.
• HPA töötab kõige paremini juurutusobjektidega, mitte koopiamanipulaatoritega. Horisontaalne automaatne skaleerimine ei ühildu järjestikuste uuendustega (rolling update), mis manipuleerib otseselt koopiamanipulaatoritega. Juhtumisel sõltub koopiate arv otseselt juurutusobjektidest.

Pod’ide vertikaalne automaatne skaleerimine

Vertikaalne automaatne skaleerimine (VPA) määrab olemasolevatele pod’idele rohkem (või vähem) protsessorit või mälu. Sobib olekuga (stateful) või mitteolekuga (stateless) pod’idele, kuid on peamiselt mõeldud stateful-teenustele. Siiski võite VPA-d rakendada ka olekuta moodulitele, kui on vajalik algse ressursside jaotuse automaatne kohandamine.

VPA reageerib ka OOM (out of memory, mälupuudus) juhtumitele. Protsessorit ja mälu saab muuta ainult pod’ide taaskäivitamisega. Taaskäivitamisel järgib VPA jaotuse eelarvet (pods distribution budget, PDB), et tagada minimaalne moodulite arv.

Saate määrata iga mooduli jaoks minimaalsete ja maksimaalsete ressursihulkade. Näiteks saate piirata eraldatava mälu maksimumi 8 GB. See on kasulik, kui praegused sõlmed ei suuda eraldada rohkem kui 8 GB mälu konteinerile. Üksikasjalikud spetsifikatsioonid ja toimimismehhanism on kirjeldatud ametlikus VPA wikil.

Lisaks on VPA-l huvitav soovituste funktsioon (VPA Recommender). See jälgib moodulite ressursikasutust ja OOM-sündmusi, et pakkuda uusi mälu ja protsessori ajakavasid, tuginedes intelligentses algoritmil, mis arvestab ajaloolisi mõõdikuid. Seal on ka API, mis võtab vastu pod'i deskriptiivi ja tagastab soovitatud ressursihinnad.

Tasub märkida, et VPA Recommender ei jälgi „piirangu” ressursse. See võib viia olukorrani, kus moodul monopoliseerib ressursid sõlmede sees. Parim on seada piirang tasemel nimespetsiifiliselt, et vältida tohutut mälu või protsessorikasutust.

VPA toimimise ülevaade:

1. VPA kontrollib pidevalt installimise ajal saadud mõõdikute väärtusi, vaikimisi 10-sekundiliste intervallidega.
2. Kui saavutatakse määratud lävi, püüab VPA muuta eraldatud ressursihulka.
3. VPA uuendab ressursihulka juurutamise/kopeerimise kontrolleris.
4. Moodulite taaskäivitamisel rakendatakse kõik uued ressursid loodud instantsidele.

VPA lisab vajaliku hulk ressursse

Arvestage VPA kasutamisel järgmiste punktidega:

• Mastaapimine nõuab pod'i kohustuslikku taaskäivitamist. See on vajalik, et vältida ebastabiilset toimimist pärast muudatuste tegemist. Usaldusväärsuse tõttu taaskäivitavad moodulid ja jaotavad uued ressursid sõlmede vahel.
• VPA ja HPA pole hetkel üksteisega ühilduvad ja ei saa töötada samades pod'ides. Kui kasutate ühes klastris mõlemaid mastaapimise mehhanisme, veenduge, et seadistused ei võimalda neil aktiveeruda samade objektide peal.
• VPA kohandab konteinerite ressursikšid seoses ainult nende varasema ja praeguse kasutamisega. Ta ei sea ressursikasutusele piire. Võivad tekkida probleemid rakenduste ebakorrektses töötamises, mis hakkavad haarama üha rohkem ressursse, mis toob kaasa selle, et Kubernetes keelab antud podi.
• VPA on endiselt arenduse varases staadiumis. Ole valmis, et süsteem võib lähitulevikus mõningaid muutusi kogeda. Saate lugeda tuntud piirangutest ja arendusuplandest. Nii on plaanis ellu viia VPA ja HPA koostööd ning ka moodulite käivitamine koos nende jaoks mõeldud vertikaalse automaatmõõtmise poliitikaga (näiteks spetsiaalne silt ‘requires VPA’).

Kubernetes klastrite automaatmõõtmine

Klastri automaatmõõtmine (Cluster Autoscaler, CA) muudab sõlmede arvu, lähtudes ootel olevate podi moodulite arvust. Süsteem kontrollib regulaarselt, kas on ootavaid mooduleid — ja suurendab klastri mahtu, kui on vaja rohkem ressursse ja kui klaster ei ületa seatud piire. CA suhtleb pilveteenuse pakkujaga, küsib temalt täiendavaid sõlmi või vabastab inaktiivsed. CA esimene avalik versioon esitati Kubernetes 1.8.

CA töö kõrgema taseme skeem:

1. CA kontrollib iga 10 sekundi järel, kas ootel on mooduleid.
2. Kui üks või mitu moodulit on ootel, kuna klastris ei ole piisavalt vabu ressursse nende jaotamiseks, üritab ta ette valmistada ühe või mitu täiendavat sõlme.
3. Kui pilveteenuse pakkuja eraldab vajaliku sõlme, liitub see klassiga ja on valmis teenindama podi mooduleid.
4. Kubernetes'i planeerija jaotab ootel moodulid uuele sõlmele. Kui pärast seda jäävad mõned moodulid ikka ootele, kordub protsess ja klastrisse lisatakse uusi sõlmi.

Automaatne sõlmede jaotamine pilves

Kaasake järgmised punktid CA kasutamisel:

• CA tagab, et kõigil klastris olevatel moodulitel on käivitamiseks ruumi, sõltumata protsessori koormuse tasemest. Lisaks üritab ta tagada, et klastris ei oleks ebavajalikke sõlmi.
• CA registreerib vajaduse skaleerimise järele umbes 30 sekundi pärast.
• Kui sõlm enam ei ole vajalik, ootab CA vaikimisi 10 minutit, enne kui süsteemi skaleerib.
• Automaatse skaleerimise süsteemis on olemas laiendajad (expanders). Need on erinevad strateegiad, et valida sõlmede grupp, kuhu uusi sõlmi lisada.
• Kohustuste kohaselt rakendage valikut cluster-autoscaler.kubernetes.io/safe-to-evict (true). Kui seadistate palju pod’e või kui paljusid neist hajutatakse kõikide sõlmede vahel, kaotate suuresti võimaluse klastrit vähendada.
• Kasutage PodDisruptionBudgets, et vältida pod’ide eemaldamist, mis võib täielikult häirida teie rakenduse osa.

Kuidas Kubernetes'i automaatne skaleerimine omavahel suhtleb

Ideaalne harmoonia saavutamiseks tuleks rakendada automaatset skaleerimist nii pod’ide tasemel (HPA/VPA) kui ka klastritasemel. Need suhtlevad omavahel suhteliselt lihtsalt:

1. HPA või VPA uuendavad pod’ide koopiaid või olemasolevatele pod’idele eraldatud ressursse.
2. Kui kavandatud skaleerimiseks pole piisavalt sõlmi, märkab CA ooteolekus pod’e.
3. CA eraldab uus sõlmed.
4. Moodulid jaotatakse uutele sõlmedele.

Kubernetes'i skaleerimisüsteemide ühisne süsteem

Tüüpilised vead Kubernetes'i automaatse skaleerimise puhul

On mitmeid tüüpilisi probleeme, millega devops'id silmitsi seisavad, kui nad püüavad automaatset skaleerimist rakendada.

HPA ja VPA sõltuvad mõõdikutest ja teatud ajalooandmetest. Kui ressursse on eraldatud liiga vähe, volditakse moodulid kokku ja nad ei suuda genereerida mõõdikuid. Sellisel juhul ei toimu automaatset skaleerimist kunagi.

Skaleerimisoperatsioon ise on ajalooliselt oluline. Soovime, et moodulid ja klaster skaleeruksid kiiresti — enne, kui kasutajad märkavad mingeid probleeme ja tõrkeid. Seetõttu tuleks arvesse võtta pod’ide ja klastrite keskmist skaleerimisaega.

Ideaalne stsenaarium — 4 minutit:

1. 30 sekundit. Sihtmõõdikute uuendamine: 30−60 sekundit.
2. 30 sekundit. HPA kontrollib mõõdikute väärtusi: 30 sekundit.
3. Alla 2 sekundi. Pod moodulid loodud ja liiguvad ooteolekusse: 1 sekund.
4. Alla 2 sekundi. CA näeb ooteolekus mooduleid ja saadab kutsed sõlmede ettevalmistamiseks: 1 sekund.
5. 3 minutit. Pilveteenuse pakkuja eraldab sõlmed. K8s ootab, kuni need on valmis: kuni 10 minutit (sõltub mitmest tegurist).

Halvim (reaalsem) stsenaarium — 12 minutit:

1. 30 sekundit. Sihtmärkide uuendamine.
2. 30 sekundit. HPA kontrollib mõõdikute väärtusi.
3. Alla 2 sekundi. Pod-moodulid on loodud ja liiguvad ooterežiimi.
4. Alla 2 sekundi. CA näeb ooterežiimis mooduleid ja saadab sõlmede ettevalmistamiseks kutseid.
5. 10 minutit. Pilveteenuse pakkuja eraldab sõlmed. K8s ootab, kuni need on valmis. Ooteaeg sõltub mitmest tegurist, näiteks teenusepakkuja viivitusest, opsüsteemi viivitusest, abivahendite toimimisest.

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

Kuidas hallata skaleerimist Kubernetes'is

1. Kubernetes on ressursside haldamise ja orkestreerimise tööriist. Pod'ide ja klastrite ressursside haldamise operatsioonid on Kubernetes'e õppimise põhialus.
2. Omastage pod'ide skaleeritavuse loogika HPA ja VPA arvestades.
3. CA-d tasub kasutada ainult siis, kui mõistate hästi oma pod'ide ja konteinerite vajadusi.
4. Klastri optimaalseks seadistamiseks tuleb mõista, kuidas erinevad skaleerimissüsteemid koos töötavad.
5. Skaleerimise aja hindamisel pidage meeles halvimat ja parimat stsenaariumi.

Allikas: habr.com