ProHoster > Blogs > Administrācija > TrÄ«s automātiskās mērogoÅ”anas lÄ«meņi programmā Kubernetes: kā tos efektÄ«vi izmantot

TrÄ«s automātiskās mērogoÅ”anas lÄ«meņi programmā Kubernetes: kā tos efektÄ«vi izmantot

TrÄ«s automātiskās mērogoÅ”anas lÄ«meņi programmā Kubernetes: kā tos efektÄ«vi izmantot
Lai pilnÄ«bā apgÅ«tu Kubernetes, jums jāzina dažādi veidi, kā mērogot klastera resursus: pēc pēc sistēmas izstrādātāju domām, tas ir viens no Kubernetes galvenajiem uzdevumiem. Mēs esam snieguÅ”i augsta lÄ«meņa pārskatu par horizontālās un vertikālās automātiskās mērogoÅ”anas un klasteru izmēru maiņas mehānismiem, kā arÄ« ieteikumus, kā tos efektÄ«vi izmantot.

Raksts Kubernetes Autoscaling 101: klasteru automātiskais mērogoÅ”anas lÄ«dzeklis, horizontālais automātiskais mērogotājs un vertikālā poda automātiskais mērogotājs tulkojusi komanda, kas ieviesa automātisko mērogoÅ”anu Kubernetes aaS no Mail.ru.

Kāpēc ir svarÄ«gi domāt par mērogoÅ”anu

Kubernetes - rÄ«ks resursu pārvaldÄ«bai un orÄ·estrÄ“Å”anai. Protams, ir patÄ«kami nodarboties ar lieliskajām podziņu izvietoÅ”anas, uzraudzÄ«bas un pārvaldÄ«bas funkcijām (pods ir konteineru grupa, kas tiek palaista, reaģējot uz pieprasÄ«jumu).

Tomēr jums vajadzētu padomāt arÄ« par Ŕādiem jautājumiem:

  1. Kā mērogot moduļus un lietojumprogrammas?
  2. Kā nodroŔināt konteineru darbību un efektivitāti?
  3. Kā reaģēt uz pastāvīgām izmaiņām kodā un lietotāju darba slodzēm?

Kubernetes klasteru konfigurÄ“Å”ana, lai lÄ«dzsvarotu resursus un veiktspēju, var bÅ«t sarežģīta, un tai ir nepiecieÅ”amas ekspertu zināŔanas par Kubernetes iekŔējo darbÄ«bu. JÅ«su lietojumprogrammas vai pakalpojumu darba slodze var svārstÄ«ties visas dienas garumā vai pat stundas laikā, tāpēc lÄ«dzsvaroÅ”anu vislabāk ir uzskatÄ«t par nepārtrauktu procesu.

Kubernetes automātiskās mērogoÅ”anas lÄ«meņi

EfektÄ«vai automātiskai mērogoÅ”ana prasa koordināciju starp diviem lÄ«meņiem:

  1. Pod līmenis, ieskaitot horizontālo (Horizontal Pod Autoscaler, HPA) un vertikālo autoscaler (Vertical Pod Autoscaler, VPA). Tas mērogoja jūsu konteineriem pieejamos resursus.
  2. Klastera lÄ«menis, ko pārvalda klastera automātiskais mērogoÅ”anas lÄ«dzeklis (CA), kas palielina vai samazina mezglu skaitu klasterÄ«.

Horizontal Autoscaler (HPA) modulis

Kā norāda nosaukums, HPA mērogo podkopiju skaitu. Lielākā daļa devops izmanto CPU un atmiņas slodzi kā aktivizētājus, lai mainītu kopiju skaitu. Tomēr ir iespējams mērogot sistēmu, pamatojoties uz pielāgota metrikaviņu kombinācija vai pat ārējie rādītāji.

Augsta līmeņa HPA darbības diagramma:

  1. HPA nepārtraukti pārbauda instalÄ“Å”anas laikā norādÄ«tās metrikas vērtÄ«bas ar noklusējuma intervālu 30 sekundes.
  2. HPA mēģina palielināt moduļu skaitu, ja tiek sasniegts norādītais slieksnis.
  3. HPA atjaunina reprodukciju skaitu izvietoŔanas/replicēŔanas kontrollerī.
  4. Pēc tam izvietoÅ”anas/replicÄ“Å”anas kontrolleris izvieto visus nepiecieÅ”amos papildu moduļus.

TrÄ«s automātiskās mērogoÅ”anas lÄ«meņi programmā Kubernetes: kā tos efektÄ«vi izmantot
HPA sāk moduļa izvietoŔanas procesu, kad tiek sasniegts metrikas slieksnis

Lietojot HPA, ņemiet vērā:

  • Noklusējuma HPA pārbaudes intervāls ir 30 sekundes. To nosaka karogs horizontālā-pod-autoscaler-sync-period kontroliera pārvaldniekā.
  • Noklusējuma relatÄ«vā kļūda ir 10%.
  • Pēc pēdējā moduļu skaita palielināŔanas HPA sagaida, ka rādÄ«tāji stabilizēsies trÄ«s minÅ«Å”u laikā. Å o intervālu nosaka karogs horizontāls-pod-autoscaler-upscale-delay.
  • Pēc pēdējā moduļu skaita samazināŔanas HPA gaida piecas minÅ«tes, lai stabilizētu. Å o intervālu nosaka karogs horizontal-pod-autoscaler-downscale-delay.
  • HPA vislabāk darbojas ar izvietoÅ”anas objektiem, nevis replikācijas kontrolleriem. Horizontālā automātiskā mērogoÅ”ana nav saderÄ«ga ar ritoÅ”o atjauninājumu, kas tieÅ”i manipulē ar replikācijas kontrolieriem. Izvietojot, reprodukciju skaits ir tieÅ”i atkarÄ«gs no izvietoÅ”anas objektiem.

Pākstu vertikālā automātiskā mērogoÅ”ana

Vertikālā automātiskā mērogoÅ”ana (VPA) esoÅ”ajiem blokiem pieŔķir vairāk (vai mazāk) CPU laika vai atmiņas. Piemērots statusful vai bezvalsts podiem, bet galvenokārt paredzēts statusful pakalpojumiem. Tomēr bezvalsts moduļiem varat izmantot arÄ« VPA, ja nepiecieÅ”ams automātiski pielāgot sākotnēji pieŔķirto resursu apjomu.

VPA arÄ« reaģē uz OOM (out of memory) notikumiem. Lai mainÄ«tu CPU laiku un atmiņu, ir jārestartē podi. Atsākot BPN, tiek ievērots pieŔķīruma budžets (pākstÄ«m izplatÄ«Å”anas budžets, PBP), lai garantētu minimālo nepiecieÅ”amo moduļu skaitu.

Katram modulim var iestatÄ«t minimālos un maksimālos resursus. Tādējādi jÅ«s varat ierobežot maksimālo pieŔķirtās atmiņas apjomu lÄ«dz 8 GB. Tas ir noderÄ«gi, ja paÅ”reizējie mezgli noteikti nevar pieŔķirt vairāk nekā 8 GB atmiņas vienam konteineram. Detalizētas specifikācijas un darbÄ«bas mehānisms ir aprakstÄ«tas oficiālā VPA wiki.

Turklāt VPA ir interesanta ieteikumu funkcija (VPA Recommender). Tas uzrauga resursu izmantoÅ”anu un visu moduļu OOM notikumus, lai ieteiktu jaunas atmiņas un CPU laika vērtÄ«bas, pamatojoties uz inteliÄ£entu algoritmu, kura pamatā ir vēsturiskie rādÄ«tāji. Ir arÄ« API, kas izmanto pod rokturi un atgriež ieteiktās resursu vērtÄ«bas.

Ir vērts atzīmēt, ka VPA Recommender neizseko resursu "limitu". Tā rezultātā modulis var monopolizēt resursus mezglos. Labāk ir iestatīt ierobežojumu nosaukumvietas līmenī, lai izvairītos no milzīga atmiņas vai CPU patēriņa.

Augsta līmeņa VPA darbības shēma:

  1. VPA nepārtraukti pārbauda instalÄ“Å”anas laikā norādÄ«tās metrikas vērtÄ«bas ar noklusējuma intervālu 10 sekundes.
  2. Ja tiek sasniegts norādÄ«tais slieksnis, VPA mēģina mainÄ«t pieŔķirto resursu apjomu.
  3. VPA atjaunina resursu skaitu izvietoŔanas/replicēŔanas kontrollerī.
  4. Kad moduļi tiek restartēti, visi jaunie resursi tiek lietoti izveidotajiem gadījumiem.

TrÄ«s automātiskās mērogoÅ”anas lÄ«meņi programmā Kubernetes: kā tos efektÄ«vi izmantot
VPA pievieno nepiecieŔamo resursu apjomu

LÅ«dzu, ņemiet vērā Ŕādus punktus, izmantojot VPA:

  • Lai mērogotu, ir obligāti jārestartē pods. Tas ir nepiecieÅ”ams, lai izvairÄ«tos no nestabilas darbÄ«bas pēc izmaiņu veikÅ”anas. UzticamÄ«bas labad moduļi tiek restartēti un sadalÄ«ti pa mezgliem, pamatojoties uz tikko pieŔķirtajiem resursiem.
  • VPA un HPA vēl nav saderÄ«gi viens ar otru un nevar darboties vienā un tajā paŔā podā. Ja izmantojat abus mērogoÅ”anas mehānismus vienā klasterÄ«, pārliecinieties, vai iestatÄ«jumi neļauj tos aktivizēt vieniem un tiem paÅ”iem objektiem.
  • VPA noregulē konteineru pieprasÄ«jumus pēc resursiem, pamatojoties tikai uz iepriekŔējo un paÅ”reizējo lietojumu. Tas nenosaka resursu izmantoÅ”anas ierobežojumus. Var rasties problēmas, ja lietojumprogrammas nedarbojas pareizi un sāk pārņemt arvien vairāk resursu, tas novedÄ«s pie tā, ka Kubernetes izslēgs Å”o podiņu.
  • VPA joprojām ir attÄ«stÄ«bas sākuma stadijā. Esiet gatavi tam, ka tuvākajā nākotnē sistēmā var tikt veiktas dažas izmaiņas. JÅ«s varat lasÄ«t par zināmie ierobežojumi Šø attÄ«stÄ«bas plāniem. Tādējādi tiek plānots Ä«stenot VPA un HPA kopÄ«gu darbÄ«bu, kā arÄ« moduļu izvietoÅ”anu kopā ar vertikālās automērogoÅ”anas politiku tiem (piemēram, speciāla etiÄ·ete ā€˜nepiecieÅ”ams VPAā€™).

Kubernetes klastera automātiskā mērogoÅ”ana

Cluster Autoscaler (CA) maina mezglu skaitu, pamatojoties uz gaidÄ«Å”anas bloku skaitu. Sistēma periodiski pārbauda neapstiprinātos moduļus un palielina klastera lielumu, ja nepiecieÅ”ams vairāk resursu un ja klasteris nepārsniedz noteiktos ierobežojumus. CA sazinās ar mākoņpakalpojumu sniedzēju, pieprasa no tā papildu mezglus vai atbrÄ«vo dÄ«kstāves mezglus. Pirmā plaÅ”i pieejamā CA versija tika ieviesta Kubernetes 1.8.

Augsta līmeņa SA darbības shēma:

  1. CA pārbauda neapstiprinātos moduļus pēc noklusējuma 10 sekunžu intervālā.
  2. Ja viens vai vairāki podi atrodas gaidstāves stāvoklÄ«, jo klasterim nav pietiekami daudz pieejamo resursu, lai tos pieŔķirtu, tas mēģina nodroÅ”ināt vienu vai vairākus papildu mezglus.
  3. Kad mākoņpakalpojumu sniedzējs pieŔķir vajadzÄ«go mezglu, tas pievienojas klasterim un ir gatavs apkalpot podi.
  4. Kubernetes plānotājs izplata neapstiprinātos aplikumus jaunam mezglam. Ja pēc tam daži moduļi joprojām paliek gaidÄ«Å”anas stāvoklÄ«, process tiek atkārtots un klasterim tiek pievienoti jauni mezgli.

TrÄ«s automātiskās mērogoÅ”anas lÄ«meņi programmā Kubernetes: kā tos efektÄ«vi izmantot
Automātiska klasteru mezglu nodroŔināŔana mākonī

Lietojot CA, ņemiet vērā tālāk minēto.

  • CA nodroÅ”ina, ka visiem klastera podiem ir vietas, lai tie darbotos neatkarÄ«gi no CPU slodzes. Tas arÄ« cenÅ”as nodroÅ”ināt, lai klasterÄ« nebÅ«tu nevajadzÄ«gu mezglu.
  • CA reÄ£istrē mērogoÅ”anas nepiecieÅ”amÄ«bu pēc aptuveni 30 sekundēm.
  • Kad mezgls vairs nav vajadzÄ«gs, CA pēc noklusējuma gaida 10 minÅ«tes pirms sistēmas mērogoÅ”anas.
  • AutomērogoÅ”anas sistēmai ir paplaÅ”inātāju jēdziens. Tās ir dažādas mezglu grupas atlases stratēģijas, kurām tiks pievienoti jauni mezgli.
  • Izmantojiet opciju atbildÄ«gi cluster-autoscaler.kubernetes.io/safe-to-evict (true). Ja instalējat daudz podziņu vai ja daudzi no tiem ir izkaisÄ«ti visos mezglos, jÅ«s lielā mērā zaudēsit iespēju palielināt kopu.
  • Izmantojiet PodDisruptionBudgetslai novērstu aplikumu dzÄ“Å”anu, kas var izraisÄ«t lietojumprogrammas daļu pilnÄ«gu pārtraukÅ”anu.

Kā Kubernetes autoscalers mijiedarbojas viens ar otru

Lai panāktu perfektu harmoniju, automātiskā mērogoÅ”ana ir jāpiemēro gan pod lÄ«menÄ« (HPA/VPA), gan kopu lÄ«menÄ«. Viņi mijiedarbojas viens ar otru salÄ«dzinoÅ”i vienkārÅ”i:

  1. HPA vai VPA atjaunina pod replikas vai resursus, kas pieŔķirti esoŔajiem podiem.
  2. Ja plānotajai mērogoÅ”anas veikÅ”anai nav pietiekami daudz mezglu, CA pamana, ka ir gaidÄ«Å”anas stāvoklÄ« esoÅ”ie podi.
  3. CA pieŔķir jaunus mezglus.
  4. Moduļi tiek izplatīti jauniem mezgliem.

TrÄ«s automātiskās mērogoÅ”anas lÄ«meņi programmā Kubernetes: kā tos efektÄ«vi izmantot
SadarbÄ«bas Kubernetes mērogoÅ”anas sistēma

IzplatÄ«tas kļūdas Kubernetes automātiskajā mērogoÅ”ana

Pastāv vairākas izplatÄ«tas problēmas, ar kurām devops saskaras, mēģinot ieviest automātisko mērogoÅ”anu.

HPA un VPA ir atkarÄ«gi no rādÄ«tājiem un dažiem vēsturiskiem datiem. Ja tiek pieŔķirti nepietiekami resursi, moduļi tiks samazināti lÄ«dz minimumam un nespēs Ä£enerēt metriku. Å ajā gadÄ«jumā automātiskā mērogoÅ”ana nekad nenotiks.

Pati mērogoÅ”anas darbÄ«ba ir atkarÄ«ga no laika. Mēs vēlamies, lai moduļi un kopa tiktu ātri paplaÅ”ināti ā€” pirms lietotāji pamana problēmas vai kļūmes. Tāpēc jāņem vērā vidējais pākstÄ«m un kopas mērogoÅ”anas laiks.

Ideāls scenārijs - 4 minūtes:

  1. 30 sekundes. MērÄ·a metrikas atjaunināŔana: 30ā€“60 sekundes.
  2. 30 sekundes. HPA pārbauda metrikas vērtības: 30 sekundes.
  3. Mazāk nekā 2 sekundes. Aplikācijas tiek izveidotas un pāriet gaidÄ«Å”anas stāvoklÄ«: 1 sekunde.
  4. Mazāk nekā 2 sekundes. CA redz gaidÄ«Å”anas moduļus un nosÅ«ta zvanus uz nodroÅ”inājuma mezgliem: 1 sekunde.
  5. 3 minÅ«tes. Mākoņu nodroÅ”inātājs pieŔķir mezglus. K8s gaida, lÄ«dz tie ir gatavi: lÄ«dz 10 minÅ«tēm (atkarÄ«bā no vairākiem faktoriem).

Sliktākais (reālāks) scenārijs - 12 minūtes:

  1. 30 sekundes. Atjauniniet mērķa metriku.
  2. 30 sekundes. HPA pārbauda metrikas vērtības.
  3. Mazāk nekā 2 sekundes. Pāksti tiek izveidoti un pāriet gaidīŔanas režīmā.
  4. Mazāk nekā 2 sekundes. CA redz gaidoŔos moduļus un veic zvanus, lai nodroŔinātu mezglus.
  5. 10 minÅ«tes. Mākoņu nodroÅ”inātājs pieŔķir mezglus. K8s gaida, lÄ«dz tie ir gatavi. GaidÄ«Å”anas laiks ir atkarÄ«gs no vairākiem faktoriem, piemēram, pārdevēja aizkaves, OS aizkaves un atbalsta rÄ«kiem.

Nejauciet mākoņpakalpojumu sniedzēju mērogoÅ”anas mehānismus ar mÅ«su CA. Pēdējais darbojas Kubernetes klasterÄ«, savukārt mākoņa nodroÅ”inātāja dzinējs darbojas uz mezglu izplatÄ«Å”anas pamata. Tas nezina, kas notiek ar jÅ«su pākstÄ«m vai lietojumprogrammu. Å Ä«s sistēmas darbojas paralēli.

Kā pārvaldÄ«t mērogoÅ”anu pakalpojumā Kubernetes

  1. Kubernetes ir resursu pārvaldÄ«bas un orÄ·estrÄ“Å”anas rÄ«ks. Operācijas, lai pārvaldÄ«tu aplikumus un klasteru resursus, ir galvenais pavērsiens Kubernetes apgÅ«Å”anā.
  2. Izprotiet pod mērogojamības loģiku, ņemot vērā HPA un VPA.
  3. CA ir jāizmanto tikai tad, ja jums ir laba izpratne par pākstīm un konteineriem.
  4. Lai optimāli konfigurētu klasteri, jums ir jāsaprot, kā dažādas mērogoÅ”anas sistēmas darbojas kopā.
  5. Novērtējot mērogoÅ”anas laiku, ņemiet vērā sliktāko un labāko scenāriju.

Avots: www.habr.com

Pievieno komentāru