Pentru fiecare resursă Kubernetes, puteți configura două tipuri de cerințe - Cereri și Limite. Primul descrie cerințele minime pentru disponibilitatea resurselor de nod gratuite necesare pentru a rula un container sau un pod, al doilea limitează strict resursele disponibile pentru container.
Când Kubernetes programează pod-uri, este foarte important ca containerele să aibă suficiente resurse pentru a funcționa corect. Dacă intenționați să implementați o aplicație mare pe un nod cu resurse limitate, este posibil ca aceasta să nu ruleze, deoarece nodul epuizează memoria sau rămâne fără putere CPU. În acest articol, vom analiza cum puteți rezolva deficitul de putere de calcul utilizând solicitările și limitele de resurse.
Cererile și limitele sunt mecanisme pe care Kubernetes le folosește pentru a gestiona resurse precum CPU și memoria. Solicitările sunt cele care asigură că containerul primește resursa solicitată. Dacă un container solicită o resursă, Kubernetes o va programa doar pe un nod care o poate furniza. Limitele controlează că resursele solicitate de container nu vor depăși niciodată o anumită valoare.
Un container își poate crește puterea de calcul doar până la o anumită limită, după care va fi limitat. Să vedem cum funcționează. Deci, există două tipuri de resurse - procesor și memorie. Programatorul Kubernetes folosește date despre aceste resurse pentru a afla unde să ruleze podurile. O specificație tipică de resurse pentru un pod arată astfel.
Fiecare container dintr-un pod își poate seta propriile interogări și limite, totul este aditiv. Resursele procesorului sunt definite în milicore. Dacă containerul dumneavoastră are nevoie de două miezuri complete pentru a rula, setați valoarea la 2000 m. Dacă containerul are nevoie doar de puterea de 1/4 din miez, valoarea va fi de 250 m. Rețineți că, dacă atribuiți o valoare a resursei CPU mai mare decât numărul de nuclee al celui mai mare nod, podul dvs. nu va fi programat să pornească deloc. O situație similară va apărea dacă aveți un Pod care are nevoie de patru nuclee, iar clusterul Kubernetes este format din doar două mașini virtuale principale.
Cu excepția cazului în care aplicația dvs. este concepută special pentru a profita de mai multe nuclee (programe precum calculul științific complex și operațiunile de baze de date vin în minte), atunci cea mai bună practică este să setați cererile CPU la 1 sau mai puțin și apoi să rulați mai multe replici la scalabilitate. Această soluție va oferi sistemului o mai mare flexibilitate și fiabilitate.
Când vine vorba de limitările CPU, lucrurile devin mai interesante, deoarece este considerată o resursă compresibilă. Dacă aplicația dvs. începe să se apropie de limita de putere a procesorului, Kubernetes va începe să vă încetinească containerul folosind CPU Throttling - reducând frecvența procesorului. Aceasta înseamnă că procesorul va fi accelerat artificial, dând aplicației performanțe potențial mai slabe, dar procesul nu va fi încheiat sau eliminat.
Resursele de memorie sunt definite în octeți. De obicei, valoarea din setări este măsurată în mebibytes Mib, dar puteți seta orice valoare, de la octeți la petabytes. Aceeași situație se aplică aici ca și în cazul CPU - dacă solicitați o cantitate de memorie mai mare decât cantitatea de memorie de pe nodurile dvs., acel pod nu va fi programat să se execute. Dar, spre deosebire de resursele CPU, memoria nu este comprimată deoarece nu există nicio modalitate de a-i limita utilizarea. Prin urmare, execuția containerului va fi oprită de îndată ce acesta depășește memoria alocată acestuia.
Este important să rețineți că nu puteți configura cereri care depășesc resursele pe care le pot furniza nodurile dvs. Specificațiile de resurse partajate pentru mașinile virtuale GKE pot fi găsite în linkurile de sub acest videoclip.
Într-o lume ideală, setările implicite ale containerului ar fi suficiente pentru ca fluxurile de lucru să funcționeze fără probleme. Dar lumea reală nu este așa, oamenii pot uita cu ușurință să configureze utilizarea resurselor, sau hackerii vor stabili solicitări și restricții care depășesc capacitățile reale ale infrastructurii. Pentru a preveni astfel de scenarii, puteți configura cotele de resurse ResourceQuota și LimitRange.
Odată ce un spațiu de nume a fost creat, acesta poate fi blocat folosind cote. De exemplu, dacă aveți spațiile de nume prod și dev, modelul este că nu există deloc cote de producție și cote de dezvoltare foarte stricte. Acest lucru permite prod, în cazul unei creșteri puternice a traficului, să preia întreaga resursă disponibilă, blocând complet dev.
Cota de resurse ar putea arăta astfel. În acest exemplu există 4 secțiuni - acestea sunt cele 4 linii de jos ale codului.
Să ne uităm la fiecare dintre ele. Requests.cpu este numărul maxim de solicitări CPU combinate care pot veni din toate containerele din spațiul de nume. În acest exemplu, puteți avea 50 de containere cu cereri de 10 m, cinci containere cu solicitări de 100 m sau doar un container cu solicitări de 500 m. Atâta timp cât numărul total de requests.cpu al unui anumit spațiu de nume este mai mic de 500m, totul va fi bine.
Memory requested requests.memory este cantitatea maximă de solicitări de memorie combinate pe care o pot avea toate containerele din spațiul de nume. Ca și în cazul precedent, puteți avea 50 de containere de 2 mib, cinci containere de 20 de mib sau un singur container de 100 de mib, atâta timp cât cantitatea totală de memorie solicitată în spațiul de nume este mai mică de 100 de mebibytes.
Limits.cpu este cantitatea maximă combinată de putere CPU pe care o pot folosi toate containerele din spațiul de nume. Putem considera că aceasta este limita solicitărilor de putere a procesorului.
În cele din urmă, limits.memory este cantitatea maximă de memorie partajată pe care o pot folosi toate containerele din spațiul de nume. Aceasta este o limită a solicitărilor totale de memorie.
Deci, implicit, containerele dintr-un cluster Kubernetes rulează cu resurse de calcul nelimitate. Cu cotele de resurse, administratorii clusterului pot limita consumul de resurse și crearea de resurse pe baza spațiului de nume. Într-un spațiu de nume, un pod sau un container poate consuma atâta putere și memorie CPU cât este determinat de cota de resurse pentru spațiul de nume. Cu toate acestea, există îngrijorarea că un singur pod sau container poate monopoliza toate resursele disponibile. Pentru a preveni această situație, se folosește un interval limită - o politică de limitare a alocării resurselor (pentru pod-uri sau containere) în spațiul de nume.
Intervalul limită oferă restricții care pot:
- Asigurați utilizarea minimă și maximă a resurselor de calcul pentru fiecare modul sau container din spațiul de nume;
- impune cererile de stocare minime și maxime Starage Request pentru fiecare PersistentVolumeClaim din spațiul de nume;
- să impună o relație între o cerere și o limită pentru o resursă dintr-un spațiu de nume;
- setați Cereri/Limite implicite pentru resursele de calcul în spațiul de nume și injectați-le automat în containere în timpul execuției.
În acest fel, puteți crea un interval limită în spațiul dvs. de nume. Spre deosebire de o cotă, care se aplică întregului spațiu de nume, Limit Range este utilizat pentru containere individuale. Acest lucru poate împiedica utilizatorii să creeze containere foarte mici sau, dimpotrivă, gigantice în spațiul de nume. Intervalul limită ar putea arăta astfel.
Ca și în cazul precedent, aici se pot distinge 4 secțiuni. Să ne uităm la fiecare.
Secțiunea implicită stabilește limitele implicite pentru containerul din pod. Dacă setați aceste valori la intervalul extrem, atunci orice container pentru care aceste valori nu au fost setate în mod explicit vor urma valorile implicite.
Secțiunea de solicitare implicită defaultRequest configurează cererile implicite pentru containerul din pod. Din nou, dacă setați aceste valori la intervalul extrem, atunci orice container care nu setează în mod explicit aceste opțiuni va folosi implicit aceste valori.
Secțiunea maximă specifică limitele maxime care pot fi setate pentru un container din pod. Valorile din secțiunea implicită și limitele containerului nu pot fi setate peste această limită. Este important de reținut că, dacă valoarea este setată la max și nu există nicio secțiune implicită, atunci valoarea maximă devine valoarea implicită.
Secțiunea min specifică solicitările minime care pot fi setate pentru un container dintr-un pod. Cu toate acestea, valorile din secțiunea implicită și interogările pentru container nu pot fi setate sub această limită.
Din nou, este important de reținut că, dacă această valoare este setată, implicit nu este, atunci valoarea minimă devine promptul implicit.
Aceste solicitări de resurse sunt utilizate în cele din urmă de planificatorul Kubernetes pentru a vă executa sarcinile de lucru. Pentru a vă configura corect containerele, este foarte important să înțelegeți cum funcționează. Să presupunem că doriți să rulați mai multe poduri în clusterul dvs. Presupunând că specificațiile podului sunt valide, programul Kubernetes va folosi echilibrarea round robin pentru a selecta un nod pentru a rula volumul de lucru.
Kubernetes va verifica dacă Nodul 1 are suficiente resurse pentru a îndeplini cererile de la containerele pod, iar dacă nu, va trece la următorul nod. Dacă niciunul dintre nodurile din sistem nu este capabil să satisfacă cererile, pod-urile vor intra în starea În așteptare. Folosind funcțiile motorului Google Kubernetes, cum ar fi scalarea automată a nodurilor, GKE poate detecta automat starea de așteptare și poate crea mai multe noduri suplimentare.
Dacă ulterior rămâneți fără capacitatea nodului, scalarea automată va reduce numărul de noduri pentru a vă economisi bani. Acesta este motivul pentru care Kubernetes programează pod-uri pe baza solicitărilor. Cu toate acestea, limita poate fi mai mare decât cererile și, în unele cazuri, nodul poate rămâne fără resurse. Numim acest stat stat de supraangajare.
După cum am spus, când vine vorba de CPU, Kubernetes va începe să limiteze podurile. Fiecare pod va primi cât a cerut, dar dacă nu ajunge la limită, va începe să se aplice throttling.
Când vine vorba de resursele de memorie, Kubernetes este forțat să ia decizii cu privire la ce pod-uri să ștergă și pe care să le păstreze până când eliberați resursele sistemului sau întregul sistem se va prăbuși.
Să ne imaginăm un scenariu în care aveți o mașină care rămâne fără memorie - cum ar gestiona Kubernetes asta?
Kubernetes va căuta pod-uri care utilizează mai multe resurse decât au cerut. Deci, dacă containerele dvs. nu au deloc Soliciți, înseamnă că în mod implicit folosesc mai mult decât au cerut, pur și simplu pentru că nu au cerut absolut nimic! Astfel de containere devin candidații principali pentru închidere. Următorii candidați sunt containere care și-au satisfăcut toate solicitările, dar sunt încă sub limita maximă.
Deci, dacă Kubernetes găsește mai multe poduri care și-au depășit parametrii de solicitare, le va sorta după prioritate și apoi va elimina podurile cu cea mai mică prioritate. Dacă toate podurile au aceeași prioritate, atunci Kubernetes va închide acele poduri care depășesc cererile lor mai mult decât alte poduri.
În cazuri foarte rare, Kubernetes poate anula pod-urile care se află încă în domeniul de aplicare al solicitărilor lor. Acest lucru se poate întâmpla atunci când componentele critice ale sistemului, cum ar fi agentul Kubelet sau Docker, încep să consume mai multe resurse decât ceea ce le-a fost rezervat.
Deci, în stadiile incipiente ale companiilor mici, un cluster Kubernetes poate funcționa bine fără a stabili solicitări și restricții de resurse, dar pe măsură ce echipele și proiectele încep să crească în dimensiune, riscați să întâmpinați probleme în acest domeniu. Adăugarea de interogări și constrângeri la modulele și spațiile de nume necesită foarte puțin efort suplimentar și poate economisi o mulțime de bătăi de cap.
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com