Alang sa matag kapanguhaan sa Kubernetes, posible nga i-configure ang duha ka klase nga kinahanglanon - Mga Pangayo ug Limitasyon. Ang una naghulagway sa minimum nga mga kinahanglanon alang sa libre nga mga kapanguhaan sa node nga gikinahanglan sa pagpadagan sa usa ka sudlanan o pod, ang ikaduha grabe nga naglimite sa mga kapanguhaan nga anaa sa sudlanan.
Kung ang Kubernetes nagplano og mga pod, importante kaayo nga ang mga sudlanan adunay igong kahinguhaan nga modagan sa normal. Kung nagplano ka nga magbutang usa ka dako nga aplikasyon sa usa ka host nga gipugngan sa kapanguhaan, posible nga dili kini modagan tungod kay ang host nahutdan sa memorya o nahutdan sa gahum sa processor. Niini nga artikulo, atong tan-awon kung giunsa nimo masulbad ang mga problema sa kakulang sa gahum sa pag-compute gamit ang mga hangyo sa kapanguhaan ug mga pagdili.
Ang mga hangyo ug Limitasyon maoy mga mekanismo nga gigamit sa Kubernetes sa pagdumala sa mga kahinguhaan sama sa CPU ug memorya. Ang mga hangyo mao ang nagsiguro nga makuha sa sudlanan ang gihangyo nga kapanguhaan. Kung ang usa ka sudlanan mangayo usa ka kapanguhaan, ang Kubernetes mag-iskedyul lang niini sa usa ka node nga makahatag niini. Limitado ang pagkontrol nga ang mga kahinguhaan nga gipangayo sa sudlanan dili gyud molapas sa usa ka piho nga kantidad.
Ang sudlanan mahimo ra nga motubo ang gahum sa pag-compute hangtod sa usa ka piho nga limitasyon, pagkahuman kini limitado. Atong tan-awon kon sa unsang paagi kini molihok. Busa, adunay duha ka matang sa mga kapanguhaan - processor ug memorya. Ang Kubernetes scheduler naggamit niini nga mga kapanguhaan aron mahibal-an kung asa modagan ang imong mga pod. Ang usa ka tipikal nga espesipikasyon sa kapanguhaan alang sa usa ka pod ingon niini.
Ang matag sudlanan sa usa ka pod mahimong magtakda sa kaugalingon nga mga hangyo ug limitasyon, kini tanan additive. Ang mga kapanguhaan sa processor gihubit sa millicore. Kung ang imong sudlanan nanginahanglan duha ka bug-os nga core aron modagan, imong gibutang ang kantidad sa 2000m. Kon ang sudlanan nagkinahanglan lamang sa 1/4 core gahum, ang bili mahimong 250m. Hibaloi nga kon mag-assign ka ug CPU nga resource value nga mas dako pa sa gidaghanon sa mga cores sa kinadak-ang node, nan ang imong pod dili na maeskedyul nga magsugod sa tanan. Ang usa ka susama nga sitwasyon mahitabo kung ikaw adunay usa ka pod nga nagkinahanglan og upat ka mga cores, ug ang Kubernetes cluster naglangkob lamang sa duha ka nag-unang virtual machines.
Gawas lang kung ang imong aplikasyon espesipikong gidesinyo aron mapahimuslan ang daghang mga cores (busa ang mga programa sama sa komplikado nga mga kalkulasyon sa siyensya ug mga operasyon sa database moabut sa hunahuna), nan ang labing kaayo nga praktis mao ang pagtakda sa Mga Pangayo sa CPU sa 1 o mas ubos ug dayon pagpadagan sa daghang mga replika sa scalability. Kini nga solusyon maghatag sa sistema nga labi ka dali ug kasaligan.
Kung bahin sa mga limitasyon sa CPU, ang mga butang mahimong labi ka makapaikag tungod kay kini giisip nga usa ka compressible nga kapanguhaan. Kung ang imong aplikasyon magsugod sa pagduol sa limitasyon sa CPU, ang Kubernetes magsugod sa pag-throttling sa imong sudlanan gamit ang CPU Throttling. Kini nagpasabot nga ang processor mahimong artipisyal nga limitado, nga maghatag sa aplikasyon sa posibleng mas grabe nga performance, apan ang proseso dili mahunong o ma-render.
Ang mga kapanguhaan sa memorya gihubit sa mga byte. Kasagaran ang kantidad sa mga setting gisukod sa Mib mebibytes, apan mahimo nimo kini ibutang sa bisan unsang kantidad, gikan sa mga byte hangtod sa mga petabytes. Ang sitwasyon dinhi parehas sa CPU - kung maghangyo ka alang sa usa ka kantidad sa memorya nga molapas sa gidaghanon sa memorya sa imong mga node, ang pagpatuman niini nga pod dili ma-iskedyul. Apan dili sama sa mga kahinguhaan sa CPU, ang memorya dili ma-compress tungod kay walay paagi nga limitahan ang paggamit niini. Busa, ang pagpatuman sa sudlanan ihunong sa diha nga kini mahurot sa memorya nga gigahin niini.
Importante nga hinumdoman nga dili nimo ma-configure ang mga hangyo nga molapas sa gidaghanon sa mga kapanguhaan nga mahatag sa imong mga node. Ang mga detalye sa pagpaambit alang sa GKE VMs makita sa mga link sa ubos niini nga video.
Sa usa ka sulundon nga kalibutan, ang default nga mga setting sa sudlanan igo na aron magpadayon nga hapsay ang mga daloy sa trabaho. Apan ang tinuod nga kalibutan dili ingon niana, ang mga tawo dali nga makalimot sa pag-adjust sa paggamit sa kahinguhaan, o ang mga hacker magtakda og mga hangyo ug mga limitasyon nga molapas sa aktwal nga kapabilidad sa imprastraktura. Aron mapugngan ang maong mga senaryo, mahimo nimong i-configure ang ResourceQuota resource quota ug LimitRange ranges.
Kung nahimo na ang usa ka namespace, mahimo silang ma-lock gamit ang mga quota. Pananglitan, kung ikaw adunay prod ug dev namespaces, ang sumbanan mao nga wala gayuy mga quota sa produksiyon, ug ang mga quota sa pag-uswag higpit kaayo. Gitugotan niini ang prod nga makuha ang tanan nga magamit nga kapanguhaan kung adunay kusog nga pagtaas sa trapiko, hingpit nga gibabagan ang dev.
Ang usa ka quota sa kapanguhaan mahimong ingon niini. Niini nga pananglitan, adunay 4 ka seksyon - kini ang 4 ka ubos nga linya sa code.
Atong tan-awon ang matag usa kanila. Ang Requests.cpu mao ang kinatas-ang gidaghanon sa hiniusang hangyo alang sa gahum sa CPU nga mahimong gikan sa tanang namespace nga sudlanan. Niini nga pananglitan, mahimo kang adunay 50 ka container nga adunay 10m request, lima ka container nga adunay 100m requests, o usa lang ka container nga adunay 500m requests. Hangtud nga ang kinatibuk-ang gidaghanon sa mga requests.cpu sa usa ka namespace ubos pa sa 500m, ang tanan maayo ra.
Gihangyo nga memory requests.memory mao ang pinakataas nga gidaghanon sa hiniusa nga memory requests nga maangkon sa tanang sudlanan sa namespace. Sama sa miaging kaso, mahimo kang adunay 50 2 mib nga sudlanan, lima ka 20 mib nga sudlanan, o usa ka 100 mib nga sudlanan basta ang kinatibuk-ang gidaghanon sa memorya nga gihangyo sa namespace dili moubos sa 100 mebibytes.
Ang Limits.cpu mao ang pinakataas nga hiniusang gidaghanon sa gahum sa processor nga magamit sa tanang namespace nga sudlanan. Mahimo natong hunahunaon nga kini ang limitasyon sa mga hangyo sa gahum sa processor.
Sa kataposan, ang limits.memory mao ang kinatas-ang gidaghanon sa shared memory nga magamit sa tanang sudlanan sa namespace. Kini ang limitasyon sa kinatibuk-ang hangyo sa memorya.
Busa, pinaagi sa default, ang mga sudlanan sa usa ka Kubernetes cluster modagan uban sa walay kinutuban nga mga kapanguhaan sa computing. Uban sa mga quota sa kapanguhaan, ang mga tagdumala sa cluster mahimong limitahan ang pagkonsumo sa kapanguhaan ug paghimo sa kapanguhaan base sa namespace. Sa usa ka namespace, ang usa ka pod o sudlanan makakonsumo sa daghang CPU ug gahum sa memorya sama sa gipasabut sa quota sa kapanguhaan sa namespace. Bisan pa, adunay kabalaka nga ang usa ka pod o sudlanan mahimong magmonopoliya sa tanan nga magamit nga mga kapanguhaan. Aron mapugngan kini nga sitwasyon, gigamit ang limitasyon Range - ang palisiya sa paglimit sa alokasyon sa mga kahinguhaan (alang sa mga pod o mga sudlanan) sa namespace.
Ang limit range naghatag og mga limitasyon nga mahimo:
- pagsiguro sa minimum ug maximum nga paggamit sa computing resources alang sa matag module o sudlanan sa namespace;
- ipatuman ang minimum ug maximum nga Starage Request para sa matag PersistentVolumeClaim sa namespace;
- pagpugos sa usa ka relasyon tali sa usa ka Request ug usa ka Limitasyon alang sa usa ka kapanguhaan sa usa ka namespace;
- itakda ang default nga mga Request/Limit para sa pag-compute sa mga kahinguhaan sa namespace ug awtomatik nga i-inject kini ngadto sa mga sudlanan sa runtime.
Para makahimo ka ug limit range sa imong namespace. Dili sama sa quota, nga magamit sa tibuok namespace, ang Limit Range gigamit alang sa indibidwal nga mga sudlanan. Makapugong kini sa mga tiggamit sa paghimo og gagmay o higanteng mga sudlanan sulod sa namespace. Ang Limit Range mahimong ingon niini.
Sama sa miaging kaso, 4 nga mga seksyon ang mahimong mailhan dinhi. Atong tan-awon ang matag usa.
Ang default nga seksyon nagtakda sa default nga mga pagdili alang sa sudlanan sa pod. Kung imong gibutang kini nga mga kantidad sa labi ka taas nga sakup, nan ang bisan unsang mga sudlanan diin kini nga mga kantidad wala pa klaro nga gitakda mosunod sa mga default nga kantidad.
Sa defaultRequest nga seksyon, ang default nga mga hangyo gi-configure alang sa sudlanan sa pod. Pag-usab, kung imong itakda kini nga mga kantidad sa grabe nga sakup, nan ang bisan unsang mga sudlanan diin kini nga mga parameter dili klaro nga gitakda mogamit niini nga mga kantidad nga default.
Ang max nga seksyon nagtino sa labing taas nga mga limitasyon nga mahimong itakda alang sa usa ka sudlanan sa usa ka pod. Ang mga bili sa default nga seksyon ug mga limitasyon sa sudlanan dili mabutang sa ibabaw niini nga limitasyon. Mahinungdanon nga timan-an nga kung ang max gitakda ug walaβy default nga seksyon, nan ang labing taas nga kantidad mahimong default nga kantidad.
Ang min nga seksyon nagtino sa minimum nga mga hangyo nga mahimong itakda alang sa usa ka sudlanan sa usa ka pod. Bisan pa, ang mga kantidad sa default nga seksyon ug mga hangyo alang sa usa ka sudlanan dili mabutang sa ubos niini nga limitasyon.
Pag-usab, importante nga timan-an nga kung kini nga kantidad gitakda ug ang default dili, nan ang minimum nga kantidad mahimong default nga pangutana.
Sa katapusan, kini nga mga hangyo sa kapanguhaan gigamit sa Kubernetes scheduler aron ipatuman ang imong mga workloads. Aron mapahimutang nimo sa husto ang imong mga sudlanan, hinungdanon kaayo nga masabtan kung giunsa kini molihok. Ingnon ta nga gusto nimo magpadagan og daghang pod sa imong cluster. Sa pag-ingon nga balido ang mga detalye sa pod, ang iskedyul sa Kubernetes mogamit og round robin aron mapili ang node nga modagan sa workload.
Susihon sa mga Kubernetes kung ang Node 1 adunay igo nga mga kapanguhaan aron matuman ang mga hangyo sa mga sudlanan sa pod, ug kung dili, kini magpadayon sa sunod nga node. Kung walay bisan usa sa mga node sa sistema ang makahimo sa pagtagbaw sa mga hangyo, ang mga pods moadto sa Pending nga estado. Gamit ang mga feature sa Google Kubernetes engine sama sa node autoscaling, ang GKE awtomatik nga makamatikod sa pending nga kahimtang ug makamugna ug pipila pa ka dugang nga mga node.
Kung adunay sobra nga kapasidad sa mga node sa ulahi, ang autoscaling makapakunhod sa gidaghanon sa mga node aron makadaginot ka og kwarta. Mao kini ang hinungdan ngano nga ang Kubernetes nag-iskedyul sa mga Pod base sa mga hangyo. Bisan pa, ang limitasyon mahimong mas taas kaysa sa mga hangyo, ug sa pipila ka mga kaso ang host mahimo nga mahurot gyud sa mga kapanguhaan. Gitawag namo kini nga estado nga overcommitment state.
Sama sa akong giingon, kung bahin sa CPU, magsugod ang mga Kubernetes nga limitahan ang mga Pod. Ang matag pod makadawat kutob sa gipangayo niini, apan kung dili kini makaabot sa limitasyon, unya ang throttling magsugod sa paggamit.
Sa termino sa mga kahinguhaan sa panumduman, dinhi ang Kubernetes kinahanglan nga mohimo og mga desisyon mahitungod sa kung unsang mga pod ang tangtangon ug unsa ang tipigan hangtud nga imong mabakante ang mga kapanguhaan sa sistema, kung dili ang tibuok nga sistema mahugno.
Hunahunaa ang usa ka senaryo diin ikaw adunay usa ka makina nga nahutdan sa memorya - unsaon kini pagdumala sa Kubernetes?
Pangitaon sa Kubernetes ang mga Pod nga naggamit ug daghang mga kahinguhaan kaysa gihangyo. Mao nga kung ang imong mga sudlanan walaβy mga hangyo, kini nagpasabut nga pinaagi sa default mogamit sila labi pa sa ilang gipangayo, tungod lang kay wala sila nangayo bisan unsa! Ang maong mga sudlanan nahimong pangunang kandidato alang sa pagsira. Ang sunod nga mga kandidato mao ang mga sudlanan nga nakatagbaw sa tanan nilang mga hangyo apan ubos pa sa maximum nga limitasyon.
Mao nga kung makit-an sa Kubernetes ang pipila ka mga pod nga milapas sa ilang mga parameter sa hangyo, kini magsunud kanila pinaagi sa prayoridad ug dayon tangtangon ang labing ubos nga mga pod nga prayoridad. Kung ang tanan nga mga pod adunay parehas nga prayoridad, unya ang mga Kubernetes magsira sa mga pod nga milabaw sa ilang mga hangyo nga labi pa sa ubang mga pod.
Sa talagsa ra kaayo nga mga kaso, ang mga Kubernetes mahimong tapuson ang mga Pod nga naa pa sa ilang mga hangyo. Mahimo kini mahitabo kung ang mga kritikal nga sangkap sa sistema sama sa ahente sa Kubelet o Docker magsugod sa pagkonsumo sa daghang mga kapanguhaan kaysa sa gitagana alang kanila.
Mao nga, sa sayong bahin sa gagmay nga mga negosyo, ang usa ka Kubernetes cluster mahimong molihok nga maayo nga wala magtakda sa mga hangyo ug mga limitasyon sa kapanguhaan, apan samtang ang imong mga koponan ug proyekto nagsugod sa pagtubo sa gidak-on, nameligro ka nga adunay mga problema sa kini nga lugar. Ang pagdugang sa mga pangutana ug pagpugong sa imong mga module ug mga namespace nanginahanglan gamay ra kaayo nga paningkamot ug makaluwas kanimo daghang kasamok.
Pipila ka mga ad π
Salamat sa pagpabilin kanamo. Ganahan ka ba sa among mga artikulo? Gusto nga makakita og mas makapaikag nga sulod? Suportahi kami pinaagi sa pag-order o pagrekomenda sa mga higala, , usa ka talagsaon nga analogue sa mga entry-level server, nga giimbento namo alang kanimo: (anaa sa RAID1 ug RAID10, hangtod sa 24 ka mga core ug hangtod sa 40GB DDR4).
Dell R730xd 2 ka beses nga mas barato sa Equinix Tier IV data center sa Amsterdam? Dinhi lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - gikan sa $99! Basaha ang mahitungod sa
Source: www.habr.com