🥇Cumu accede à e risorse Kubernetes Pod

A Ricompensa di Tohad

Quandu si principia cù Kubernetes, hè cumuni di scurdà di a creazione di risorse di container. À questu puntu, hè abbastanza per assicurà chì l'imaghjini di Docker funziona è pò esse implementatu à u cluster Kubernetes.

Ma più tardi l'applicazione deve esse implementata in un cluster di produzzione cù altre applicazioni. Per fà questu, avete bisognu di assignà risorse per u cuntinuu è assicuratevi chì ci sò abbastanza di elli per avè l'appiecazione in funziunamentu, è chì altre applicazioni in esecuzione ùn anu micca prublemi.

squadra Kubernetes aaS da Mail.ru traduttu un articulu nantu à e risorse di container (CPU & MEM), richieste è limitazioni di risorse. Amparerete i benefici di sti paràmetri è ciò chì succede s'ellu ùn li mette micca.

Risorse informatica

Avemu dui tipi di risorse cù e seguenti unità:

Unità di trasfurmazioni cintrali (CPU) - core;
Memoria (MEM) - byte.

E risorse sò specificate per ogni cuntainer. In u seguente pod YAML file, vi vede una sezione di risorse chì cuntene e risorse richieste è limitate:

Requested Pod Resources = somma di risorse richieste di tutti i cuntenituri;
Limite di Risorsa Pod = Suma di tutti i Limiti di Risorsa Pod.

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:  1Gi

Esempiu di risorse richieste è limitate

chjosu resources.requested da a specificazione Pod hè unu di l'elementi chì hè utilizatu per truvà u node desideratu. Pudete digià pianificà a implementazione di Pod per questu. Cumu truvà un node adattatu?

Kubernetes hè custituitu da parechji cumpunenti, cumpresu un nodu maestru o un nodu maestru (Kubernetes Control Plane). U node maestru hà parechji prucessi: kube-apiserver, kube-controller-manager è kube-scheduler.

U prucessu di kube-scheduler hè incaricatu di riviseghjà i pods di nova creazione è di truvà nodi di u travagliu pussibuli chì currispondenu à tutte e dumande di pod, cumpresu u numeru di risorse dumandate. A lista di i nodi truvati da kube-scheduler hè classificatu. U pod hè programatu nantu à u node cù i punteggi più altu.

Induve serà piazzatu u Pod viola ?

In a stampa pudete vede chì u kube-scheduler deve pianificà un novu Pod viola. U cluster Kubernetes cuntene dui nodi: A è B. Comu pudete vede, kube-scheduler ùn pò micca pianificà un Pod in u node A - i risorse dispunibili (unrequested) ùn currispondenu micca à e dumande di u Pod purple. Allora, u 1 GB di memoria dumandata da u Pod purple ùn si mette micca in u node A, postu chì a memoria dispunibule hè 0,5 GB. Ma u node B hà abbastanza risorse. In u risultatu, kube-scheduler decide chì a destinazione di u Pod purpura hè u node B.

Avà sapemu cumu i risorsi dumandati affettanu a scelta di u node per eseguisce u Pod. Ma chì hè l'impattu di e risorse marginali?

U limitu di risorse hè un cunfini chì u CPU / MEM ùn pò micca attraversà. In ogni casu, a risorsa di CPU hè flessibile, cusì i cuntenituri chì righjunghjenu i so limiti di CPU ùn pruvucanu micca a fine di u Pod. Invece, u throttling di CPU accuminciarà. Se u limitu di usu MEM hè righjuntu, u cuntinuu serà fermatu per via di OOM-Killer è riavviatu se permessu da a paràmetra RestartPolicy.

Risorse richieste è massime in dettagliu

Comunicazione di risorse trà Docker è Kubernetes

U megliu modu per spiegà cumu travaglianu e richieste di risorse è i limiti di risorse hè di intruduce a relazione trà Kubernetes è Docker. In l'imaghjini sopra, pudete vede cumu i campi Kubernetes è i bandieri di startup di Docker sò in relazione.

Memoria: dumanda è limitazione

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Cum'è l'esitatu sopra, a memoria hè misurata in byte. Bastu nantu à Documentazione Kubernetes, pudemu specificà a memoria cum'è un numeru. Di solitu hè un interu, per esempiu 2678 - vale à dì, 2678 bytes. Pudete ancu aduprà suffissi G и Gi, A cosa principal hè di ricurdà chì ùn sò micca equivalenti. U primu hè decimale è u sicondu hè binariu. Cum'è l'esempiu citatu in a documentazione k8s: 128974848, 129e6, 129M, 123Mi - sò praticamenti equivalenti.

Opzione Kubernetes limits.memory currisponde à a bandiera --memory da Docker. In casu di request.memory Ùn ci hè micca freccia per Docker perchè Docker ùn usa micca stu campu. Pudete dumandà, hè ancu necessariu? Iè bisognu. Comu dissi prima, u campu importa per Kubernetes. Basatu nantu à l'infurmazioni da questu, kube-scheduler decide nantu à quale nodu pianificà u Pod.

Chì succèri si stabilisce una memoria insufficiente per una dumanda?

Se u cuntinuu hà righjuntu i limiti di a memoria dumandata, u Pod hè postu in un gruppu di Pods chì si fermanu quandu ùn ci hè micca abbastanza memoria in u node.

Chì succede se stabilisce u limitu di memoria troppu bassu?

Se u cuntinuu supera u limitu di memoria, serà terminatu per via di OOM-Killed. È riavviarà s'ellu hè pussibule basatu in RestartPolicy induve u valore predeterminatu hè Always.

Chì succede se ùn specificate micca a memoria dumandata ?

Kubernetes pigliarà u valore limite è l'imposta cum'è u valore predeterminatu.

Chì pò succede se ùn specificate micca un limitu di memoria?

U cuntinuu ùn hà micca restrizioni; pò aduprà a quantità di memoria chì vole. S'ellu principia à utilizà tutta a memoria dispunibile di u node, allora OOM u ucciderà. U cuntinuu serà poi riavviatu s'ellu hè pussibule basatu in RestartPolicy.

Chì succede se ùn specificate micca i limiti di memoria?

Questu hè u peghju scenariu di u casu: u pianificatore ùn sapi quantu risorse u cuntinuu necessita, è questu pò causà seri prublemi nantu à u node. In questu casu, saria bonu per avè limiti predeterminati nantu à u spaziu di nomi (stabilitu da LimitRange). Ùn ci hè micca limiti predeterminati - u Pod ùn hà micca limiti, pò aduprà a quantità di memoria chì vole.

Se a memoria dumandata hè più di u node pò offre, u Pod ùn serà micca pianificatu. Hè impurtante di ricurdà chì Requests.memory - micca u valore minimu. Questa hè una descrizzione di a quantità di memoria abbastanza per mantene u cuntinuu in funzione continuamente.

Di solitu hè cunsigliatu per stabilisce u listessu valore per request.memory и limit.memory. Questu assicura chì Kubernetes ùn pianificerà micca un Pod in un node chì hà abbastanza memoria per eseguisce u Pod ma micca abbastanza per eseguisce. Tenite in mente: a pianificazione di Kubernetes Pod piglia solu in contu requests.memorye limits.memory ùn piglia micca in contu.

CPU: dumanda è limite

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

Cù un CPU tuttu hè un pocu più complicatu. Riturnendu à a stampa di a relazione trà Kubernetes è Docker, pudete vede request.cpu соответствует --cpu-shares, invece limit.cpu currisponde à a bandiera cpus in Docker.

U CPU chì Kubernetes dumanda hè multiplicatu da 1024, a proporzione di ciculi CPU. Se vulete dumandà 1 core full, duvete aghjunghje cpu: 1cum'è mostra sopra.

A dumanda di un kernel sanu (proporzione = 1024) ùn significa micca chì u vostru cuntinuu riceverà. Se a vostra macchina d'ospiti hà solu un core è avete più di un containeru, allora tutti i cuntenituri devenu sparte u CPU dispunibule trà elli. Cumu succede questu? Fighjemu a stampa.

Richiesta CPU - Sistema Single Core

Imaginemu chì avete un sistema d'ospite unicu core chì esegue cuntenituri. Mamma (Kubernetes) hà cottu una torta (CPU) è vole sparte trà i zitelli (contenitori). Trè figlioli volenu una torta sana (proporzione = 1024), un altru zitellu vole a meza torta (512). Mamma vole esse ghjustu è face un calculu simplice.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

Basatu nantu à u calculu, trè figlioli riceveranu 28% di u core, è micca tuttu u core. U quartu figliolu uttene u 14% di u kernel sanu, micca a mità. Ma e cose seranu diverse si avete un sistema multi-core.

Richiesta CPU - Sistema Multi-Core (4).

In l'imaghjini sopra, pudete vede chì trè figlioli volenu una torta sana, è unu vole a mità. Siccomu a mamma hà fattu quattru torte, ognunu di i so figlioli uttene quant'è volenu. In un sistema multi-core, i risorsi di processore sò distribuiti in tutti i nuclei di processore dispunibili. Se un cuntinuu hè limitatu à menu di un core di CPU pienu, pò ancu aduprà à 100%.

I calculi sopra sò simplificati per capisce cumu u CPU hè distribuitu trà i cuntenituri. Di sicuru, in più di i cuntenituri stessi, ci sò altri prucessi chì utilizanu ancu risorse CPU. Quandu i prucessi in un cuntainer sò inattivi, altri ponu utilizà a so risorsa. CPU: "200m" соответствует CPU: 0,2, chì significa circa 20% di un core.

Avà parlemu limit.cpu. U CPU chì Kubernetes limita hè multiplicatu da 100. U risultatu hè a quantità di tempu chì u cuntinuu pò aduprà ogni 100 µs (cpu-period).

limit.cpu currisponde à a bandiera di Docker --cpus. Questa hè una nova cumminazione di vechji --cpu-period и --cpu-quota. Fixendulu, indichemu quante risorse di CPU dispunibuli chì u cuntinuu pò usà massimu prima di inizià a limitazione:

cpus - cumminazzioni cpu-period и cpu-quota. cpus = 1.5 equivalenti à u paràmetru cpu-period = 100000 и cpu-quota = 150000;
U periodu di CPU - periodu Scheduler CPU CFS, predefinitu 100 microsecondi;
cpu-quota - numeru di microsecondi à l'internu cpu-period, chì hè delimitatu da u cuntinuu.

Chì succede se installate un CPU dumandatu insufficiente?

Se u cuntinuu necessita più di ciò chì hà stallatu, arrubbarà CPU da altri prucessi.

Chì succede se stabilisce u limitu CPU troppu bassu?

Siccomu a risorsa CPU hè regulabile, a throttling s'accenderà.

Chì succede se ùn specificate micca una dumanda di CPU?

Cum'è cù a memoria, u valore di dumanda hè uguali à u limitu.

Chì succede se ùn specificate micca un limitu CPU?

U cuntinuu aduprà quantu CPU quantu bisognu. Se una pulitica di CPU predeterminata (LimitRange) hè definita in u namespace, allora stu limitu hè ancu utilizatu per u cuntinuu.

Chì succede se ùn specificate nè una dumanda nè un limitu CPU?

Cum'è cù a memoria, questu hè u peghju scenariu. U pianificatore ùn cunnosci micca quante risorse hà bisognu di u vostru containeru, è questu pò causà seri prublemi nantu à u node. Per evitari questu, avete bisognu di stabilisce limiti predeterminati per i spazii di nomi (LimitRange).

Ricurdativi: se dumandate più CPU chì i nodi ponu furnisce, u Pod ùn serà micca pianificatu. Requests.cpu - micca u valore minimu, ma un valore abbastanza per inizià u Pod è travaglià senza fallimenti. Se l'applicazione ùn faci micca calculi cumplessi, a megliu opzione hè di stallà request.cpu <= 1 è lanciate tante repliche quant'è necessariu.

Quantità ideale di risorse richieste o limitu di risorse

Avemu amparatu nantu à a limitazione di e risorse di l'informatica. Avà hè u tempu di risponde à a quistione: "Quante risorse u mo Pod necessita per eseguisce l'applicazione senza prublemi? Chì ghjè a quantità ideale?

Sfortunatamente, ùn ci sò risposte chjaramente à queste dumande. Se ùn sapete micca cumu funziona a vostra applicazione o quantu CPU o memoria hà bisognu, a megliu opzione hè di dà à l'applicazione assai memoria è CPU è poi eseguite teste di rendiment.

In più di e teste di rendiment, monitorate u cumpurtamentu di l'applicazione in u monitoraghju per una settimana. Se i grafici indicanu chì a vostra applicazione cunsuma menu risorse di ciò chì avete dumandatu, pudete riduce a quantità di CPU o memoria dumandata.

Per esempiu, vede questu Dashboard di Grafana. Mostra a diffarenza trà e risorse richieste o limitu di risorsa è l'utilizazione attuale di e risorse.

cunchiusioni

A dumanda è a limitazione di risorse aiuta à mantene u vostru cluster Kubernetes sanu. A cunfigurazione di limitu curretta minimizza i costi è mantene l'applicazioni in funzione in ogni mumentu.

In breve, ci sò uni pochi di cose da tene à mente:

I risorse richiesti sò una cunfigurazione chì hè presa in contu à u mumentu di l'iniziu (quandu Kubernetes pensa à accoglie l'applicazione). In cuntrastu, a limitazione di e risorse hè impurtante in runtime - quandu l'applicazione hè digià in esecuzione nantu à u node.
Comparatu à a memoria, u CPU hè una risorsa regulata. Se ùn ci hè micca abbastanza CPU, u vostru Pod ùn si chjuderà è u mecanismu di throttling s'accenderà.
E risorse richieste è u limitu di risorse ùn sò micca valori minimi è massimi! Definisce e risorse richieste, assicuratevi chì l'applicazione funziona senza prublemi.
Una bona pratica hè di stabilisce a dumanda di memoria uguale à u limitu di memoria.
Ok installazione dumandata CPU <=1, se l'applicazione ùn eseguisce micca calculi cumplessi.
Se dumandate più risorse ch'è sò dispunibuli nantu à un node, u Pod ùn serà mai pianificatu à quellu node.
Per determinà a quantità curretta di risorse richieste / limiti di risorse, utilizate a prova di carica è u monitoraghju.

Speru chì questu articulu vi aiuta à capisce u cuncettu basu di limitazione di risorse. È puderà applicà sta cunniscenza in u vostru travagliu.

Bona furtuna!

Cosa altru à leghje:

Source: www.habr.com

Cumu accede à e risorse Kubernetes Pod