SÄkot darbu ar Kubernetes, parasti aizmirst par konteinera resursu iestatÄ«Å”anu. Å ajÄ brÄ«dÄ« pietiek ar to, lai nodroÅ”inÄtu Docker attÄla darbÄ«bu un to var izvietot Kubernetes klasterÄ«.
TaÄu vÄlÄk lietojumprogramma ir jÄizvieto ražoÅ”anas klasterÄ« kopÄ ar citÄm lietojumprogrammÄm. Lai to izdarÄ«tu, jums ir jÄpieŔķir resursi konteineram un jÄpÄrliecinÄs, vai to ir pietiekami daudz, lai lietojumprogramma tiktu iestatÄ«ta un darbotos, un vai citÄm darbojoÅ”Äm lietojumprogrammÄm nebÅ«s problÄmu.
Komanda iztulkojis rakstu par konteineru resursiem (CPU un MEM), pieprasÄ«jumiem un resursu ierobežojumiem. JÅ«s uzzinÄsit par Å”o iestatÄ«jumu priekÅ”rocÄ«bÄm un to, kas notiks, ja tos neiestatÄ«sit.
SkaitļoŔanas resursi
Mums ir divu veidu resursi ar Å”ÄdÄm vienÄ«bÄm:
- CentrÄlais procesors (CPU) - serdeÅi;
- AtmiÅa (MEM) - baiti.
Katram konteineram ir norÄdÄ«ti resursi. NÄkamajÄ Pod YAML failÄ jÅ«s redzÄsit resursu sadaļu, kas satur pieprasÄ«tos un ierobežotos resursus:
- Requested Pod Resources = visu konteineru pieprasīto resursu summa;
- Pod resursu limits = visu Pod resursu limitu summa.
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: 1GiPieprasÄ«to un ierobežoto resursu piemÄrs
Lauks resources.requested no specifikÄcijas Pod ir viens no elementiem, kas tiek izmantots, lai atrastu vÄlamo mezglu. JÅ«s jau varat plÄnot Pod izvietoÅ”anu tam. KÄ atrast piemÄrotu mezglu?
Kubernetes sastÄv no vairÄkiem komponentiem, tostarp galvenÄ mezgla vai galvenÄ mezgla (Kubernetes vadÄ«bas plakne). Galvenajam mezglam ir vairÄki procesi: kube-apiserver, kube-controller-manager un kube-plÄnotÄjs.
Kube plÄnotÄja process ir atbildÄ«gs par jaunizveidoto podziÅu pÄrskatÄ«Å”anu un iespÄjamo darbinieku mezglu atraÅ”anu, kas atbilst visiem apkopoÅ”anas pieprasÄ«jumiem, tostarp pieprasÄ«to resursu skaitam. Kube-plÄnotÄja atrasto mezglu saraksts ir sakÄrtots. Pods ir ieplÄnots mezglÄ ar augstÄkajiem rÄdÄ«tÄjiem.
Kur tiks novietots purpursarkanais pods?
AttÄlÄ redzams, ka kube plÄnotÄjam ir jÄieplÄno jauns purpursarkans Pod. Kubernetes klasterÄ« ir divi mezgli: A un B. KÄ redzat, kube plÄnotÄjs nevar ieplÄnot Pod mezglÄ A ā pieejamie (nepieprasÄ«tie) resursi neatbilst purpursarkanÄ Pod pieprasÄ«jumiem. TÄtad purpursarkanÄ Pod pieprasÄ«tÄ 1 GB atmiÅa neietilps mezglÄ A, jo pieejamÄ atmiÅa ir 0,5 GB. Bet mezglam B ir pietiekami daudz resursu. RezultÄtÄ kube plÄnotÄjs nolemj, ka purpursarkanÄ Pod galamÄrÄ·is ir mezgls B.
Tagad mÄs zinÄm, kÄ pieprasÄ«tie resursi ietekmÄ mezgla izvÄli, lai palaistu Pod. Bet kÄda ir robežresursu ietekme?
Resursu ierobežojums ir robeža, kuru CPU/MEM nevar pÄrkÄpt. TomÄr CPU resurss ir elastÄ«gs, tÄpÄc konteineri, kas sasniedz CPU ierobežojumus, neizraisÄ«s Pod izieÅ”anu. TÄ vietÄ tiks sÄkta CPU drosele. Ja tiek sasniegts MEM lietoÅ”anas ierobežojums, konteiners tiks apturÄts OOM-Killer dÄļ un tiks restartÄts, ja to atļauj RestartPolicy iestatÄ«jums.
DetalizÄti pieprasÄ«tie un maksimÄlie resursi
Resursu komunikÄcija starp Docker un Kubernetes
LabÄkais veids, kÄ izskaidrot, kÄ darbojas resursu pieprasÄ«jumi un resursu ierobežojumi, ir iepazÄ«stinÄt Kubernetes un Docker attiecÄ«bas. AugÅ”ÄjÄ attÄlÄ varat redzÄt, kÄ ir saistÄ«ti Kubernetes lauki un Docker startÄÅ”anas karodziÅi.
AtmiÅa: pieprasÄ«jums un ierobežojumi
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
KÄ minÄts iepriekÅ”, atmiÅa tiek mÄrÄ«ta baitos. Balstoties uz , mÄs varam norÄdÄ«t atmiÅu kÄ skaitli. Parasti tas ir vesels skaitlis, piemÄram, 2678 - tas ir, 2678 baiti. Varat arÄ« izmantot sufiksus G Šø Gi, galvenais ir atcerÄties, ka tie nav lÄ«dzvÄrtÄ«gi. Pirmais ir decimÄls, bet otrais ir binÄrs. TÄpat kÄ piemÄrs, kas minÄts k8s dokumentÄcijÄ: 128974848, 129e6, 129M, 123Mi - tie ir praktiski lÄ«dzvÄrtÄ«gi.
Kubernetes opcija limits.memory atbilst karogam --memory no Docker. GadÄ«jumÄ, ja request.memory Docker nav bultiÅas, jo Docker neizmanto Å”o lauku. JÅ«s varat jautÄt, vai tas vispÄr ir vajadzÄ«gs? JÄ vajag. KÄ jau teicu iepriekÅ”, Kubernetes laukumam ir nozÄ«me. Pamatojoties uz tajÄ iegÅ«to informÄciju, kube plÄnotÄjs izlemj, kuram mezglam plÄnot Pod.
Kas notiek, ja pieprasÄ«jumam iestatÄt nepietiekami daudz atmiÅas?
Ja konteiners ir sasniedzis pieprasÄ«tÄs atmiÅas robežas, tad Pod tiek ievietots Pod grupÄ, kas apstÄjas, ja mezglÄ nav pietiekami daudz atmiÅas.
Kas notiek, ja iestatÄt pÄrÄk zemu atmiÅas ierobežojumu?
Ja konteiners pÄrsniedz atmiÅas ierobežojumu, tas tiks pÄrtraukts OOM-Killed dÄļ. Un tiks restartÄts, ja iespÄjams, pamatojoties uz RestartPolicy, kur ir noklusÄjuma vÄrtÄ«ba Always.
Kas notiek, ja nenorÄdÄ«sit pieprasÄ«to atmiÅu?
Kubernetes izmantos robežvÄrtÄ«bu un iestatÄ«s to kÄ noklusÄjuma vÄrtÄ«bu.
Kas var notikt, ja nenorÄdÄ«sit atmiÅas ierobežojumu?
Konteineram nav ierobežojumu; tas var izmantot tik daudz atmiÅas, cik vÄlas. Ja viÅÅ” sÄks izmantot visu pieejamo mezgla atmiÅu, OOM viÅu nogalinÄs. PÄc tam konteiners tiks restartÄts, ja iespÄjams, pamatojoties uz RestartPolicy.
Kas notiks, ja nenorÄdÄ«sit atmiÅas ierobežojumus?
Å is ir sliktÄkais scenÄrijs: plÄnotÄjs nezina, cik resursu konteineram ir nepiecieÅ”ams, un tas var radÄ«t nopietnas problÄmas mezglÄ. Å ajÄ gadÄ«jumÄ bÅ«tu jauki, ja nosaukumvietai bÅ«tu noklusÄjuma ierobežojumi (ko nosaka LimitRange). Nav noklusÄjuma ierobežojumu - Pod nav ierobežojumu, tas var izmantot tik daudz atmiÅas, cik vÄlas.
Ja pieprasÄ«tÄ atmiÅa ir lielÄka, nekÄ mezgls var piedÄvÄt, Pod netiks ieplÄnots. Ir svarÄ«gi to atcerÄties Requests.memory - nav minimÄlÄ vÄrtÄ«ba. Å is ir apraksts par atmiÅas apjomu, kas ir pietiekams, lai konteiners darbotos nepÄrtraukti.
Parasti ir ieteicams iestatÄ«t tÄdu paÅ”u vÄrtÄ«bu request.memory Šø limit.memory. Tas nodroÅ”ina, ka Kubernetes neplÄnos Pod mezglÄ, kuram ir pietiekami daudz atmiÅas, lai palaistu Pod, bet nepietiek, lai to palaistu. Å
emiet vÄrÄ: Kubernetes Pod plÄnoÅ”anÄ tiek Åemta vÄrÄ tikai requests.memoryUn limits.memory neÅem vÄrÄ.
CPU: pieprasījums un ierobežojums
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Ar CPU viss ir nedaudz sarežģītÄk. Atgriežoties pie Kubernetes un Docker attiecÄ«bu attÄla, to var redzÄt request.cpu atbilst --cpu-shares, tÄ kÄ limit.cpu atbilst karogam cpus programmÄ Docker.
Kubernetes pieprasÄ«tais CPU tiek reizinÄts ar 1024 ā CPU ciklu proporciju. Ja vÄlaties pieprasÄ«t 1 pilnu kodolu, jums tas ir jÄpievieno cpu: 1kÄ parÄdÄ«ts iepriekÅ”.
Pilna kodola pieprasÄ«Å”ana (proporcija = 1024) nenozÄ«mÄ, ka konteiners to saÅems. Ja jÅ«su resursdatoram ir tikai viens kodols un jÅ«s izmantojat vairÄk nekÄ vienu konteineru, visiem konteineriem ir jÄsadala pieejamais CPU. KÄ tas notiek? ApskatÄ«sim attÄlu.
CPU pieprasÄ«jums ā viena kodola sistÄma
IedomÄsimies, ka jums ir viena kodola resursdatora sistÄma, kurÄ darbojas konteineri. Mamma (Kubernetes) izcepa pÄ«rÄgu (CPU) un vÄlas sadalÄ«t starp bÄrniem (traukiem). TrÄ«s bÄrni vÄlas veselu pÄ«rÄgu (proporcija = 1024), vÄl viens bÄrns vÄlas puspÄ«rÄgu (512). Mamma vÄlas bÅ«t godÄ«ga un veic vienkÄrÅ”u aprÄÄ·inu.
# Š”ŠŗŠ¾Š»ŃŠŗŠ¾ ŠæŠøŃŠ¾Š³Š¾Š² Ń
Š¾ŃŃŃ Š“ŠµŃŠø?
# 3 ŃŠµŠ±ŠµŠ½ŠŗŠ° Ń
Š¾ŃŃŃ ŠæŠ¾ ŃŠµŠ»Š¾Š¼Ń ŠæŠøŃŠ¾Š³Ń Šø ŠµŃŠµ Š¾Š“ŠøŠ½ Ń
Š¾ŃŠµŃ ŠæŠ¾Š»Š¾Š²ŠøŠ½Ń ŠæŠøŃŠ¾Š³Š°
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# ŠŃŃŠ°Š¶ŠµŠ½ŠøŠµ ŠæŠ¾Š»ŃŃŠ°ŠµŃŃŃ ŃŠ°Šŗ:
3 (ŃŠµŠ±ŠµŠ½ŠŗŠ°/ŠŗŠ¾Š½ŃŠµŠ¹Š½ŠµŃŠ°) * 1 (ŃŠµŠ»ŃŠ¹ ŠæŠøŃŠ¾Š³/ŠæŠ¾Š»Š½Š¾Šµ ŃŠ“ŃŠ¾) + 1 (ŃŠµŠ±ŠµŠ½Š¾Šŗ/ŠŗŠ¾Š½ŃŠµŠ¹Š½ŠµŃ) * 0.5 (ŠæŠ¾Š»Š¾Š²ŠøŠ½Š° ŠæŠøŃŠ¾Š³Š°/ŠæŠ¾Š»Š¾Š²ŠøŠ½Š° ŃŠ“ŃŠ°)
# Š”ŠŗŠ¾Š»ŃŠŗŠ¾ ŠæŠøŃŠ¾Š³Š¾Š² ŠøŃŠæŠµŃŠµŠ½Š¾?
availableCakesNumber = 1
# Š”ŠŗŠ¾Š»ŃŠŗŠ¾ ŠæŠøŃŠ¾Š³Š° (Š¼Š°ŠŗŃŠøŠ¼Š°Š»ŃŠ½Š¾) Š“ŠµŃŠø ŃŠµŠ°Š»ŃŠ½Š¾ Š¼Š¾Š³ŃŃ ŠæŠ¾Š»ŃŃŠøŃŃ?
newMaxRequest = 1 / 3.5 =~ 28%Pamatojoties uz aprÄÄ·inu, trÄ«s bÄrni saÅems 28% no kodola, nevis visu kodolu. Ceturtais bÄrns saÅems 14% no pilna kodola, nevis pusi. Bet lietas bÅ«s savÄdÄkas, ja jums ir daudzkodolu sistÄma.
CPU pieprasÄ«jums ā vairÄku kodolu (4) sistÄma
AugÅ”ÄjÄ attÄlÄ var redzÄt, ka trÄ«s bÄrni vÄlas veselu pÄ«rÄgu, bet viens vÄlas pusi. TÄ kÄ mamma izcepa Äetrus pÄ«rÄgus, katrs viÅas bÄrns dabÅ«s tik, cik gribÄs. Daudzkodolu sistÄmÄ procesora resursi tiek sadalÄ«ti pa visiem pieejamajiem procesora kodoliem. Ja konteineram ir mazÄks par vienu pilnu CPU kodolu, tas joprojÄm var to izmantot 100%.
IepriekÅ” minÄtie aprÄÄ·ini ir vienkÄrÅ”oti, lai saprastu, kÄ CPU tiek sadalÄ«ts starp konteineriem. Protams, bez paÅ”iem konteineriem ir arÄ« citi procesi, kas izmanto arÄ« CPU resursus. Kad procesi vienÄ konteinerÄ ir dÄ«kstÄvÄ, citi var izmantot tÄ resursu. CPU: "200m" atbilst CPU: 0,2, kas nozÄ«mÄ aptuveni 20% no viena kodola.
Tagad parunÄsim par limit.cpu. Kubernetes ierobežotais centrÄlais procesors tiek reizinÄts ar 100. RezultÄts ir laiks, ko konteiners var izmantot ik pÄc 100 Āµs (cpu-period).
limit.cpu atbilst Docker karogam --cpus. Å Ä« ir jauna vecÄ kombinÄcija --cpu-period Šø --cpu-quota. Iestatot to, mÄs norÄdÄm, cik pieejamos CPU resursus konteiners var maksimÄli izmantot pirms droseles sÄkÅ”anas:
- Procesors - kombinÄcija
cpu-periodŠøcpu-quota. cpus = 1.5lÄ«dzvÄrtÄ«gs iestatÄ«jumamcpu-period = 100000Šøcpu-quota = 150000; - CPU periods - periods , noklusÄjuma 100 mikrosekundes;
- cpu kvota - mikrosekunžu skaits iekÅ”pusÄ
cpu-period, kuru ierobežo konteiners.
Kas notiek, ja instalÄjat nepietiekamu pieprasÄ«to CPU?
Ja konteineram ir nepiecieÅ”ams vairÄk, nekÄ tas ir instalÄts, tas nozags CPU no citiem procesiem.
Kas notiek, ja iestatÄt pÄrÄk zemu CPU ierobežojumu?
TÄ kÄ CPU resurss ir regulÄjams, tiks ieslÄgta drosele.
Kas notiek, ja nenorÄdÄ«sit CPU pieprasÄ«jumu?
TÄpat kÄ ar atmiÅu, pieprasÄ«juma vÄrtÄ«ba ir vienÄda ar ierobežojumu.
Kas notiks, ja nenorÄdÄ«sit CPU ierobežojumu?
Konteiners izmantos tik daudz CPU, cik nepiecieÅ”ams. Ja nosaukumvietÄ ir definÄta noklusÄjuma CPU politika (LimitRange), Å”is ierobežojums tiek izmantots arÄ« konteineram.
Kas notiek, ja nenorÄdÄ«sit ne pieprasÄ«jumu, ne CPU ierobežojumu?
TÄpat kÄ ar atmiÅu, Å”is ir sliktÄkais scenÄrijs. PlÄnotÄjs nezina, cik daudz resursu ir nepiecieÅ”ams jÅ«su konteineram, un tas var radÄ«t nopietnas problÄmas mezglÄ. Lai no tÄ izvairÄ«tos, jums ir jÄiestata noklusÄjuma ierobežojumi nosaukumvietÄm (LimitRange).
Atcerieties: ja pieprasÄt vairÄk CPU, nekÄ mezgli spÄj nodroÅ”inÄt, Pod netiks ieplÄnots. Requests.cpu - nevis minimÄlÄ vÄrtÄ«ba, bet vÄrtÄ«ba, kas ir pietiekama, lai iedarbinÄtu Pod un darbotos bez kļūmÄm. Ja lietojumprogramma neveic sarežģītus aprÄÄ·inus, labÄkÄ iespÄja ir instalÄt request.cpu <= 1 un palaidiet tik daudz kopiju, cik nepiecieÅ”ams.
IdeÄls pieprasÄ«to resursu apjoms vai resursu ierobežojums
MÄs uzzinÄjÄm par skaitļoÅ”anas resursu ierobežojumiem. Tagad ir pienÄcis laiks atbildÄt uz jautÄjumu: āCik daudz resursu manam Pod ir nepiecieÅ”ams, lai lietojumprogramma palaistu bez problÄmÄm? KÄda ir ideÄlÄ summa?
DiemžÄl skaidras atbildes uz Å”iem jautÄjumiem nav. Ja nezinÄt, kÄ darbojas jÅ«su lietojumprogramma vai cik daudz CPU vai atmiÅas tai ir nepiecieÅ”ams, vislabÄkais risinÄjums ir pieŔķirt lietojumprogrammai daudz atmiÅas un CPU un pÄc tam veikt veiktspÄjas testus.
Papildus veiktspÄjas testiem nedÄļu uzraugiet lietojumprogrammas uzvedÄ«bu. Ja diagrammas norÄda, ka jÅ«su lietojumprogramma patÄrÄ mazÄk resursu, nekÄ pieprasÄ«jÄt, varat samazinÄt pieprasÄ«tÄ CPU vai atmiÅas apjomu.
KÄ piemÄru skatiet Å”o . Tas parÄda atŔķirÄ«bu starp pieprasÄ«tajiem resursiem vai resursu ierobežojumu un paÅ”reizÄjo resursu lietojumu.
SecinÄjums
Resursu pieprasÄ«Å”ana un ierobežoÅ”ana palÄ«dz uzturÄt jÅ«su Kubernetes klasteru veselÄ«gu. Pareiza limita konfigurÄcija samazina izmaksas un nodroÅ”ina lietojumprogrammu darbÄ«bu visu laiku.
ÄŖsÄk sakot, ir dažas lietas, kas jÄpatur prÄtÄ:
- PieprasÄ«tie resursi ir konfigurÄcija, kas tiek Åemta vÄrÄ startÄÅ”anas laikÄ (kad Kubernetes plÄno mitinÄt lietojumprogrammu). Turpretim resursu ierobežoÅ”ana ir svarÄ«ga izpildlaikÄ, kad lietojumprogramma jau darbojas mezglÄ.
- SalÄ«dzinot ar atmiÅu, centrÄlais procesors ir regulÄts resurss. Ja nav pietiekami daudz CPU, jÅ«su Pod neizslÄgsies un ieslÄgsies droseles mehÄnisms.
- PieprasÄ«tie resursi un resursu limits nav minimÄlÄs un maksimÄlÄs vÄrtÄ«bas! DefinÄjot pieprasÄ«tos resursus, jÅ«s nodroÅ”inÄsiet, ka lietojumprogramma darbosies bez problÄmÄm.
- Laba prakse ir iestatÄ«t atmiÅas pieprasÄ«jumu vienÄdu ar atmiÅas ierobežojumu.
- Ok instalÄÅ”ana pieprasÄ«ta
CPU <=1, ja lietojumprogramma neveic sarežģītus aprÄÄ·inus. - Ja pieprasÄt vairÄk resursu, nekÄ ir pieejams mezglÄ, Pod nekad netiks ieplÄnots Å”im mezglam.
- Lai noteiktu pareizo pieprasÄ«to resursu/resursu ierobežojumu apjomu, izmantojiet slodzes testÄÅ”anu un uzraudzÄ«bu.
Es ceru, ka Å”is raksts palÄ«dzÄs jums izprast resursu ierobežojuma pamatjÄdzienu. Un Ŕīs zinÄÅ”anas varÄsi pielietot savÄ darbÄ.
Veiksmi!
Ko vÄl lasÄ«t:
- .
- .
- .
Avots: www.habr.com