Para sa bawat mapagkukunan ng Kubernetes, maaari mong i-configure ang dalawang uri ng mga kinakailangan - Mga Kahilingan at Limitasyon. Ang una ay naglalarawan ng mga minimum na kinakailangan para sa pagkakaroon ng mga libreng mapagkukunan ng node na kinakailangan upang magpatakbo ng isang lalagyan o pod, ang pangalawa ay mahigpit na naglilimita sa mga mapagkukunang magagamit sa lalagyan.
Kapag nag-iskedyul ang Kubernetes ng mga pod, napakahalaga na ang mga container ay may sapat na mapagkukunan upang gumana nang maayos. Kung nagpaplano kang mag-deploy ng malaking application sa isang node na limitado sa mapagkukunan, posibleng hindi ito tatakbo dahil ubos na ang memory ng node o nauubusan ng CPU power. Sa artikulong ito, titingnan natin kung paano mo mareresolba ang mga kakulangan ng kuryente sa pag-compute gamit ang mga kahilingan at limitasyon ng mapagkukunan.
Ang Mga Kahilingan at Limitasyon ay mga mekanismo na ginagamit ng Kubernetes upang pamahalaan ang mga mapagkukunan tulad ng CPU at memorya. Ang mga kahilingan ang siyang tumitiyak na natatanggap ng container ang hiniling na mapagkukunan. Kung humiling ang isang container ng mapagkukunan, iiskedyul lang ito ng Kubernetes sa isang node na makakapagbigay nito. Limitado ang kontrol na ang mga mapagkukunang hinihiling ng lalagyan ay hindi lalampas sa isang tiyak na halaga.
Ang isang container ay maaari lamang tumaas ang computing power nito hanggang sa isang partikular na limitasyon, pagkatapos nito ay magiging limitado. Tingnan natin kung paano ito gumagana. Kaya, mayroong dalawang uri ng mga mapagkukunan - processor at memorya. Gumagamit ang scheduler ng Kubernetes ng data tungkol sa mga mapagkukunang ito upang malaman kung saan tatakbo ang iyong mga pod. Ang isang tipikal na detalye ng mapagkukunan para sa isang pod ay ganito ang hitsura.
Ang bawat container sa isang pod ay maaaring magtakda ng sarili nitong mga query at limitasyon, lahat ito ay additive. Ang mga mapagkukunan ng processor ay tinukoy sa mga millicore. Kung ang iyong container ay nangangailangan ng dalawang buong core upang tumakbo, itatakda mo ang halaga sa 2000m. Kung ang lalagyan ay nangangailangan lamang ng kapangyarihan ng 1/4 ng core, ang halaga ay magiging 250m. Tandaan na kung magtatalaga ka ng halaga ng mapagkukunan ng CPU na mas malaki kaysa sa bilang ng mga core ng pinakamalaking node, hindi maiiskedyul na magsimula ang iyong pod. Ang isang katulad na sitwasyon ay magaganap kung mayroon kang Pod na nangangailangan ng apat na core, at ang Kubernetes cluster ay binubuo lamang ng dalawang pangunahing virtual machine.
Maliban kung ang iyong application ay partikular na idinisenyo upang samantalahin ang maraming mga core (mga program tulad ng kumplikadong siyentipikong computing at mga pagpapatakbo ng database ang naiisip), kung gayon ang pinakamahusay na kasanayan ay itakda ang Mga Kahilingan sa CPU sa 1 o mas mababa at pagkatapos ay magpatakbo ng higit pang mga replika sa scalability. Ang solusyon na ito ay magbibigay sa system ng higit na kakayahang umangkop at pagiging maaasahan.
Pagdating sa mga limitasyon ng CPU, ang mga bagay ay nagiging mas kawili-wili dahil ito ay itinuturing na isang compressible na mapagkukunan. Kung magsisimulang lapitan ng iyong application ang limitasyon ng lakas ng processor, sisimulan ng Kubernetes na pabagalin ang iyong container gamit ang CPU Throttling - binabawasan ang dalas ng processor. Nangangahulugan ito na ang CPU ay artipisyal na ma-throttle, na magbibigay sa application ng potensyal na mas masahol na pagganap, ngunit ang proseso ay hindi wawakasan o aalisin.
Ang mga mapagkukunan ng memorya ay tinukoy sa mga byte. Karaniwan ang halaga sa mga setting ay sinusukat sa mebibytes Mib, ngunit maaari kang magtakda ng anumang halaga, mula sa mga byte hanggang sa mga petabytes. Ang parehong sitwasyon ay nalalapat dito tulad ng sa CPU - kung maglalagay ka ng isang kahilingan para sa isang halaga ng memorya na mas malaki kaysa sa dami ng memorya sa iyong mga node, ang pod na iyon ay hindi nakaiskedyul na isagawa. Ngunit hindi tulad ng mga mapagkukunan ng CPU, ang memorya ay hindi naka-compress dahil walang paraan upang limitahan ang paggamit nito. Samakatuwid, ang pagpapatupad ng lalagyan ay ititigil sa sandaling lumampas ito sa memorya na inilaan dito.
Mahalagang tandaan na hindi ka makakapag-configure ng mga kahilingang lampas sa mga mapagkukunang maibibigay ng iyong mga node. Ang mga ibinahaging detalye ng mapagkukunan para sa mga GKE virtual machine ay matatagpuan sa mga link sa ibaba ng video na ito.
Sa isang perpektong mundo, ang mga default na setting ng container ay magiging sapat upang mapanatiling maayos ang mga daloy ng trabaho. Ngunit ang totoong mundo ay hindi ganoon, ang mga tao ay madaling makakalimutan na i-configure ang paggamit ng mga mapagkukunan, o ang mga hacker ay magtatakda ng mga kahilingan at paghihigpit na lumampas sa mga tunay na kakayahan ng imprastraktura. Upang maiwasang mangyari ang mga ganitong sitwasyon, maaari mong i-configure ang ResourceQuota at LimitRange resource quota.
Kapag nalikha na ang isang namespace, maaari itong mai-block gamit ang mga quota. Halimbawa, kung mayroon kang prod at dev namespaces, ang pattern ay walang mga production quota at napakahigpit na development quota. Nagbibigay-daan ito sa prod, kung sakaling magkaroon ng matinding trapiko, na kunin ang buong magagamit na mapagkukunan, na ganap na hinaharangan ang dev.
Maaaring ganito ang hitsura ng quota ng mapagkukunan. Sa halimbawang ito mayroong 4 na seksyon - ito ang 4 na ilalim na linya ng code.
Tingnan natin ang bawat isa sa kanila. Ang Requests.cpu ay ang maximum na bilang ng pinagsamang mga kahilingan sa CPU na maaaring magmula sa lahat ng container sa namespace. Sa halimbawang ito, maaari kang magkaroon ng 50 container na may 10m request, limang container na may 100m request, o isang container lang na may 500m request. Hangga't ang kabuuang bilang ng requests.cpu ng isang ibinigay na namespace ay mas mababa sa 500m, magiging maayos ang lahat.
Ang memory requested requests.memory ay ang maximum na dami ng pinagsamang memory request na maaaring magkaroon ng lahat ng container sa namespace. Tulad ng sa nakaraang kaso, maaari kang magkaroon ng 50 2 mib container, limang 20 mib container, o isang solong 100 mib container hangga't ang kabuuang halaga ng memory na hinihiling sa namespace ay mas mababa sa 100 mebibytes.
Ang Limits.cpu ay ang maximum na pinagsamang dami ng CPU power na magagamit ng lahat ng container sa namespace. Maaari naming isaalang-alang na ito ang limitasyon ng mga kahilingan sa kapangyarihan ng processor.
Panghuli, ang limits.memory ay ang maximum na dami ng shared memory na magagamit ng lahat ng container sa namespace. Ito ay isang limitasyon sa kabuuang mga kahilingan sa memorya.
Kaya, bilang default, ang mga container sa isang Kubernetes cluster ay tumatakbo na may walang limitasyong mga mapagkukunan sa pag-compute. Sa mga quota ng mapagkukunan, maaaring limitahan ng mga administrator ng cluster ang pagkonsumo ng mapagkukunan at paggawa ng mapagkukunan batay sa namespace. Sa isang namespace, ang isang pod o container ay maaaring kumonsumo ng mas maraming CPU power at memory gaya ng tinutukoy ng namespace resource quota. Gayunpaman, mayroong isang alalahanin na maaaring monopolyo ng isang pod o container ang lahat ng magagamit na mapagkukunan. Upang maiwasan ang sitwasyong ito, ginagamit ang isang limit range - isang patakaran para sa paglilimita sa paglalaan ng mga mapagkukunan (para sa mga pod o container) sa namespace.
Ang saklaw ng limitasyon ay nagbibigay ng mga paghihigpit na maaaring:
- Tiyakin ang minimum at maximum na paggamit ng computing resources para sa bawat module o container sa namespace;
- ipatupad ang minimum at maximum na mga kahilingan sa storage ng Starage Request para sa bawat PersistentVolumeClaim sa namespace;
- ipatupad ang isang relasyon sa pagitan ng isang Kahilingan at isang Limitasyon para sa isang mapagkukunan sa isang namespace;
- itakda ang mga default na Kahilingan/Limit para sa pagkalkula ng mga mapagkukunan sa namespace at awtomatikong ipasok ang mga ito sa mga lalagyan sa oras ng pagtakbo.
Sa paraang ito makakagawa ka ng limit range sa iyong namespace. Hindi tulad ng isang quota, na nalalapat sa buong namespace, ang Limit Range ay ginagamit para sa mga indibidwal na container. Maaari nitong pigilan ang mga user na gumawa ng napakaliit o, kabaligtaran, malalaking lalagyan sa loob ng namespace. Maaaring ganito ang hitsura ng Limit Range.
Tulad ng sa nakaraang kaso, 4 na seksyon ang maaaring makilala dito. Tingnan natin ang bawat isa.
Itinatakda ng default na seksyon ang mga default na limitasyon para sa container sa pod. Kung itinakda mo ang mga halagang ito sa sukdulang saklaw, ang anumang mga lalagyan kung saan ang mga halagang ito ay hindi pa tahasang itinakda ay susunod sa mga default na halaga.
Kino-configure ng default na seksyon ng kahilingan defaultRequest ang mga default na kahilingan para sa lalagyan sa pod. Muli, kung itatakda mo ang mga halagang ito sa matinding saklaw, ang anumang mga lalagyan na hindi tahasang nagtatakda ng mga opsyong ito ay magiging default sa mga halagang ito.
Tinutukoy ng max na seksyon ang mga maximum na limitasyon na maaaring itakda para sa isang container sa pod. Ang mga halaga sa default na seksyon at mga limitasyon ng container ay hindi maaaring itakda sa itaas ng limitasyong ito. Mahalagang tandaan na kung ang halaga ay nakatakda sa max at walang default na seksyon, ang maximum na halaga ay magiging default na halaga.
Ang seksyon ng min ay tumutukoy sa mga minimum na kahilingan na maaaring itakda para sa isang lalagyan sa isang pod. Gayunpaman, ang mga halaga sa default na seksyon at mga query para sa lalagyan ay hindi maaaring itakda sa ibaba ng limitasyong ito.
Muli, mahalagang tandaan na kung ang halagang ito ay itinakda, ang default ay hindi, kung gayon ang pinakamababang halaga ang magiging default na prompt.
Ang mga kahilingan sa resource na ito ay ginagamit ng Kubernetes scheduler para isagawa ang iyong mga workload. Upang ma-configure mo nang tama ang iyong mga lalagyan, napakahalagang maunawaan kung paano ito gumagana. Sabihin nating gusto mong magpatakbo ng maraming pod sa iyong cluster. Kung ipagpalagay na valid ang mga detalye ng pod, gagamit ang iskedyul ng Kubernetes ng round robin balancing para pumili ng node na magpapatakbo ng workload.
Susuriin ng Kubernetes kung ang Node 1 ay may sapat na mapagkukunan upang matupad ang mga kahilingan mula sa mga container ng pod, at kung hindi, magpapatuloy ito sa susunod na node. Kung wala sa mga node sa system ang makakatugon sa mga kahilingan, ang mga pod ay mapupunta sa Nakabinbing estado. Gamit ang mga feature ng engine ng Google Kubernetes gaya ng autoscaling ng node, maaaring awtomatikong makita ng GKE ang status ng paghihintay at lumikha ng higit pang mga karagdagang node.
Kung pagkatapos ay maubusan ka ng kapasidad ng node, babawasan ng autoscaling ang bilang ng mga node upang makatipid ka ng pera. Ito ang dahilan kung bakit nag-iskedyul ang Kubernetes ng mga pod batay sa mga kahilingan. Gayunpaman, ang limitasyon ay maaaring mas mataas kaysa sa mga kahilingan, at sa ilang mga kaso ang node ay maaaring aktwal na maubusan ng mga mapagkukunan. Tinatawag namin ang estadong ito na overcommitment state.
Gaya ng sinabi ko, pagdating sa CPU, sisimulan ng Kubernetes na limitahan ang mga pod. Ang bawat pod ay makakatanggap hangga't hinihiling nito, ngunit kung hindi ito umabot sa limitasyon, magsisimulang mag-apply ang throttling.
Pagdating sa mga mapagkukunan ng memorya, ang Kubernetes ay napipilitang gumawa ng mga pagpapasya tungkol sa kung aling mga pod ang tatanggalin at kung alin ang pananatilihin hanggang sa mabakante mo ang mga mapagkukunan ng system o ang buong system ay mag-crash.
Isipin natin ang isang senaryo kung saan mayroon kang isang makina na nauubusan ng memory - paano ito haharapin ng Kubernetes?
Maghahanap ang Kubernetes ng mga pod na gumagamit ng mas maraming mapagkukunan kaysa sa hiniling nila. Kaya't kung ang iyong mga container ay walang mga Kahilingan, nangangahulugan iyon na hindi sila gumagamit ng higit pa kaysa sa hiniling nila, dahil hindi sila humiling ng kahit ano! Ang ganitong mga lalagyan ay nagiging pangunahing kandidato para sa pagsasara. Ang mga susunod na kandidato ay mga lalagyan na natugunan ang lahat ng kanilang mga kahilingan ngunit mas mababa pa rin sa maximum na limitasyon.
Kaya't kung makakita ang Kubernetes ng ilang pod na lumampas sa kanilang mga parameter ng kahilingan, pag-uuri-uriin nito ang mga ito ayon sa priyoridad at pagkatapos ay aalisin ang pinakamababang priyoridad na pod. Kung ang lahat ng pod ay may parehong priyoridad, wawakasan ng Kubernetes ang mga pod na lumampas sa kanilang mga kahilingan nang higit sa iba pang pod.
Sa napakabihirang mga kaso, maaaring i-abort ng Kubernetes ang mga pod na nasa saklaw pa rin ng kanilang mga kahilingan. Ito ay maaaring mangyari kapag ang mga kritikal na bahagi ng system tulad ng ahente ng Kubelet o Docker ay nagsimulang kumonsumo ng mas maraming mapagkukunan kaysa sa kung ano ang nakalaan para sa kanila.
Kaya, sa mga unang yugto ng maliliit na kumpanya, maaaring gumana nang maayos ang isang Kubernetes cluster nang hindi nagtatakda ng mga kahilingan at paghihigpit sa mapagkukunan, ngunit habang nagsisimulang lumaki ang iyong mga koponan at proyekto, nagkakaroon ka ng panganib na magkaroon ng mga problema sa lugar na ito. Ang pagdaragdag ng mga query at mga hadlang sa iyong mga module at namespace ay nangangailangan ng napakakaunting dagdag na pagsisikap at makakapagtipid ng maraming abala.
Ilang ad π
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com