Când începeți cu Kubernetes, este obișnuit să uitați de configurarea resurselor containerului. În acest moment, este suficient să vă asigurați că imaginea Docker funcționează și poate fi implementată în clusterul Kubernetes.
Dar mai târziu, aplicația trebuie să fie implementată într-un cluster de producție împreună cu alte aplicații. Pentru a face acest lucru, trebuie să alocați resurse pentru container și să vă asigurați că există suficiente pentru ca aplicația să funcționeze și că alte aplicații care rulează nu vor avea probleme.
Echipă a tradus un articol despre resursele containerului (CPU și MEM), solicitări și limitările resurselor. Veți afla care sunt beneficiile acestor setări și ce se întâmplă dacă nu le setați.
Resurse de calcul
Avem două tipuri de resurse cu următoarele unități:
- Unitate centrală de procesare (CPU) - nuclee;
- Memorie (MEM) - octeți.
Resursele sunt specificate pentru fiecare container. În următorul fișier Pod YAML, veți vedea o secțiune de resurse care conține resursele solicitate și limită:
- Requested Pod Resources = suma resurselor solicitate ale tuturor containerelor;
- Limita resurselor pod = Suma tuturor limitelor resurselor podului.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiExemplu de resurse solicitate și limitate
Câmp resources.requested din specificația Pod este unul dintre elementele care se utilizează pentru a găsi nodul dorit. Puteți planifica deja implementarea Pod pentru acesta. Cum găsești un nod potrivit?
Kubernetes este format din mai multe componente, inclusiv un nod master sau un nod master (Plan de control Kubernetes). Nodul master are mai multe procese: kube-apiserver, kube-controller-manager și kube-scheduler.
Procesul kube-scheduler este responsabil pentru revizuirea podurilor nou create și găsirea nodurilor de lucru posibile care se potrivesc tuturor solicitărilor de pod, inclusiv numărul de resurse solicitate. Lista nodurilor găsite de kube-scheduler este clasată. Pod-ul este programat pe nodul cu cele mai mari scoruri.
Unde va fi plasat Podul violet?
În imagine puteți vedea că kube-scheduler ar trebui să programeze un nou Pod violet. Clusterul Kubernetes conține două noduri: A și B. După cum puteți vedea, kube-scheduler nu poate programa un Pod pe nodul A - resursele disponibile (nesolicitate) nu se potrivesc cu solicitările Podului violet. Deci, 1 GB de memorie solicitat de Podul violet nu se va potrivi pe nodul A, deoarece memoria disponibilă este de 0,5 GB. Dar nodul B are suficiente resurse. Ca rezultat, Kube-scheduler decide că destinația Pod-ului violet este nodul B.
Acum știm cum resursele solicitate afectează alegerea nodului pentru a rula Pod. Dar care este impactul resurselor marginale?
Limita resurselor este o limită pe care CPU/MEM nu o poate trece. Cu toate acestea, resursa CPU este flexibilă, astfel încât containerele care își ating limitele CPU nu vor determina ieșirea Podului. În schimb, va începe accelerarea procesorului. Dacă limita de utilizare a MEM este atinsă, containerul va fi oprit din cauza OOM-Killer și repornit dacă este permis de setarea RestartPolicy.
Resurse solicitate și maxime în detaliu
Comunicarea resurselor între Docker și Kubernetes
Cel mai bun mod de a explica cum funcționează cererile de resurse și limitele de resurse este de a introduce relația dintre Kubernetes și Docker. În imaginea de mai sus puteți vedea cum sunt legate câmpurile Kubernetes și steagurile de pornire Docker.
Memoria: cerere și limitare
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
După cum am menționat mai sus, memoria este măsurată în octeți. Bazat pe , putem specifica memoria ca număr. De obicei este un număr întreg, de exemplu 2678 - adică 2678 octeți. Puteți folosi și sufixe G и Gi, principalul lucru este să ne amintim că nu sunt echivalente. Primul este zecimal, iar al doilea este binar. Ca exemplul menționat în documentația k8s: 128974848, 129e6, 129M, 123Mi - sunt practic echivalente.
Opțiunea Kubernetes limits.memory se potrivește cu steagul --memory de la Docker. In caz de request.memory Nu există săgeată pentru Docker, deoarece Docker nu utilizează acest câmp. Vă puteți întreba, este chiar necesar? Da nevoie. După cum am spus mai devreme, domeniul contează pentru Kubernetes. Pe baza informațiilor din acesta, kube-scheduler decide ce nod să programeze Pod.
Ce se întâmplă dacă setați memorie insuficientă pentru o solicitare?
Dacă containerul a atins limitele memoriei solicitate, atunci Pod-ul este plasat într-un grup de Pod-uri care se opresc atunci când nu există suficientă memorie în nod.
Ce se întâmplă dacă setați limita de memorie prea mică?
Dacă containerul depășește limita de memorie, acesta va fi încheiat din cauza OOM-Killed. Și va reporni dacă este posibil pe baza RestartPolicy unde este valoarea implicită Always.
Ce se întâmplă dacă nu specificați memoria solicitată?
Kubernetes va lua valoarea limită și o va seta ca valoare implicită.
Ce se poate întâmpla dacă nu specificați o limită de memorie?
Containerul nu are restricții; poate folosi atâta memorie cât dorește. Dacă începe să folosească toată memoria disponibilă a nodului, atunci OOM îl va ucide. Containerul va fi apoi repornit, dacă este posibil, pe baza RestartPolicy.
Ce se întâmplă dacă nu specificați limite de memorie?
Acesta este cel mai rău scenariu: planificatorul nu știe câte resurse necesită containerul și acest lucru poate cauza probleme serioase la nod. În acest caz, ar fi bine să existe limite implicite pentru spațiul de nume (setate de LimitRange). Nu există limite implicite - Pod-ul nu are limite, poate folosi atâta memorie cât dorește.
Dacă memoria solicitată este mai mare decât poate oferi nodul, Podul nu va fi programat. Este important să ne amintim asta Requests.memory - nu valoarea minimă. Aceasta este o descriere a cantității de memorie suficientă pentru a menține containerul să funcționeze continuu.
De obicei este recomandat să setați aceeași valoare pentru request.memory и limit.memory. Acest lucru asigură că Kubernetes nu va programa un Pod pe un nod care are suficientă memorie pentru a rula Podul, dar nu suficientă pentru a-l rula. Rețineți: planificarea Kubernetes Pod ia în considerare doar requests.memoryȘi limits.memory nu ia in calcul.
CPU: cerere și limită
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Cu un procesor totul este puțin mai complicat. Revenind la imaginea relației dintre Kubernetes și Docker, puteți vedea asta request.cpu соответствует --cpu-shares, întrucât limit.cpu se potrivește cu steagul cpus în Docker.
Procesorul pe care îl solicită Kubernetes este înmulțit cu 1024, proporția ciclurilor CPU. Dacă doriți să solicitați 1 nucleu complet, trebuie să adăugați cpu: 1așa cum se arată mai sus.
Solicitarea unui nucleu complet (proporție = 1024) nu înseamnă că containerul dumneavoastră îl va primi. Dacă mașina dvs. gazdă are un singur nucleu și rulați mai mult de un container, atunci toate containerele trebuie să partajeze CPU-ul disponibil între ele. Cum se întâmplă asta? Să ne uităm la poză.
Solicitare CPU - Sistem unic
Să ne imaginăm că aveți un sistem gazdă cu un singur nucleu care rulează containere. Mama (Kubernetes) a copt o plăcintă (CPU) și vrea să o împartă între copii (recipiente). Trei copii vor o plăcintă întreagă (proporție = 1024), un alt copil vrea o jumătate de plăcintă (512). Mama vrea să fie corectă și face un calcul simplu.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Pe baza calculului, trei copii vor primi 28% din nucleu, și nu întregul nucleu. Al patrulea copil va primi 14% din nucleul complet, nu jumătate. Dar lucrurile vor fi altfel dacă aveți un sistem multi-core.
Solicitare CPU - Sistem Multi-Core (4).
În imaginea de mai sus puteți vedea că trei copii vor o plăcintă întreagă, iar unul vrea jumătate. Deoarece mama a copt patru plăcinte, fiecare dintre copiii ei va primi câte vrea. Într-un sistem multi-core, resursele procesorului sunt distribuite în toate nucleele de procesor disponibile. Dacă un container este limitat la mai puțin de un nucleu CPU complet, îl poate folosi în continuare la 100%.
Calculele de mai sus sunt simplificate pentru a înțelege modul în care CPU este distribuit între containere. Desigur, pe lângă containerele în sine, există și alte procese care folosesc și resurse CPU. Când procesele dintr-un container sunt inactive, alții pot folosi resursa acestuia. CPU: "200m" соответствует CPU: 0,2, ceea ce înseamnă aproximativ 20% dintr-un nucleu.
Acum să vorbim despre limit.cpu. Procesorul pe care îl limitează Kubernetes este înmulțit cu 100. Rezultatul este timpul pe care containerul îl poate folosi la fiecare 100 µs (cpu-period).
limit.cpu se potrivește cu steagul Docker --cpus. Aceasta este o nouă combinație de vechi --cpu-period и --cpu-quota. Setând-o, indicăm câte resurse CPU disponibile poate folosi containerul la maxim înainte de a începe limitarea:
- CPU - combinație
cpu-periodиcpu-quota. cpus = 1.5echivalent cu setareacpu-period = 100000иcpu-quota = 150000; - CPU-perioada - punct , implicit 100 microsecunde;
- cpu-cota - numărul de microsecunde în interior
cpu-period, care este delimitat de container.
Ce se întâmplă dacă instalați CPU solicitat insuficient?
Dacă containerul are nevoie de mai mult decât a instalat, va fura CPU din alte procese.
Ce se întâmplă dacă setați limita CPU prea mică?
Deoarece resursa CPU este reglabilă, accelerarea se va activa.
Ce se întâmplă dacă nu specificați o solicitare CPU?
Ca și în cazul memoriei, valoarea solicitării este egală cu limita.
Ce se întâmplă dacă nu specificați o limită de CPU?
Containerul va folosi atât CPU cât are nevoie. Dacă în spațiul de nume este definită o politică implicită pentru CPU (LimitRange), atunci această limită este utilizată și pentru container.
Ce se întâmplă dacă nu specificați nici o solicitare, nici o limită CPU?
Ca și în cazul memoriei, acesta este cel mai rău caz. Planificatorul nu știe de câte resurse are nevoie containerul tău, iar acest lucru poate cauza probleme serioase la nod. Pentru a evita acest lucru, trebuie să setați limite implicite pentru spațiile de nume (LimitRange).
Amintiți-vă: dacă solicitați mai mult CPU decât pot oferi nodurile, Pod-ul nu va fi programat. Requests.cpu - nu valoarea minimă, ci o valoare suficientă pentru a porni Pod-ul și a funcționa fără defecțiuni. Dacă aplicația nu efectuează calcule complexe, cea mai bună opțiune este instalarea request.cpu <= 1 și lansați câte replici este necesar.
Cantitatea ideală de resurse solicitate sau limita de resurse
Am aflat despre limitarea resurselor de calcul. Acum este timpul să răspund la întrebarea: „De câte resurse are nevoie Podul meu pentru a rula aplicația fără probleme? Care este cantitatea ideală?
Din păcate, nu există răspunsuri clare la aceste întrebări. Dacă nu știți cum funcționează aplicația dvs. sau de câtă CPU sau memorie are nevoie, cea mai bună opțiune este să oferiți aplicației multă memorie și CPU și apoi să executați teste de performanță.
Pe lângă testele de performanță, monitorizați comportamentul aplicației în monitorizare timp de o săptămână. Dacă graficele indică faptul că aplicația dumneavoastră consumă mai puține resurse decât ați solicitat, puteți reduce cantitatea de CPU sau memorie solicitată.
Ca exemplu, vezi asta . Afișează diferența dintre resursele solicitate sau limita de resurse și utilizarea curentă a resurselor.
Concluzie
Solicitarea și limitarea resurselor vă ajută să vă mențineți clusterul Kubernetes sănătos. Configurarea corectă a limitelor minimizează costurile și menține aplicațiile în funcționare în orice moment.
Pe scurt, sunt câteva lucruri de reținut:
- Resursele solicitate sunt o configurație care este luată în considerare la momentul pornirii (când Kubernetes plănuiește să găzduiască aplicația). În schimb, limitarea resurselor este importantă în timpul execuției, când aplicația rulează deja pe nod.
- În comparație cu memoria, procesorul este o resursă reglementată. Dacă nu este suficient CPU, Podul nu se va închide și mecanismul de accelerare se va porni.
- Resursele solicitate și limita de resurse nu sunt valori minime și maxime! Prin definirea resurselor solicitate, vă asigurați că aplicația va rula fără probleme.
- O bună practică este să setați cererea de memorie egală cu limita de memorie.
- Ok s-a cerut instalarea
CPU <=1, dacă aplicația nu efectuează calcule complexe. - Dacă solicitați mai multe resurse decât sunt disponibile pe un nod, Podul nu va fi niciodată programat pentru acel nod.
- Pentru a determina cantitatea corectă de resurse/limite de resurse solicitate, utilizați testarea și monitorizarea încărcării.
Sper că acest articol vă ajută să înțelegeți conceptul de bază al limitării resurselor. Și vei putea aplica aceste cunoștințe în munca ta.
Succes!
Ce altceva de citit:
- .
- .
- .
Sursa: www.habr.com