Kubernetese automaatse skaleerimise kolm taset: kuidas neid tõhusalt kasutada

Kubernetese automaatse skaleerimise kolm taset: kuidas neid tõhusalt kasutada
Kubernetese täielikuks valdamiseks peate teadma erinevaid viise klastri ressursside skaleerimiseks: by süsteemi arendajate sõnul, see on Kubernetese üks peamisi ülesandeid. Oleme andnud kõrgetasemelise ülevaate horisontaalse ja vertikaalse automaatse skaleerimise ja klastri suuruse muutmise mehhanismidest ning soovitusi nende tõhusaks kasutamiseks.

Artikkel Kubernetes Autoscaling 101: klastri automaatskaalaer, horisontaalne automaatskaalaer ja vertikaalse podi automaatskaalaer tõlkinud meeskond, kes juurutas automaatse skaleerimise Kubernetes aaS saidilt Mail.ru.

Miks on oluline skaleerimisele mõelda?

Kubernetes - tööriist ressursside haldamiseks ja orkestreerimiseks. Muidugi on tore nokitseda kaubikute juurutamise, jälgimise ja haldamise lahedate funktsioonide kallal (pod on rühm konteinereid, mis käivitatakse vastusena taotlusele).

Siiski peaksite mõtlema ka järgmistele küsimustele:

  1. Kuidas mooduleid ja rakendusi skaleerida?
  2. Kuidas hoida konteinerid töökorras ja tõhusana?
  3. Kuidas reageerida pidevatele koodimuutustele ja kasutajate töökoormusele?

Kubernetese klastrite konfigureerimine ressursside ja jõudluse tasakaalustamiseks võib olla keeruline ja nõuab asjatundlikke teadmisi Kubernetese sisemise töö kohta. Teie rakenduse või teenuste töökoormus võib päeva jooksul või isegi tunni jooksul kõikuda, nii et tasakaalustamist on kõige parem käsitleda kui pidevat protsessi.

Kubernetese automaatse skaleerimise tasemed

Tõhus automaatne skaleerimine nõuab kahe taseme koordineerimist:

  1. Podi tase, sealhulgas horisontaalne (Horizontal Pod Autoscaler, HPA) ja vertikaalne automaatskaalaer (Vertical Pod Autoscaler, VPA). See skaleerib teie konteinerite jaoks saadaolevaid ressursse.
  2. Klastri tase, mida haldab Cluster Autoscaler (CA), mis suurendab või vähendab sõlmede arvu klastri sees.

Horizontal Autoscaler (HPA) moodul

Nagu nimigi ütleb, skaleerib HPA kaustade koopiate arvu. Enamik devoppe kasutab koopiate arvu muutmiseks käivitajatena protsessorit ja mälukoormust. Süsteemi on aga võimalik skaleerida selle põhjal kohandatud mõõdikudnende kombinatsioon или даже välised mõõdikud.

Kõrgetasemelise HPA tööskeem:

  1. HPA kontrollib installimise ajal määratud mõõdikuväärtusi pidevalt 30-sekundilise vaikeintervalli järel.
  2. HPA üritab moodulite arvu suurendada, kui määratud lävi on saavutatud.
  3. HPA värskendab juurutamise/replikatsiooni kontrolleris olevate koopiate arvu.
  4. Seejärel juurutab juurutamise/replikatsiooni kontroller kõik vajalikud lisamoodulid.

Kubernetese automaatse skaleerimise kolm taset: kuidas neid tõhusalt kasutada
HPA alustab mooduli juurutusprotsessi, kui saavutatakse meetriline lävi

HPA kasutamisel võtke arvesse järgmist.

  • HPA vaikekontrolli intervall on 30 sekundit. See on seatud lipuga horizontal-pod-autoscaler-sync-period kontrolleri halduris.
  • Vaikimisi on suhteline viga 10%.
  • Pärast viimast moodulite arvu suurendamist eeldab HPA, et mõõdikud stabiliseeruvad kolme minuti jooksul. Selle intervalli määrab lipp horizontal-pod-autoscaler-upscale-delay.
  • Pärast viimast moodulite arvu vähendamist ootab HPA viis minutit, et stabiliseerida. Selle intervalli määrab lipp horizontal-pod-autoscaler-downscale-delay.
  • HPA töötab kõige paremini juurutusobjektidega, mitte replikatsioonikontrolleritega. Horisontaalne automaatne skaleerimine ei ühildu jooksva värskendusega, mis manipuleerib otseselt replikatsioonikontrolleritega. Juurutamisel sõltub koopiate arv otseselt juurutusobjektidest.

Kaunade vertikaalne automaatne skaleerimine

Vertikaalne automaatskaleerimine (VPA) eraldab olemasolevatele kaustadele rohkem (või vähem) protsessori aega või mälu. Sobib olekuga või olekuta kaustadele, kuid mõeldud peamiselt olekupõhiste teenuste jaoks. Siiski saate VPA-d kasutada ka olekuta moodulite jaoks, kui peate automaatselt kohandama algselt eraldatud ressursside hulka.

VPA reageerib ka OOM (mälu otsas) sündmustele. Protsessori aja ja mälu muutmine nõuab kaustade taaskäivitamist. Taaskäivitamisel järgib VPA eraldiste eelarvet (kaunade levitamise eelarve, esialgne eelarveprojekt), et tagada minimaalne nõutav moodulite arv.

Iga mooduli jaoks saate määrata minimaalse ja maksimaalse ressursi. Seega saate piirata eraldatud mälu maksimaalset mahtu 8 GB-ni. See on kasulik, kui praegused sõlmed ei suuda kindlasti eraldada rohkem kui 8 GB mälu konteineri kohta. Üksikasjalikud spetsifikatsioonid ja töömehhanism on kirjeldatud artiklis ametlik VPA viki.

Lisaks on VPA-l huvitav soovitusfunktsioon (VPA Recommender). See jälgib kõigi moodulite ressursikasutust ja OOM-i sündmusi, et soovitada uusi mälu ja protsessori aja väärtusi, mis põhinevad intelligentsel, ajaloolistel mõõdikutel põhineval algoritmil. Samuti on olemas API, mis kasutab pod-käepidet ja tagastab soovitatud ressursiväärtused.

Väärib märkimist, et VPA Recommender ei jälgi ressursi "limiiti". Selle tulemuseks võib olla mooduli ressursside monopoliseerimine sõlmedes. Parem on määrata limiit nimeruumi tasemel, et vältida tohutut mälu- või protsessorikulu.

Kõrgetasemeline VPA tööskeem:

  1. VPA kontrollib installimisel määratud mõõdikuid pidevalt 10-sekundilise vaikeintervalli järel.
  2. Kui määratud lävi saavutatakse, proovib VPA muuta eraldatud ressursside hulka.
  3. VPA värskendab juurutamise/replikatsiooni kontrolleris olevate ressursside arvu.
  4. Kui moodulid taaskäivitatakse, rakendatakse loodud eksemplaridele kõik uued ressursid.

Kubernetese automaatse skaleerimise kolm taset: kuidas neid tõhusalt kasutada
VPA lisab vajaliku hulga ressursse

VPA kasutamisel pidage meeles järgmisi punkte.

  • Skaleerimine nõuab podi kohustuslikku taaskäivitamist. See on vajalik ebastabiilse töö vältimiseks pärast muudatuste tegemist. Usaldusväärsuse huvides taaskäivitatakse moodulid ja jaotatakse sõlmede vahel äsja eraldatud ressursside alusel.
  • VPA ja HPA ei ole veel omavahel ühilduvad ega saa töötada samadel kaustadel. Kui kasutate mõlemat skaleerimismehhanismi samas klastris, veenduge, et teie seaded takistaksid nende aktiveerimist samadel objektidel.
  • VPA häälestab ressursside konteineritaotlusi ainult varasema ja praeguse kasutuse põhjal. See ei sea ressursikasutuse piiranguid. Võib esineda probleeme sellega, et rakendused ei tööta korralikult ja hakkavad üha rohkem ressursse üle võtma, see viib selleni, et Kubernetes lülitab selle podi välja.
  • VPA on alles arengu algfaasis. Olge valmis selleks, et süsteemis võib lähitulevikus toimuda mõningaid muudatusi. Saate lugeda teadaolevad piirangud и arengukavad. Seega on plaanis rakendada VPA ja HPA ühist toimimist, samuti moodulite juurutamist koos vertikaalse automaatse skaleerimise poliitikaga (näiteks spetsiaalne silt "vajab VPA-d").

Kubernetese klastri automaatne skaleerimine

Cluster Autoscaler (CA) muudab sõlmede arvu ootepoodide arvu alusel. Süsteem kontrollib perioodiliselt ootel mooduleid ja suurendab klastri suurust, kui on vaja rohkem ressursse ja kui klaster ei ületa kehtestatud limiite. CA suhtleb pilveteenuse pakkujaga, küsib temalt lisasõlmesid või vabastab jõudeolevad. CA esimene üldiselt saadaolev versioon võeti kasutusele Kubernetes 1.8-s.

SA töö kõrgetasemeline skeem:

  1. CA kontrollib ootel mooduleid vaikeintervalliga 10 sekundit.
  2. Kui üks või mitu kausta on ooterežiimis, kuna klastris ei ole nende eraldamiseks piisavalt ressursse, proovib see varustada üht või mitut täiendavat sõlme.
  3. Kui pilveteenuse pakkuja eraldab vajaliku sõlme, liitub see klastriga ja on valmis kaunasid teenindama.
  4. Kubernetese ajakava jagab ootel olevad kaustad uude sõlme. Kui pärast seda jäävad mõned moodulid endiselt ooteolekusse, korratakse protsessi ja klastrisse lisatakse uued sõlmed.

Kubernetese automaatse skaleerimise kolm taset: kuidas neid tõhusalt kasutada
Klastri sõlmede automaatne varustamine pilves

CA kasutamisel võtke arvesse järgmist.

  • CA tagab, et kõigil klastri kaustadel on töötamiseks ruumi, olenemata protsessori koormusest. Samuti püüab see tagada, et klastris poleks tarbetuid sõlme.
  • CA registreerib skaleerimise vajaduse ligikaudu 30 sekundi pärast.
  • Kui sõlme pole enam vaja, ootab CA vaikimisi 10 minutit enne süsteemi skaleerimist.
  • Automaatsel skaleerimisel on laiendajate kontseptsioon. Need on erinevad strateegiad sõlmede rühma valimiseks, millele uued sõlmed lisatakse.
  • Kasutage valikut vastutustundlikult cluster-autoscaler.kubernetes.io/safe-to-evict (true). Kui installite palju kaunasid või kui paljud neist on kõigis sõlmedes laiali, kaotate suures osas võimaluse klastrit laiendada.
  • Kasutage PodDisruptionBudgetset vältida kaunade kustutamist, mis võib põhjustada teie rakenduse osade täielikku purunemist.

Kuidas Kubernetese automaatskaalarid üksteisega suhtlevad

Täiusliku harmoonia saavutamiseks tuleks automaatset skaleerimist rakendada nii poditasandil (HPA/VPA) kui ka klastri tasemel. Nad suhtlevad üksteisega suhteliselt lihtsalt:

  1. HPA-d või VPA-d värskendavad pod-koopiaid või olemasolevatele kaustadele eraldatud ressursse.
  2. Kui planeeritud skaleerimiseks pole piisavalt sõlmi, märkab CA ooteolekus kaustade olemasolu.
  3. CA eraldab uued sõlmed.
  4. Moodulid jaotatakse uutele sõlmedele.

Kubernetese automaatse skaleerimise kolm taset: kuidas neid tõhusalt kasutada
Kubernetese koostöösüsteem

Levinud vead Kubernetese automaatsel skaleerimisel

On mitmeid levinud probleeme, millega devops automaatse skaleerimise rakendamisel kokku puutub.

HPA ja VPA sõltuvad mõõdikutest ja mõningatest ajaloolistest andmetest. Kui eraldatakse ebapiisavalt ressursse, minimeeritakse moodulid ja need ei saa mõõdikuid genereerida. Sel juhul automaatset skaleerimist kunagi ei toimu.

Skaleerimise toiming ise on ajatundlik. Soovime, et moodulid ja klastrid skaleeriksid kiiresti – enne, kui kasutajad märkavad probleeme või tõrkeid. Seetõttu tuleks arvesse võtta kaunade ja klastri keskmist skaleerimisaega.

Ideaalne stsenaarium – 4 minutit:

  1. 30 sekundit. Sihtmõõdikute värskendamine: 30–60 sekundit.
  2. 30 sekundit. HPA kontrollib mõõdikuid: 30 sekundit.
  3. Vähem kui 2 sekundit. Kaunad luuakse ja lähevad ooteolekusse: 1 sekund.
  4. Vähem kui 2 sekundit. CA näeb ootemooduleid ja saadab kõned pakkumissõlmedele: 1 sekund.
  5. 3 minutit. Pilvepakkuja eraldab sõlmed. K8s ootab, kuni need on valmis: kuni 10 minutit (olenevalt mitmest tegurist).

Halvim (realistlikum) stsenaarium – 12 minutit:

  1. 30 sekundit. Sihtmõõdikute värskendamine.
  2. 30 sekundit. HPA kontrollib mõõdikuid.
  3. Vähem kui 2 sekundit. Kaunad luuakse ja lähevad ooterežiimi.
  4. Vähem kui 2 sekundit. CA näeb ootel olevaid mooduleid ja teeb kõnesid sõlmede varundamiseks.
  5. 10 minutit. Pilveteenuse pakkuja eraldab sõlmed. K8s ootab, kuni nad on valmis. Ooteaeg sõltub mitmest tegurist, nagu tarnija viivitus, OS-i viivitus ja tugitööriistad.

Ärge ajage pilveteenuse pakkujate skaleerimismehhanisme meie CA-ga segamini. Viimane töötab Kubernetese klastri sees, samal ajal kui pilvepakkuja mootor töötab sõlmede levitamise põhimõttel. See ei tea, mis teie kaunade või rakendusega toimub. Need süsteemid töötavad paralleelselt.

Kuidas Kubernetesis skaleerimist hallata

  1. Kubernetes on ressursside haldamise ja orkestreerimise tööriist. Podide ja klastriressursside haldamise toimingud on Kubernetese valdamise oluline verstapost.
  2. Saate aru pod skaleeritavuse loogikast, võttes arvesse HPA ja VPA.
  3. CA-d tuleks kasutada ainult siis, kui mõistate hästi oma kaunade ja konteinerite vajadusi.
  4. Klastri optimaalseks konfigureerimiseks peate mõistma, kuidas erinevad skaleerimissüsteemid koos töötavad.
  5. Skaleerimisaja hindamisel pidage meeles halvimat ja parimat stsenaariumi.

Allikas: www.habr.com

Lisa kommentaar