Norėdami visiškai įvaldyti „Kubernetes“, turite žinoti skirtingus klasterio išteklių mastelio keitimo būdus: pagal , tai viena pagrindinių Kubernetes užduočių. Pateikėme aukšto lygio horizontalaus ir vertikalaus automatinio mastelio keitimo ir grupių dydžio keitimo mechanizmų apžvalgą bei rekomendacijas, kaip juos efektyviai naudoti.
Straipsnis išvertė komanda, įdiegusi automatinį mastelį .
Kodėl svarbu galvoti apie mastelio keitimą
- išteklių valdymo ir orkestravimo įrankis. Žinoma, malonu padirbėti su šauniomis podelių diegimo, stebėjimo ir valdymo funkcijomis (dėklas yra konteinerių grupė, kuri paleidžiama pagal užklausą).
Tačiau taip pat turėtumėte pagalvoti apie šiuos klausimus:
- Kaip pakeisti modulių ir programų mastelį?
- Kaip užtikrinti, kad konteineriai veiktų ir veiktų efektyviai?
- Kaip reaguoti į nuolatinius kodo pokyčius ir vartotojų darbo krūvius?
„Kubernetes“ grupių konfigūravimas siekiant suderinti išteklius ir našumą gali būti sudėtingas ir reikalauja ekspertų žinių apie vidinį „Kubernetes“ veikimą. Jūsų programos ar paslaugų darbo krūvis gali svyruoti visą dieną ar net valandą, todėl balansavimą geriausia laikyti nuolatiniu procesu.
Kubernetes automatinio mastelio keitimo lygiai
Veiksmingam automatiniam mastelio keitimui reikalingas dviejų lygių koordinavimas:
- Pod lygis, įskaitant horizontalųjį (Horizontal Pod Autoscaler, HPA) ir vertikalųjį automatinį skalerį (Vertical Pod Autoscaler, VPA). Tai sumažina galimus jūsų sudėtinių rodinių išteklius.
- Klasterio lygis, kurį valdo Cluster Autoscaler (CA), kuris padidina arba sumažina mazgų skaičių klasteryje.
Horizontalus automatinio mastelio (HPA) modulis
Kaip rodo pavadinimas, HPA padidina ankšties kopijų skaičių. Dauguma „devop“ naudoja procesoriaus ir atminties apkrovą kaip paleidiklius, kad pakeistų kopijų skaičių. Tačiau galima keisti sistemos mastelį , jų или даже .
Aukšto lygio HPA veikimo schema:
- HPA nuolat tikrina matavimo reikšmes, nurodytas diegimo metu, numatytuoju 30 sekundžių intervalu.
- HPA bando padidinti modulių skaičių, jei pasiekiamas nurodytas slenkstis.
- HPA atnaujina kopijų skaičių diegimo / replikacijos valdiklyje.
- Tada diegimo / replikacijos valdiklis diegia visus būtinus papildomus modulius.
HPA pradeda modulio diegimo procesą, kai pasiekiama metrinė riba
Naudodami HPA, atsižvelkite į šiuos dalykus:
- Numatytasis HPA tikrinimo intervalas yra 30 sekundžių. Jį nustato vėliava horizontalus-pod-autoscaler-sync-period valdiklio vadove.
- Numatytoji santykinė klaida yra 10%.
- Po paskutinio modulių skaičiaus padidinimo HPA tikisi, kad rodikliai stabilizuosis per tris minutes. Šis intervalas nustatomas vėliava horizontalus-pod-autoscaler-upscale-delay.
- Po paskutinio modulių skaičiaus sumažinimo HPA laukia penkias minutes, kol stabilizuosis. Šis intervalas nustatomas vėliava horizontalus-pod-autoscaler-downscale-delay.
- HPA geriausiai veikia su diegimo objektais, o ne su replikacijos valdikliais. Horizontalus automatinis mastelio keitimas nesuderinamas su nuolatiniu atnaujinimu, kuris tiesiogiai manipuliuoja replikacijos valdikliais. Diegiant, kopijų skaičius tiesiogiai priklauso nuo diegimo objektų.
Vertikalus ankščių automatinis skalavimas
Vertikalus automatinis mastelio keitimas (VPA) skiria daugiau (arba mažiau) procesoriaus laiko arba atminties esamiems blokams. Tinka būsenos arba be būsenos ankštims, bet daugiausia skirta būsenos paslaugoms. Tačiau taip pat galite naudoti VPA moduliams be būsenos, jei reikia automatiškai koreguoti iš pradžių skirtų išteklių kiekį.
VPA taip pat reaguoja į OOM (out of memory) įvykius. Norint pakeisti procesoriaus laiką ir atmintį, reikia iš naujo paleisti blokus. Iš naujo paleidus VPA atsižvelgiama į paskirstymo biudžetą (), kad būtų garantuotas minimalus reikiamas modulių skaičius.
Kiekvienam moduliui galite nustatyti minimalius ir maksimalius išteklius. Taigi galite apriboti didžiausią skiriamos atminties kiekį iki 8 GB. Tai naudinga, jei dabartiniai mazgai tikrai negali skirti daugiau nei 8 GB atminties vienam konteineriui. Išsamios specifikacijos ir veikimo mechanizmas aprašyti .
Be to, VPA turi įdomią rekomendacijų funkciją (VPA Recommender). Jis stebi išteklių naudojimą ir visų modulių OOM įvykius, kad pasiūlytų naujas atminties ir procesoriaus laiko reikšmes, pagrįstas intelektualiu algoritmu, pagrįstu istorine metrika. Taip pat yra API, kuri perima pod rankeną ir grąžina siūlomas išteklių reikšmes.
Verta paminėti, kad VPA Recommender neseka išteklių „ribos“. Dėl to modulis gali monopolizuoti išteklius mazguose. Geriau nustatyti ribą vardų erdvės lygiu, kad išvengtumėte didžiulio atminties ar procesoriaus suvartojimo.
Aukšto lygio VPA veikimo schema:
- VPA nuolat tikrina matavimo reikšmes, nurodytas diegimo metu, numatytuoju 10 sekundžių intervalu.
- Pasiekus nurodytą slenkstį, VPA bando pakeisti skiriamą išteklių kiekį.
- VPA atnaujina išteklių skaičių diegimo / replikacijos valdiklyje.
- Kai moduliai paleidžiami iš naujo, sukurtiems egzemplioriams pritaikomi visi nauji ištekliai.
VPA prideda reikiamą kiekį išteklių
Naudodami VPA atminkite šiuos dalykus:
- Norint pakeisti mastelį, reikia iš naujo paleisti bloką. Tai būtina norint išvengti nestabilaus veikimo po pakeitimų. Siekiant patikimumo, moduliai paleidžiami iš naujo ir paskirstomi mazguose pagal naujai paskirtus išteklius.
- VPA ir HPA dar nesuderinami vienas su kitu ir negali veikti tuose pačiuose moduliuose. Jei naudojate abu mastelio keitimo mechanizmus tame pačiame klasteryje, įsitikinkite, kad nustatymai neleidžia jų suaktyvinti tuose pačiuose objektuose.
- VPA derina konteinerių užklausas dėl išteklių tik pagal ankstesnį ir dabartinį naudojimą. Jis nenustato išteklių naudojimo apribojimų. Gali kilti problemų dėl netinkamai veikiančių programų ir pradedančių perimti vis daugiau išteklių, todėl „Kubernetes“ išjungs šį bloką.
- VPA vis dar yra ankstyvoje kūrimo stadijoje. Būkite pasirengę, kad artimiausiu metu sistema gali pasikeisti. Galite perskaityti apie и . Taigi planuojama įgyvendinti bendrą VPA ir HPA veikimą, taip pat diegti modulius kartu su vertikalaus automatinio mastelio keitimo politika (pavyzdžiui, speciali etiketė „reikia VPA“).
Automatinis Kubernetes klasterio mastelio keitimas
Cluster Autoscaler (CA) pakeičia mazgų skaičių pagal laukiančių grupių skaičių. Sistema periodiškai tikrina laukiančius modulius ir padidina klasterio dydį, jei reikia daugiau išteklių ir jei klasteris neviršija nustatytų ribų. CA bendrauja su debesijos paslaugų teikėju, prašo papildomų mazgų arba išleidžia neveikiančius mazgus. Pirmoji visuotinai prieinama CA versija buvo pristatyta Kubernetes 1.8 versijoje.
Aukšto lygio SA veikimo schema:
- CA tikrina laukiančius modulius numatytuoju 10 sekundžių intervalu.
- Jei vienas ar daugiau blokų yra budėjimo būsenoje, nes klasteris neturi pakankamai išteklių jiems paskirstyti, jis bando numatyti vieną ar daugiau papildomų mazgų.
- Kai debesijos paslaugų teikėjas paskiria reikiamą mazgą, jis prisijungia prie klasterio ir yra pasirengęs aptarnauti ankštis.
- Kubernetes planavimo priemonė paskirsto laukiančius blokus naujam mazgui. Jei po to kai kurie moduliai vis dar lieka laukimo būsenoje, procesas kartojamas ir į klasterį įtraukiami nauji mazgai.
Automatinis klasterio mazgų aprūpinimas debesyje
Naudodami CA atsižvelkite į šiuos dalykus:
- CA užtikrina, kad visi grupės blokai turėtų vietos veikti, nepaisant procesoriaus apkrovos. Taip pat bandoma užtikrinti, kad klasteryje nebūtų nereikalingų mazgų.
- CA užregistruoja poreikį keisti mastelį maždaug po 30 sekundžių.
- Kai mazgas nebereikalingas, CA pagal numatytuosius nustatymus laukia 10 minučių prieš sumažindama sistemos mastelį.
- Automatinio mastelio keitimo sistema turi plėtiklių koncepciją. Tai skirtingos mazgų grupės, prie kurios bus pridedami nauji mazgai, pasirinkimo strategijos.
- Naudokitės pasirinkimu atsakingai cluster-autoscaler.kubernetes.io/safe-to-evict (true). Jei įdiegsite daug ankšties arba jei daugelis iš jų yra išsklaidytos visuose mazguose, iš esmės prarasite galimybę išplėsti grupę.
- Naudokite kad būtų išvengta ankšties ištrynimo, nes dėl to kai kurios programos gali visiškai sugesti.
Kaip „Kubernetes“ automatiniai skalės įrenginiai sąveikauja tarpusavyje
Norint pasiekti tobulą harmoniją, automatinis mastelio keitimas turėtų būti taikomas ir pod (HPA/VPA), ir klasterio lygiu. Jie sąveikauja vienas su kitu gana paprastai:
- HPA arba VPA atnaujina priedų kopijas arba esamoms grupėms skirtus išteklius.
- Jei nėra pakankamai mazgų planuojamam mastelio keitimui, CA pastebi, kad ankštys yra laukiančios būsenos.
- CA skiria naujus mazgus.
- Moduliai paskirstomi naujiems mazgams.
Bendradarbiaujanti „Kubernetes“ padidinimo sistema
Dažnos Kubernetes automatinio skalavimo klaidos
Yra keletas bendrų problemų, su kuriomis „devops“ susiduria bandydami įdiegti automatinį mastelio keitimą.
HPA ir VPA priklauso nuo metrikos ir kai kurių istorinių duomenų. Jei nebus skirta pakankamai išteklių, moduliai bus sumažinti ir negalės generuoti metrikos. Šiuo atveju automatinis mastelio keitimas niekada neįvyks.
Pati mastelio keitimo operacija yra jautri laikui. Norime, kad moduliai ir klasteris greitai padidėtų – naudotojams nepastebėjus jokių problemų ir gedimų. Todėl reikia atsižvelgti į vidutinį ankščių ir grupės mastelio keitimo laiką.
Idealus scenarijus – 4 minutės:
- 30 sekundžių. Atnaujinti tikslinę metriką: 30–60 sekundžių.
- 30 sekundžių. HPA tikrina metrines reikšmes: 30 sekundžių.
- Mažiau nei 2 sekundes. Ankštys sukuriamos ir pereina į laukimo būseną: 1 sekundė.
- Mažiau nei 2 sekundes. CA mato laukiančius modulius ir siunčia skambučius į aprūpinimo mazgus: 1 sekundė.
- 3 minutes. Debesų paslaugų teikėjas skiria mazgus. K8s laukia, kol bus paruošti: iki 10 minučių (priklauso nuo kelių veiksnių).
Blogiausias (tikresnis) scenarijus – 12 minučių:
- 30 sekundžių. Atnaujinkite tikslinę metriką.
- 30 sekundžių. HPA tikrina metrines reikšmes.
- Mažiau nei 2 sekundes. Ankštys sukuriamos ir pereina į budėjimo būseną.
- Mažiau nei 2 sekundes. CA mato laukiančius modulius ir iškviečia mazgus.
- 10 minučių. Debesų paslaugų teikėjas skiria mazgus. K8s laukia, kol bus paruošti. Laukimo laikas priklauso nuo kelių veiksnių, pvz., tiekėjo delsos, OS delsos ir palaikymo įrankių.
Nepainiokite debesų paslaugų teikėjų mastelio keitimo mechanizmų su mūsų CA. Pastarasis veikia „Kubernetes“ klasteryje, o debesies teikėjo variklis veikia mazgo paskirstymo pagrindu. Jis nežino, kas vyksta su jūsų ankštimis ar programa. Šios sistemos veikia lygiagrečiai.
Kaip valdyti mastelio keitimą „Kubernetes“.
- Kubernetes yra išteklių valdymo ir orkestravimo įrankis. Pods ir klasterio išteklių valdymo operacijos yra pagrindinis Kubernetes įsisavinimo etapas.
- Supraskite pod mastelio logiką atsižvelgiant į HPA ir VPA.
- CA turėtų būti naudojamas tik tuo atveju, jei gerai suprantate savo ankščių ir talpyklų poreikius.
- Norėdami optimaliai sukonfigūruoti grupę, turite suprasti, kaip skirtingos mastelio keitimo sistemos veikia kartu.
- Apskaičiuodami mastelio keitimo laiką, turėkite omenyje blogiausio ir geriausio atvejo scenarijus.
Šaltinis: www.habr.com