Kapag nagsimula sa Kubernetes, karaniwan nang kalimutan ang tungkol sa pag-set up ng mga mapagkukunan ng container. Sa puntong ito, sapat na upang matiyak na gumagana ang imahe ng Docker at maaaring i-deploy sa cluster ng Kubernetes.
Ngunit sa ibang pagkakataon ang application ay kailangang i-deploy sa isang production cluster kasama ng iba pang mga application. Upang gawin ito, kailangan mong maglaan ng mga mapagkukunan para sa lalagyan at tiyaking sapat ang mga ito upang mapatakbo ang application, at ang ibang tumatakbong mga application ay hindi makakaranas ng mga problema.
Koponan nagsalin ng artikulo tungkol sa mga mapagkukunan ng container (CPU at MEM), mga kahilingan at mga limitasyon sa mapagkukunan. Malalaman mo ang mga benepisyo ng mga setting na ito at kung ano ang mangyayari kung hindi mo itatakda ang mga ito.
Mga mapagkukunan sa pag-compute
Mayroon kaming dalawang uri ng mga mapagkukunan na may mga sumusunod na yunit:
- Central processing unit (CPU) - mga core;
- Memorya (MEM) - mga byte.
Tinukoy ang mga mapagkukunan para sa bawat lalagyan. Sa sumusunod na Pod YAML file, makakakita ka ng seksyon ng mapagkukunan na naglalaman ng hiniling at limitasyon ng mga mapagkukunan:
- Hiniling na Mga Mapagkukunan ng Pod = kabuuan ng mga hiniling na mapagkukunan ng lahat ng mga lalagyan;
- Pod Resource Limit = Kabuuan ng lahat ng Pod Resource Limits.
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: 1GiHalimbawa ng Hiniling at Limitadong Mga Mapagkukunan
Field resources.requested mula sa detalye Ang Pod ay isa sa mga elemento na ginagamit upang mahanap ang nais na node. Maaari mo nang planuhin ang pag-deploy ng Pod para dito. Paano ka makakahanap ng angkop na node?
Ang Kubernetes ay binubuo ng ilang bahagi, kabilang ang isang master node o master node (Kubernetes Control Plane). Ang master node ay may ilang mga proseso: kube-apiserver, kube-controller-manager at kube-scheduler.
Ang proseso ng kube-scheduler ay responsable para sa pagsusuri ng mga bagong likhang pod at paghahanap ng mga posibleng worker node na tumutugma sa lahat ng mga kahilingan sa pod, kabilang ang bilang ng mga mapagkukunang hiniling. Ang listahan ng mga node na natagpuan ng kube-scheduler ay niraranggo. Naka-iskedyul ang pod sa node na may pinakamataas na marka.
Saan ilalagay ang purple Pod?
Sa larawan makikita mo na ang kube-scheduler ay dapat mag-iskedyul ng bagong purple Pod. Ang Kubernetes cluster ay naglalaman ng dalawang node: A at B. Gaya ng nakikita mo, ang kube-scheduler ay hindi makakapag-iskedyul ng Pod sa node A - ang mga available (hindi hiniling) na mapagkukunan ay hindi tumutugma sa mga kahilingan ng purple na Pod. Kaya, ang 1 GB ng memorya na hiniling ng purple Pod ay hindi magkasya sa node A, dahil ang available na memory ay 0,5 GB. Ngunit ang node B ay may sapat na mapagkukunan. Bilang resulta, nagpasya ang kube-scheduler na ang destinasyon ng purple Pod ay node B.
Ngayon alam na natin kung paano nakakaapekto ang mga hiniling na mapagkukunan sa pagpili ng node para patakbuhin ang Pod. Ngunit ano ang epekto ng marginal resources?
Ang limitasyon ng mapagkukunan ay isang hangganan na hindi maaaring lampasan ng CPU/MEM. Gayunpaman, ang mapagkukunan ng CPU ay nababaluktot, kaya ang mga lalagyan na umabot sa kanilang mga limitasyon sa CPU ay hindi magiging sanhi ng pag-alis ng Pod. Sa halip, magsisimula ang CPU throttling. Kung naabot ang limitasyon sa paggamit ng MEM, ititigil ang container dahil sa OOM-Killer at magre-restart kung pinapayagan ng setting ng RestartPolicy.
Hiling at maximum na mapagkukunan sa detalye
Resource communication sa pagitan ng Docker at Kubernetes
Ang pinakamahusay na paraan upang ipaliwanag kung paano gumagana ang mga kahilingan sa mapagkukunan at mga limitasyon sa mapagkukunan ay upang ipakilala ang ugnayan sa pagitan ng Kubernetes at Docker. Sa larawan sa itaas makikita mo kung paano nauugnay ang mga field ng Kubernetes at mga flag ng Docker startup.
Memorya: kahilingan at limitasyon
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Tulad ng nabanggit sa itaas, ang memorya ay sinusukat sa bytes. Batay sa , maaari naming tukuyin ang memorya bilang isang numero. Kadalasan ito ay isang integer, halimbawa 2678 - iyon ay, 2678 bytes. Maaari ka ring gumamit ng mga suffix G ΠΈ Gi, ang pangunahing bagay ay tandaan na hindi sila katumbas. Ang una ay decimal at ang pangalawa ay binary. Tulad ng halimbawang binanggit sa k8s na dokumentasyon: 128974848, 129e6, 129M, 123Mi - halos magkatumbas sila.
Pagpipilian sa Kubernetes limits.memory tumutugma sa bandila --memory mula sa Docker. Kung sakali request.memory Walang arrow para sa Docker dahil hindi ginagamit ng Docker ang field na ito. Maaari mong itanong, kailangan pa ba ito? Oo kailangan. Gaya ng sinabi ko kanina, mahalaga ang field para sa Kubernetes. Batay sa impormasyon mula dito, ang kube-scheduler ay nagpapasya kung aling node ang iiskedyul ang Pod.
Ano ang mangyayari kung nagtakda ka ng hindi sapat na memorya para sa isang kahilingan?
Kung ang lalagyan ay umabot sa mga limitasyon ng hiniling na memorya, ang Pod ay ilalagay sa isang pangkat ng mga Pod na hihinto kapag walang sapat na memorya sa node.
Ano ang mangyayari kung itinakda mo ang limitasyon ng memorya ng masyadong mababa?
Kung ang lalagyan ay lumampas sa limitasyon ng memorya, ito ay wawakasan dahil sa OOM-Killed. At magre-restart kung posible batay sa RestartPolicy kung saan ang default na halaga ay Always.
Ano ang mangyayari kung hindi mo tinukoy ang hiniling na memorya?
Kukunin ng Kubernetes ang halaga ng limitasyon at itatakda ito bilang default na halaga.
Ano ang maaaring mangyari kung hindi ka tumukoy ng limitasyon sa memorya?
Ang lalagyan ay walang mga paghihigpit; maaari itong gumamit ng mas maraming memorya hangga't gusto nito. Kung sisimulan niyang gamitin ang lahat ng magagamit na memorya ng node, papatayin siya ng OOM. Ire-restart ang container kung maaari batay sa RestartPolicy.
Ano ang mangyayari kung hindi mo tinukoy ang mga limitasyon ng memorya?
Ito ang pinakamasamang sitwasyon ng kaso: hindi alam ng scheduler kung gaano karaming mga mapagkukunan ang kailangan ng lalagyan, at maaari itong magdulot ng malubhang problema sa node. Sa kasong ito, mainam na magkaroon ng mga default na limitasyon sa namespace (itinakda ng LimitRange). Walang mga default na limitasyon - ang Pod ay walang mga limitasyon, maaari itong gumamit ng mas maraming memorya hangga't gusto nito.
Kung ang hiniling na memorya ay higit pa sa maiaalok ng node, hindi maiiskedyul ang Pod. Mahalagang tandaan iyon Requests.memory - hindi ang pinakamababang halaga. Ito ay isang paglalarawan ng dami ng memorya na sapat upang panatilihing patuloy na tumatakbo ang lalagyan.
Karaniwang inirerekomendang itakda ang parehong halaga para sa request.memory ΠΈ limit.memory. Tinitiyak nito na hindi mag-iskedyul ang Kubernetes ng Pod sa isang node na may sapat na memorya para patakbuhin ang Pod ngunit hindi sapat para patakbuhin ito. Tandaan: Isinasaalang-alang lamang ang pagpaplano ng Kubernetes Pod requests.memoryAt limits.memory hindi isinasaalang-alang.
CPU: kahilingan at limitasyon
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Sa isang CPU ang lahat ay medyo mas kumplikado. Pagbabalik sa larawan ng relasyon sa pagitan ng Kubernetes at Docker, makikita mo iyon request.cpu tumutugma sa --cpu-shares, samantalang limit.cpu tumutugma sa bandila cpus sa Docker.
Ang CPU na hinihiling ng Kubernetes ay pinarami ng 1024, ang proporsyon ng mga cycle ng CPU. Kung gusto mong humiling ng 1 buong core, dapat kang magdagdag cpu: 1tulad ng ipinapakita sa itaas.
Ang paghiling ng buong kernel (proporsyon = 1024) ay hindi nangangahulugang matatanggap ito ng iyong container. Kung ang iyong host machine ay may isang core lamang at nagpapatakbo ka ng higit sa isang lalagyan, ang lahat ng mga lalagyan ay dapat magbahagi ng magagamit na CPU sa pagitan nila. Paano ito nangyayari? Tingnan natin ang larawan.
Kahilingan sa CPU - Single Core System
Isipin natin na mayroon kang single-core host system na nagpapatakbo ng mga container. Nagluto si Nanay (Kubernetes) ng pie (CPU) at gustong hatiin ito sa mga bata (mga lalagyan). Gusto ng tatlong bata ng isang buong pie (proporsyon = 1024), gusto ng isa pang bata ng kalahating pie (512). Nais ni Nanay na maging patas at gumawa ng isang simpleng pagkalkula.
# Π‘ΠΊΠΎΠ»ΡΠΊΠΎ ΠΏΠΈΡΠΎΠ³ΠΎΠ² Ρ
ΠΎΡΡΡ Π΄Π΅ΡΠΈ?
# 3 ΡΠ΅Π±Π΅Π½ΠΊΠ° Ρ
ΠΎΡΡΡ ΠΏΠΎ ΡΠ΅Π»ΠΎΠΌΡ ΠΏΠΈΡΠΎΠ³Ρ ΠΈ Π΅ΡΠ΅ ΠΎΠ΄ΠΈΠ½ Ρ
ΠΎΡΠ΅Ρ ΠΏΠΎΠ»ΠΎΠ²ΠΈΠ½Ρ ΠΏΠΈΡΠΎΠ³Π°
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# ΠΡΡΠ°ΠΆΠ΅Π½ΠΈΠ΅ ΠΏΠΎΠ»ΡΡΠ°Π΅ΡΡΡ ΡΠ°ΠΊ:
3 (ΡΠ΅Π±Π΅Π½ΠΊΠ°/ΠΊΠΎΠ½ΡΠ΅ΠΉΠ½Π΅ΡΠ°) * 1 (ΡΠ΅Π»ΡΠΉ ΠΏΠΈΡΠΎΠ³/ΠΏΠΎΠ»Π½ΠΎΠ΅ ΡΠ΄ΡΠΎ) + 1 (ΡΠ΅Π±Π΅Π½ΠΎΠΊ/ΠΊΠΎΠ½ΡΠ΅ΠΉΠ½Π΅Ρ) * 0.5 (ΠΏΠΎΠ»ΠΎΠ²ΠΈΠ½Π° ΠΏΠΈΡΠΎΠ³Π°/ΠΏΠΎΠ»ΠΎΠ²ΠΈΠ½Π° ΡΠ΄ΡΠ°)
# Π‘ΠΊΠΎΠ»ΡΠΊΠΎ ΠΏΠΈΡΠΎΠ³ΠΎΠ² ΠΈΡΠΏΠ΅ΡΠ΅Π½ΠΎ?
availableCakesNumber = 1
# Π‘ΠΊΠΎΠ»ΡΠΊΠΎ ΠΏΠΈΡΠΎΠ³Π° (ΠΌΠ°ΠΊΡΠΈΠΌΠ°Π»ΡΠ½ΠΎ) Π΄Π΅ΡΠΈ ΡΠ΅Π°Π»ΡΠ½ΠΎ ΠΌΠΎΠ³ΡΡ ΠΏΠΎΠ»ΡΡΠΈΡΡ?
newMaxRequest = 1 / 3.5 =~ 28%Batay sa kalkulasyon, tatlong bata ang makakatanggap ng 28% ng core, at hindi ang buong core. Ang ikaapat na bata ay makakakuha ng 14% ng buong kernel, hindi kalahati. Ngunit mag-iiba ang mga bagay kung mayroon kang multi-core system.
Kahilingan sa CPU - Multi-Core (4) System
Sa larawan sa itaas makikita mo na tatlong bata ang gusto ng isang buong pie, at ang isa ay gusto ng kalahati. Dahil ang nanay ay naghurno ng apat na pie, bawat isa sa kanyang mga anak ay makakakuha ng marami hangga't gusto nila. Sa isang multi-core system, ang mga mapagkukunan ng processor ay ipinamamahagi sa lahat ng magagamit na mga core ng processor. Kung ang isang container ay limitado sa mas mababa sa isang buong CPU core, maaari pa rin itong gamitin sa 100%.
Ang mga kalkulasyon sa itaas ay pinasimple upang maunawaan kung paano ipinamamahagi ang CPU sa mga lalagyan. Siyempre, bukod sa mga lalagyan mismo, may iba pang mga proseso na gumagamit din ng mga mapagkukunan ng CPU. Kapag ang mga proseso sa isang lalagyan ay idle, magagamit ng iba ang mapagkukunan nito. CPU: "200m" tumutugma sa CPU: 0,2, na nangangahulugang humigit-kumulang 20% ββng isang core.
Ngayon pag-usapan natin limit.cpu. Ang CPU na nililimitahan ng Kubernetes ay pinarami ng 100. Ang resulta ay ang dami ng oras na magagamit ng container bawat 100 Β΅s (cpu-period).
limit.cpu tumutugma sa bandila ng Docker --cpus. Ito ay isang bagong kumbinasyon ng luma --cpu-period ΠΈ --cpu-quota. Sa pamamagitan ng pagtatakda nito, ipinapahiwatig namin kung gaano karaming magagamit na mga mapagkukunan ng CPU ang pinakamaraming magagamit ng container bago magsimula ang throttling:
- cpus - kumbinasyon
cpu-periodΠΈcpu-quota. cpus = 1.5katumbas ng settingcpu-period = 100000ΠΈcpu-quota = 150000; - CPU-panahon - panahon , default na 100 microseconds;
- cpu-quota - bilang ng mga microsecond sa loob
cpu-period, na nakatali sa lalagyan.
Ano ang mangyayari kung nag-install ka ng hindi sapat na hiniling na CPU?
Kung ang lalagyan ay nangangailangan ng higit sa na-install nito, ito ay magnanakaw ng CPU mula sa iba pang mga proseso.
Ano ang mangyayari kung itinakda mo nang masyadong mababa ang limitasyon ng CPU?
Dahil adjustable ang resource ng CPU, mag-o-on ang throttling.
Ano ang mangyayari kung hindi ka tumukoy ng kahilingan sa CPU?
Tulad ng memorya, ang halaga ng kahilingan ay katumbas ng limitasyon.
Ano ang mangyayari kung hindi ka tumukoy ng limitasyon sa CPU?
Gagamitin ng container ang mas maraming CPU hangga't kailangan nito. Kung ang isang default na patakaran ng CPU (LimitRange) ay tinukoy sa namespace, ginagamit din ang limitasyong ito para sa container.
Ano ang mangyayari kung hindi mo tinukoy ang alinman sa isang kahilingan o isang limitasyon ng CPU?
Tulad ng memorya, ito ang pinakamasamang sitwasyon. Hindi alam ng scheduler kung gaano karaming mga mapagkukunan ang kailangan ng iyong container, at maaari itong magdulot ng malubhang problema sa node. Upang maiwasan ito, kailangan mong magtakda ng mga default na limitasyon para sa mga namespace (LimitRange).
Tandaan: kung humiling ka ng mas maraming CPU kaysa sa maibibigay ng mga node, hindi maiiskedyul ang Pod. Requests.cpu - hindi ang pinakamababang halaga, ngunit sapat na halaga upang simulan ang Pod at gumana nang walang pagkabigo. Kung ang application ay hindi nagsasagawa ng mga kumplikadong kalkulasyon, ang pinakamagandang opsyon ay ang pag-install request.cpu <= 1 at maglunsad ng maraming replika kung kinakailangan.
Tamang-tama na dami ng hiniling na mapagkukunan o limitasyon ng mapagkukunan
Nalaman namin ang tungkol sa limitasyon ng mga mapagkukunan sa pag-compute. Ngayon ay oras na upang sagutin ang tanong na: "Gaano karaming mga mapagkukunan ang kailangan ng aking Pod upang patakbuhin ang application nang walang anumang mga problema? Ano ang ideal na halaga?
Sa kasamaang palad, walang malinaw na sagot sa mga tanong na ito. Kung hindi mo alam kung paano gumagana ang iyong application o kung gaano karaming CPU o memory ang kailangan nito, ang pinakamagandang opsyon ay bigyan ang application ng maraming memory at CPU at pagkatapos ay magpatakbo ng mga pagsubok sa pagganap.
Bilang karagdagan sa mga pagsubok sa pagganap, subaybayan ang gawi ng application sa pagsubaybay sa loob ng isang linggo. Kung ang mga graph ay nagpapahiwatig na ang iyong application ay gumagamit ng mas kaunting mga mapagkukunan kaysa sa iyong hiniling, maaari mong bawasan ang halaga ng CPU o memory na hiniling.
Bilang isang halimbawa tingnan ito . Ipinapakita nito ang pagkakaiba sa pagitan ng hiniling na mga mapagkukunan o limitasyon ng mapagkukunan at ang kasalukuyang paggamit ng mapagkukunan.
Konklusyon
Ang paghiling at paglilimita sa mga mapagkukunan ay nakakatulong na panatilihing malusog ang iyong Kubernetes cluster. Ang wastong pagsasaayos ng limitasyon ay nagpapaliit ng mga gastos at nagpapanatiling tumatakbo ang mga application sa lahat ng oras.
Sa madaling salita, may ilang bagay na dapat tandaan:
- Ang mga hiniling na mapagkukunan ay isang pagsasaayos na isinasaalang-alang sa oras ng pagsisimula (kapag plano ng Kubernetes na i-host ang application). Sa kabaligtaran, ang paglilimita sa mga mapagkukunan ay mahalaga sa runtime-kapag ang application ay tumatakbo na sa node.
- Kung ikukumpara sa memorya, ang CPU ay isang regulated na mapagkukunan. Kung walang sapat na CPU, hindi magsasara ang iyong Pod at mag-o-on ang mekanismo ng throttling.
- Ang mga hiniling na mapagkukunan at limitasyon ng mapagkukunan ay hindi minimum at maximum na mga halaga! Sa pamamagitan ng pagtukoy sa hinihiling na mga mapagkukunan, tinitiyak mong tatakbo ang application nang walang mga problema.
- Ang isang mahusay na kasanayan ay upang itakda ang kahilingan ng memorya na katumbas ng limitasyon ng memorya.
- Ok, hiniling ang pag-install
CPU <=1, kung ang application ay hindi nagsasagawa ng mga kumplikadong kalkulasyon. - Kung humiling ka ng higit pang mga mapagkukunan kaysa sa magagamit sa isang node, ang Pod ay hindi kailanman maiiskedyul sa node na iyon.
- Upang matukoy ang tamang dami ng hiniling na mga resource/limitasyon sa mapagkukunan, gumamit ng pagsubok sa pagkarga at pagsubaybay.
Sana ay matulungan ka ng artikulong ito na maunawaan ang pangunahing konsepto ng limitasyon ng mapagkukunan. At magagawa mong gamitin ang kaalamang ito sa iyong trabaho.
Good luck!
Ano pa ang dapat basahin:
- .
- .
- .
Pinagmulan: www.habr.com