Pentru fiecare resursă Kubernetes există posibilitatea de a configura două tipuri de cerințe - Requests și Limits. Primul descrie cerințele minime de disponibilitate a resurselor nodului, necesare pentru a rula un container sau un pod, iar al doilea limitează strict resursele disponibile pentru container.
Când Kubernetes planifică un pod, este foarte important ca containerele să aibă suficiente resurse pentru a funcționa corect. Dacă intenționați să desfășurați o aplicație mare pe un nod cu resurse limitate, este posibil ca aceasta să nu funcționeze din cauza faptului că nodul rămâne fără memorie sau nu are suficiente puteri de procesare. În acest articol, vom explora cum putem rezolva problemele de insuficiență a puterilor de calcul prin cerințe de resurse și limitări.
Cerințele Requests și limitările Limits sunt mecanismele pe care Kubernetes le folosește pentru a gestiona resursele, precum procesorul și memoria. Requests reprezintă ceea ce asigură că un container primește resursa solicitată. Dacă un container solicită o resursă, Kubernetes o va planifica doar pe nodul care poate oferi aceasta. Limitările Limits controlează faptul că resursele solicitate de container nu vor depăși niciodată o valoare specificată.
Un container poate crește puterile de calcul doar până la un anumit prag, după care va fi limitat. Să vedem cum funcționează acest lucru. Așadar, există două tipuri de resurse - procesor și memorie. Planificatorul Kubernetes folosește date despre aceste resurse pentru a determina unde să ruleze podurile dvs. O specificație tipică a resurselor pentru un pod arată așa.
Fiecare container dintr-un pod poate stabili propriile cerințe și limite, totul fiind aditiv. Resursele de procesor sunt definite în milicores. Dacă containerul dumneavoastră necesită două nuclee complete pentru a funcționa, setați valoarea la 2000m. Dacă, în schimb, containerul are nevoie doar de 1/4 dintr-un nucleu, valoarea va fi de 250m. Rețineți că, dacă atribuiți o valoare a resurselor de procesor care depășește numărul de nuclee ale celui mai mare nod, lansarea podului nu va fi planificată deloc. O situație similară va apărea dacă aveți un pod care necesită patru nuclee, iar clusterul Kubernetes constă doar din două mașini virtuale principale.
Numai dacă aplicația dumneavoastră nu este dezvoltată special pentru a profita de avantajele mai multor nuclee (gândindu-ne aici la programe precum calculele științifice complexe și operațiile cu baze de date), cea mai bună practică este să setați cerințele CPU la 1 sau mai puțin, urmată de lansarea unui număr mai mare de replici pentru scalabilitate. Această soluție va oferi sistemului mai multă flexibilitate și fiabilitate.
Când vine vorba de limitele procesorului, lucrurile devin mai interesante, deoarece acesta este considerat un resursă comprimabilă. Dacă aplicația dumneavoastră începe să se apropie de limita puterii procesorului, Kubernetes va începe să limiteze containerul folosind CPU Throttling — reducerea frecvenței procesorului. Aceasta înseamnă că procesorul va fi restricționat artificial, oferind aplicației, potențial, o performanță mai slabă, totuși procesul nu va fi oprit sau eliminat.
Resursele de memorie sunt definite în byte. De obicei, valoarea din setări este măsurată în mebibitei Mib, dar puteți seta orice valoare, de la byte la petabyte. Aici se aplică aceeași situație ca și în cazul CPU — dacă solicitați o cantitate de memorie care depășește capacitatea de memorie a nodurilor dumneavoastră, execuția acestui pod nu va fi planificată. Dar, spre deosebire de resursele de procesor, memoria nu este comprimabilă, deoarece nu există nicio modalitate de a-i limita utilizarea. Prin urmare, execuția containerului va fi oprită imediat ce acesta depășește limita de memorie alocată.
Este important să rețineți că nu puteți configura cereri care depășesc dimensiunea resurselor pe care nodurile dvs. le pot oferi. Specificațiile resurselor comune pentru mașinile virtuale GKE pot fi găsite pe linkurile afișate sub acest videoclip.
Într-o lume ideală, setările implicite ale containerului ar fi suficiente pentru ca fluxurile de lucru să decurgă fără probleme. Însă, în realitate, lucrurile nu sunt atât de simple, oamenii pot uita cu ușurință să configureze utilizarea resurselor sau hackerii ar putea stabili cereri și limite care depășesc capacitățile reale ale infrastructurii. Pentru a preveni dezvoltarea unor astfel de scenarii, este posibil să configurați cotele de resurse ResourceQuota și intervalele de limitare LimitRange.
După crearea spațiilor de nume, acestea pot fi blocate prin cote. De exemplu, dacă aveți spații de nume prod și dev, se folosește un model în care cotele pentru producție lipsesc complet, iar cotele pentru dezvoltare sunt foarte stricte. Acest lucru permite mediului prod să preia toate resursele disponibile în cazul unei creșteri bruște a traficului, blocând complet mediul dev.
Cota resurselor poate arăta astfel. În acest exemplu, sunt 4 secțiuni - acestea sunt cele 4 linii de cod inferioare.
Să analizăm fiecare dintre ele. Requests.cpu reprezintă numărul maxim de cereri combinate de capacitate de procesor care pot proveni de la toate containerele din spațiul de nume. În acest exemplu, puteți avea 50 de containere cu cereri de 10m, cinci containere cu cereri de 100m sau pur și simplu un singur container cu cerere de 500m. Atâta timp cât cantitatea totală de requests.cpu pentru acest spațiu de nume este mai mică de 500m, totul va fi în regulă.
Memoria solicitată requests.memory este cantitatea maximă combinată de cereri de memorie pe care toate containerele din spațiul de nume o pot avea. La fel ca în cazul precedent, puteți avea 50 de containere cu 2 MiB, cinci containere cu 20 MiB sau un singur container cu 100 MiB atâta timp cât cantitatea totală de memorie solicitată în spațiul de nume este mai mică de 100 mebibai.
Limits.cpu reprezintă valoarea maximă combinată de capacitate de procesor pe care toate containerele din spațiul de nume o pot utiliza. Se poate considera că acesta este pragul cererilor de capacitate de procesor.
În cele din urmă, limits.memory reprezintă volumul maxim de memorie totală pe care toate containerele din spațiul de nume îl pot utiliza. Aceasta este o limitare a cererilor de memorie aggregate.
Așadar, prin default, containerele din clusterul Kubernetes funcționează cu resurse computaționale nelimitate. Prin intermediul cotelor de resurse, administratorii clusterului pot restricționa consumul de resurse și crearea acestora pe baza spațiului de nume. În spațiul de nume, un modul pod sau un container poate consuma atâta putere CPU și memorie cât este definit în cota de resurse a spațiului de nume. Totuși, există temerea că un singur pod sau container ar putea monopoliza toate resursele disponibile. Pentru a preveni această situație, se folosește intervalul limită Limit Range – o politică de restricționare a distribuției resurselor (pentru poduri sau containere) în spațiul de nume.
Intervalul limită oferă restricții care pot:
- asigura utilizarea minimă și maximă a resurselor computaționale pentru fiecare modul sau container din spațiul de nume;
- forța utilizarea unei cereri de stocare Storage Request minimă și maximă pentru fiecare PersistentVolumeClaim din spațiul de nume;
- forța stabilirea unei relații între cererea Request și limita Limit pentru resursa din spațiul de nume;
- stabili Requests/Limits ca valori implicite pentru resursele computaționale în spațiul de nume și să le introducă automat în containere în timpul execuției.
Astfel, puteți crea un interval limită în spațiul dumneavoastră de nume. Spre deosebire de cotele care se aplică întregului spațiu de nume, Limit Range se utilizează pentru containere individuale. Acest lucru poate preveni crearea de către utilizatori a unor containere foarte mici sau, dimpotrivă, gigantice, în interiorul spațiului de nume. Intervalul limită Limit Range poate arăta astfel.
La fel ca și în cazul anterior, aici putem distinge 4 secțiuni. Să examinăm fiecare.
În secțiunea default, se stabilesc restricții implicite pentru containerul din pod. Dacă stabiliți aceste valori în intervalul limită, orice containere pentru care aceste valori nu au fost stabilite explicit vor fi guvernate de valorile implicite.
În secțiunea defaultRequest se configurează cererile implicite pentru container în pod. Din nou, dacă setați aceste valori în intervalul limită, containele pentru care aceste parametrii nu sunt specificați explicit vor folosi aceste valori ca fiind implicite.
În secțiunea max sunt specificate limitele maxime care pot fi stabilite pentru container în pod. Valorile din secțiunea default și limitele pentru container nu pot fi setate mai sus decât această limită. Este important de reținut că dacă este stabilită o valoare max, iar secțiunea default lipsește, atunci valoarea maximă devine valoarea implicită.
În secțiunea min sunt specificate cerințele minime care pot fi stabilite pentru container în pod. Astfel, valorile din secțiunea default și cerințele pentru container nu pot fi setate mai jos decât această limită.
Din nou, este important de reținut că dacă această valoare este setată, iar valoarea default nu este, atunci valoarea minimă devine cererea implicită.
În cele din urmă, aceste cereri de resurse sunt utilizate de programatorul Kubernetes pentru a executa sarcinile dvs. de muncă. Pentru a putea configura corect containerele, este esențial să înțelegeți cum funcționează acest lucru. Să presupunem că doriți să rulați mai multe module în clusterul dvs. Presupunând că specificațiile pod-ului sunt valabile, Kubernetes va folosi un algoritm de balansare ciclică pentru a alege un nod pentru a executa sarcina.
Kubernetes va verifica dacă resursele de la nodul Node 1 sunt suficiente pentru a îndeplini cerințele containerelor din pod, iar dacă nu este cazul, va trece la următorul nod. Dacă niciunul dintre nodurile din sistem nu poate satisface cerințele, pod-urile vor trece în starea de așteptare Pending state. Prin funcționalitățile Google Kubernetes Engine, cum ar fi scalarea automată a nodurilor, GKE poate determina automat starea de așteptare și poate crea câteva noduri suplimentare.
Dacă ulterior apare o capacitate excesivă la noduri, funcția de scalare automată va reduce numărul acestora pentru a economisi bani. De aceea, Kubernetes planifică pod-urile pe baza cererilor. Cu toate acestea, limita poate fi mai mare decât cererile și, în unele cazuri, un nod poate să rămână fără resurse. Numim această stare overcommitment state.
Așa cum am menționat, când vine vorba de procesor, Kubernetes va începe să limiteze pod-urile. Fiecare pod va primi atât cât a cerut, dar dacă nu atinge limita, se va începe aplicarea throttling-ului.
În ceea ce privește resursele de memorie, Kubernetes este nevoit să ia decizii cu privire la ce pod-uri să ștergă și care să rămână, până când eliberați resursele sistemului, altfel întreaga sistem va ceda.
Să ne imaginăm un scenariu în care aveți o mașină care a atins limita de memorie – cum va acționa Kubernetes în acest caz?
Kubernetes va căuta pod-urile care utilizează mai multe resurse decât au solicitat. Așadar, dacă containerele dvs. nu au cereri deloc, aceasta înseamnă că, implicit, utilizează mai mult decât au cerut, pur și simplu pentru că nu au cerut deloc nimic! Aceste containere devin principalii candidați pentru a fi dezactivate. Următoarele candidați sunt containerele care au satisfăcut toate cerințele, dar se află încă sub limita maximă.
Așadar, dacă Kubernetes găsește mai multe pod-uri care depășesc parametrii cererilor lor, le va sorta în funcție de prioritate și apoi va elimina modulele cu prioritate mai mică. Dacă toate modulele au aceeași prioritate, Kubernetes va opri pod-urile care au depășit cererile lor mai mult decât celelalte pod-uri.
În foarte rare ocazii, Kubernetes poate întrerupe pod-uri care sunt încă în limitele cererilor lor. Acest lucru poate apărea atunci când componentele critice ale sistemului, precum agentul Kubelet sau Docker, încep să consume mai multe resurse decât au fost rezervate pentru ele.
Așadar, în etapele inițiale ale activității unor companii mici, un cluster Kubernetes poate funcționa bine fără a stabili cereri de resurse și limite, dar pe măsură ce echipele și proiectele dvs. încep să crească în dimensiune, riscați să vă confruntați cu probleme în această privință. Adăugarea cererilor și limitelor în modulele și spațiile de nume necesită foarte puțin efort suplimentar și vă poate scuti de multe griji.
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
