Pentru a stăpâni pe deplin Kubernetes, trebuie să cunoașteți diferite moduri de a scala resursele clusterului: prin , aceasta este una dintre sarcinile principale ale Kubernetes. Am oferit o prezentare generală la nivel înalt a mecanismelor de scalare automată orizontală și verticală și de redimensionare a clusterelor, precum și recomandări despre cum să le folosiți eficient.
articol tradus de echipa care a implementat autoscaling în .
De ce este important să ne gândim la scalare
- un instrument pentru managementul resurselor și orchestrare. Bineînțeles, este plăcut să te chinuiești cu caracteristicile interesante de implementare, monitorizare și gestionare a podurilor (un pod este un grup de containere care sunt lansate ca răspuns la o solicitare).
Cu toate acestea, ar trebui să vă gândiți și la următoarele întrebări:
- Cum să scalați modulele și aplicațiile?
- Cum să menținem containerele operaționale și eficiente?
- Cum să răspundeți la modificările constante ale codului și ale sarcinilor de lucru de la utilizatori?
Configurarea clusterelor Kubernetes pentru a echilibra resursele și performanța poate fi o provocare și necesită cunoștințe de specialitate cu privire la funcționarea interioară a Kubernetes. Volumul de lucru al aplicației sau serviciilor dvs. poate fluctua pe parcursul zilei sau chiar într-o oră, așa că echilibrarea este cel mai bine gândită ca un proces continuu.
Niveluri de autoscaling Kubernetes
Autoscaling eficient necesită coordonare între două niveluri:
- Nivelul podului, inclusiv autoscaler orizontal (Horizontal Pod Autoscaler, HPA) și vertical (Vertical Pod Autoscaler, VPA). Aceasta înseamnă scalarea resurselor disponibile pentru containerele dvs.
- Nivelul clusterului, care este gestionat de Cluster Autoscaler (CA), care crește sau scade numărul de noduri din cluster.
Modul Horizontal Autoscaler (HPA).
După cum sugerează și numele, HPA mărește numărul de replici ale podului. Majoritatea devopilor folosesc CPU și încărcarea memoriei ca declanșatori pentru modificarea numărului de replici. Cu toate acestea, este posibil să scalați sistemul pe baza , lor sau .
Diagrama de funcționare HPA de nivel înalt:
- HPA verifică continuu valorile metrice specificate în timpul instalării la un interval implicit de 30 de secunde.
- HPA încearcă să mărească numărul de module dacă este atins pragul specificat.
- HPA actualizează numărul de replici din controlerul de implementare/replicare.
- Controlerul de implementare/replicare implementează apoi orice module suplimentare necesare.
HPA începe procesul de implementare a modulului când este atins un prag de metrică
Când utilizați HPA, luați în considerare următoarele:
- Intervalul implicit de verificare HPA este de 30 de secunde. Este stabilit de steag orizontal-pod-autoscaler-perioada-sincronizare în managerul controlorului.
- Eroarea relativă implicită este 10%.
- După ultima creștere a numărului de module, HPA se așteaptă ca valorile să se stabilizeze în trei minute. Acest interval este stabilit de steag orizontal-pod-autoscaler-upscale-delay.
- După ultima reducere a numărului de module, HPA așteaptă cinci minute pentru a se stabiliza. Acest interval este stabilit de steag orizontal-pod-autoscaler-downscale-delay.
- HPA funcționează cel mai bine cu obiecte de implementare, mai degrabă decât cu controlere de replicare. Autoscaling orizontal este incompatibil cu actualizarea continuă, care manipulează direct controlerele de replicare. Odată cu implementarea, numărul de replici depinde direct de obiectele de implementare.
Autoscalare verticală a podurilor
Scalare automată verticală (VPA) alocă mai mult (sau mai puțin) timp CPU sau memorie podurilor existente. Potrivit pentru pod-uri cu stat sau fără stat, dar destinat în principal serviciilor cu stat. Cu toate acestea, puteți utiliza și VPA pentru modulele apatride dacă trebuie să ajustați automat cantitatea de resurse alocate inițial.
VPA răspunde și la evenimentele OOM (memorie lipsită). Modificarea timpului CPU și a memoriei necesită repornirea pod-urilor. La repornire, APV respectă bugetul de alocare () pentru a garanta numărul minim necesar de module.
Puteți seta resursele minime și maxime pentru fiecare modul. Astfel, puteți limita cantitatea maximă de memorie alocată la 8 GB. Acest lucru este util dacă nodurile actuale cu siguranță nu pot aloca mai mult de 8 GB de memorie per container. Specificațiile detaliate și mecanismul de operare sunt descrise în .
În plus, VPA are o funcție interesantă de recomandare (VPA Recommender). Monitorizează utilizarea resurselor și evenimentele OOM ale tuturor modulelor pentru a sugera noi valori de memorie și de timp CPU bazate pe un algoritm inteligent bazat pe valori istorice. Există, de asemenea, un API care preia un handle de pod și returnează valorile de resurse sugerate.
Este de remarcat faptul că VPA Recommender nu urmărește „limita” de resurse. Acest lucru poate duce la monopolizarea resurselor de către modulul în noduri. Este mai bine să setați limita la nivelul spațiului de nume pentru a evita consumul uriaș de memorie sau CPU.
Schema de operare VPA la nivel înalt:
- VPA verifică continuu valorile metrice specificate în timpul instalării la un interval implicit de 10 secunde.
- Dacă pragul specificat este atins, VPA încearcă să modifice cantitatea alocată de resurse.
- VPA actualizează numărul de resurse din controlerul de implementare/replicare.
- Când modulele sunt repornite, toate resursele noi sunt aplicate instanțelor create.
VPA adaugă cantitatea necesară de resurse
Vă rugăm să țineți cont de următoarele puncte atunci când utilizați VPA:
- Scalare necesită o repornire obligatorie a podului. Acest lucru este necesar pentru a evita funcționarea instabilă după efectuarea modificărilor. Pentru fiabilitate, modulele sunt repornite și distribuite între noduri pe baza resurselor nou alocate.
- VPA și HPA nu sunt încă compatibile între ele și nu pot rula pe aceleași poduri. Dacă utilizați ambele mecanisme de scalare în același cluster, asigurați-vă că setările dvs. împiedică activarea lor pe aceleași obiecte.
- VPA reglează solicitările de container pentru resurse pe baza utilizării anterioare și curente. Nu stabilește limite de utilizare a resurselor. Pot apărea probleme cu aplicațiile care nu funcționează corect și încep să preia din ce în ce mai multe resurse, acest lucru va duce la oprirea acestui pod de către Kubernetes.
- VPA este încă într-un stadiu incipient de dezvoltare. Fiți pregătiți că sistemul poate suferi unele modificări în viitorul apropiat. Puteți citi despre и . Astfel, există planuri de implementare a funcționării comune a VPA și HPA, precum și implementarea modulelor împreună cu o politică de autoscaling vertical pentru acestea (de exemplu, o etichetă specială „necesită VPA”).
Scalare automată a unui cluster Kubernetes
Cluster Autoscaler (CA) modifică numărul de noduri în funcție de numărul de poduri de așteptare. Sistemul verifică periodic modulele în așteptare - și mărește dimensiunea clusterului dacă sunt necesare mai multe resurse și dacă clusterul nu depășește limitele stabilite. CA comunică cu furnizorul de servicii cloud, îi solicită noduri suplimentare sau le eliberează pe cele inactive. Prima versiune general disponibilă a CA a fost introdusă în Kubernetes 1.8.
Schema la nivel înalt de operare SA:
- CA verifică modulele în așteptare la un interval implicit de 10 secunde.
- Dacă unul sau mai multe pod-uri sunt într-o stare de așteptare, deoarece clusterul nu are suficiente resurse disponibile pentru a le aloca, acesta încearcă să furnizeze unul sau mai multe noduri suplimentare.
- Când furnizorul de servicii cloud alocă nodul necesar, acesta se alătură clusterului și este gata să servească pod-urile.
- Programatorul Kubernetes distribuie pod-uri în așteptare către un nou nod. Dacă după aceasta unele module rămân în continuare în stare de așteptare, procesul se repetă și se adaugă noi noduri la cluster.
Aprovizionarea automată a nodurilor de cluster în cloud
Luați în considerare următoarele când utilizați CA:
- CA se asigură că toate podurile din cluster au spațiu de rulare, indiferent de încărcarea procesorului. De asemenea, încearcă să se asigure că nu există noduri inutile în cluster.
- CA înregistrează nevoia de scalare după aproximativ 30 de secunde.
- Odată ce un nod nu mai este necesar, CA așteaptă implicit 10 minute înainte de a extinde sistemul.
- Sistemul de autoscaling are conceptul de expandare. Acestea sunt strategii diferite pentru selectarea unui grup de noduri la care vor fi adăugate noi noduri.
- Utilizați opțiunea în mod responsabil cluster-autoscaler.kubernetes.io/safe-to-evict (adevărat). Dacă instalați o mulțime de pod-uri sau dacă multe dintre ele sunt împrăștiate pe toate nodurile, veți pierde în mare măsură capacitatea de a extinde clusterul.
- utilizare pentru a preveni ștergerea podurilor, ceea ce ar putea duce la eșuarea completă a unor părți ale aplicației dvs.
Cum interacționează autoscalerele Kubernetes între ele
Pentru o armonie perfectă, scalarea automată ar trebui aplicată atât la nivel de pod (HPA/VPA), cât și la nivel de cluster. Ei interacționează unul cu celălalt relativ simplu:
- HPA-urile sau VPA-urile actualizează replicile pod-urilor sau resursele alocate pod-urilor existente.
- Dacă nu există suficiente noduri pentru scalarea planificată, CA observă prezența podurilor în stare de așteptare.
- CA alocă noduri noi.
- Modulele sunt distribuite către noduri noi.
Sistem de scalare-out colaborativ Kubernetes
Greșeli frecvente în scalarea automată Kubernetes
Există mai multe probleme comune cu care se confruntă devops atunci când încearcă să implementeze autoscaling.
HPA și VPA depind de valori și de unele date istorice. Dacă sunt alocate resurse insuficiente, modulele vor fi minimizate și nu vor putea genera metrici. În acest caz, autoscaling nu se va întâmpla niciodată.
Operația de scalare în sine este sensibilă la timp. Dorim ca modulele și clusterul să se scaleze rapid - înainte ca utilizatorii să observe probleme sau defecțiuni. Prin urmare, timpul mediu de scalare pentru păstăi și cluster ar trebui să fie luat în considerare.
Scenariul ideal - 4 minute:
- 30 de secunde. Actualizați valorile vizate: 30-60 de secunde.
- 30 de secunde. HPA verifică valorile metrice: 30 de secunde.
- Mai puțin de 2 secunde. Podurile sunt create și intră în starea de așteptare: 1 secundă.
- Mai puțin de 2 secunde. CA vede modulele în așteptare și trimite apeluri către nodurile de furnizare: 1 secundă.
- 3 minute. Furnizorul de cloud alocă noduri. K8s așteaptă până sunt gata: până la 10 minute (în funcție de mai mulți factori).
Cel mai rău scenariu (mai realist) - 12 minute:
- 30 de secunde. Actualizați valorile vizate.
- 30 de secunde. HPA verifică valorile metrice.
- Mai puțin de 2 secunde. Pod-urile sunt create și intră în starea de așteptare.
- Mai puțin de 2 secunde. CA vede modulele în așteptare și efectuează apeluri pentru furnizarea nodurilor.
- 10 minute. Furnizorul de cloud alocă noduri. K8s așteaptă până sunt gata. Timpul de așteptare depinde de mai mulți factori, cum ar fi întârzierea furnizorului, întârzierea sistemului de operare și instrumentele de asistență.
Nu confundați mecanismele de scalare ale furnizorilor de cloud cu CA noastră. Acesta din urmă rulează în interiorul unui cluster Kubernetes, în timp ce motorul furnizorului de cloud funcționează pe bază de distribuție a nodurilor. Nu știe ce se întâmplă cu podurile sau aplicația dvs. Aceste sisteme funcționează în paralel.
Cum să gestionați scalarea în Kubernetes
- Kubernetes este un instrument de management și orchestrare a resurselor. Operațiunile de gestionare a podurilor și a resurselor clusterului reprezintă o etapă cheie în stăpânirea Kubernetes.
- Înțelegeți logica scalabilității podului ținând cont de HPA și VPA.
- CA ar trebui utilizat numai dacă înțelegeți bine nevoile capsulelor și recipientelor dvs.
- Pentru a configura optim un cluster, trebuie să înțelegeți cum funcționează împreună diferitele sisteme de scalare.
- Când estimați timpul de scalare, țineți cont de scenariile cele mai defavorabile și cele mai bune.
Sursa: www.habr.com