Kubernetes: paÄtriniet savus pakalpojumus, noÅemot CPU ierobežojumus
2016. gadÄ mÄs vietnÄ Buffer pÄrgÄja uz Kubernetes, un tagad aptuveni 60 mezgli (uz AWS) un 1500 konteineri strÄdÄ mÅ«su k8s klasterÄ«, ko pÄrvalda sitiens. TomÄr mÄs pÄrgÄjÄm uz mikropakalpojumiem, izmantojot izmÄÄ£inÄjumu un kļūdu metodi, un pat pÄc vairÄku gadu darba ar k8s joprojÄm saskaramies ar jaunÄm problÄmÄm. Å ajÄ amatÄ mÄs runÄsim par procesora ierobežojumi: kÄpÄc mÄs domÄjÄm, ka tie ir laba prakse un kÄpÄc tie nebija tik labi.
Procesora ierobežojumi un droseles
TÄpat kÄ daudzi citi Kubernetes lietotÄji, Google ļoti iesaka iestatÄ«t CPU ierobežojumus. Bez Å”Äda iestatÄ«juma konteineri mezglÄ var aizÅemt visu procesora jaudu, kas savukÄrt izraisa svarÄ«gus Kubernetes procesus (piemÄram, kubelet) pÄrtrauks atbildÄt uz pieprasÄ«jumiem. TÄdÄjÄdi CPU ierobežojumu iestatÄ«Å”ana ir labs veids, kÄ aizsargÄt savus mezglus.
Procesora ierobežojumi nosaka konteineram maksimÄlo CPU laiku, ko tas var izmantot noteiktÄ laika posmÄ (noklusÄjums ir 100 ms), un konteiners nekad nepÄrsniegs Å”o ierobežojumu. In Kubernetes par droseles konteineru un neļaut tam pÄrsniegt limitu, tiek izmantots Ä«paÅ”s instruments CFS kvota, taÄu Å”ie mÄkslÄ«gie CPU ierobežojumi galu galÄ pasliktina veiktspÄju un palielina jÅ«su konteineru reakcijas laiku.
Kas var notikt, ja mÄs nenosakÄm procesora ierobežojumus?
DiemžÄl mums paÅ”iem nÄcÄs saskarties ar Å”o problÄmu. Katram mezglam ir process, kas atbild par konteineru pÄrvaldÄ«bu kubelet, un viÅÅ” pÄrtrauca atbildÄt uz pieprasÄ«jumiem. Kad tas notiks, mezgls nonÄks stÄvoklÄ« NotReady, un konteineri no tÄ tiks novirzÄ«ti kaut kur citur un radÄ«s tÄdas paÅ”as problÄmas jaunos mezglos. Nav ideÄls scenÄrijs, lai neteiktu vairÄk.
Droseles un reakcijas problÄmas izpausme
Galvenais konteineru izsekoÅ”anas rÄdÄ«tÄjs ir trottling, tas parÄda, cik reižu jÅ«su konteiners ir bloÄ·Äts. MÄs ar interesi novÄrojÄm droseles esamÄ«bu dažos konteineros neatkarÄ«gi no tÄ, vai procesora slodze bija ekstrÄma vai nÄ. PiemÄram, apskatÄ«sim vienu no mÅ«su galvenajÄm API:
KÄ redzat zemÄk, mÄs esam noteikuÅ”i ierobežojumu lÄ«dz 800m (0.8 vai 80% kodols) un maksimÄlÄs vÄrtÄ«bas labÄkajÄ sasniedzamÄ«bas gadÄ«jumÄ 200m (20% kodols). Å Ä·iet, ka pirms pakalpojuma ierobežoÅ”anas mums joprojÄm ir pietiekami daudz procesora jaudas, tomÄr...
JÅ«s, iespÄjams, pamanÄ«jÄt, ka pat tad, ja procesora slodze ir zemÄka par norÄdÄ«tajÄm robežÄm - ievÄrojami zemÄka - droseles joprojÄm notiek.
KÄpÄc mÄs redzam droseles pie zemas CPU slodzes? ÄŖsÄ versija ir Å”Äda: "Linux kodolÄ ir kļūda, kas izraisa nevajadzÄ«gu konteineru pÄrtraukÅ”anu ar noteiktiem procesora ierobežojumiem." Ja jÅ«s interesÄ problÄmas bÅ«tÄ«ba, varat izlasÄ«t prezentÄciju (Video Šø tekstu opcijas) autors Deivs Äiluks.
CPU ierobežojumu noÅemÅ”ana (ar Ä«paÅ”u piesardzÄ«bu)
PÄc ilgÄm diskusijÄm mÄs nolÄmÄm noÅemt procesora ierobežojumus visiem pakalpojumiem, kas tieÅ”i vai netieÅ”i ietekmÄja mÅ«su lietotÄju kritisko funkcionalitÄti.
LÄmums nebija viegls, jo mÄs augstu vÄrtÄjam mÅ«su klastera stabilitÄti. AgrÄk mÄs jau esam eksperimentÄjuÅ”i ar mÅ«su klastera nestabilitÄti, un tad pakalpojumi patÄrÄja pÄrÄk daudz resursu un palÄninÄja visa sava mezgla darbu. Tagad viss bija nedaudz savÄdÄk: mums bija skaidra izpratne par to, ko mÄs sagaidÄm no mÅ«su klasteriem, kÄ arÄ« laba stratÄÄ£ija plÄnoto izmaiÅu ievieÅ”anai.
LietiÅ”Ä·Ä sarakste par aktuÄlu jautÄjumu.
KÄ aizsargÄt savus mezglus, kad ierobežojumi tiek atcelti?
āNeierobežotuā pakalpojumu izolÄcija:
AgrÄk mÄs jau esam redzÄjuÅ”i, ka daži mezgli nonÄk stÄvoklÄ« notReady, galvenokÄrt pakalpojumu dÄļ, kas patÄrÄja pÄrÄk daudz resursu.
MÄs nolÄmÄm Å”Ädus pakalpojumus izvietot atseviŔķos (āmarÄ·Ätosā) mezglos, lai tie netraucÄtu āsaistÄ«tajiemā pakalpojumiem. RezultÄtÄ, atzÄ«mÄjot dažus mezglus un pievienojot pielaides parametru ānesaistÄ«tajiemā pakalpojumiem, mÄs panÄcÄm lielÄku kontroli pÄr klasteru, un mums kļuva vieglÄk identificÄt problÄmas ar mezgliem. Lai pats veiktu lÄ«dzÄ«gus procesus, varat iepazÄ«ties ar dokumentÄcija.
Pareiza procesora un atmiÅas pieprasÄ«juma pieŔķirÅ”ana:
MÅ«su lielÄkÄs bailes bija, ka process patÄrÄs pÄrÄk daudz resursu un mezgls pÄrtrauks atbildÄt uz pieprasÄ«jumiem. TÄ kÄ tagad (pateicoties Datadog) mÄs varÄjÄm skaidri uzraudzÄ«t visus mÅ«su klastera pakalpojumus, es analizÄju vairÄku mÄneÅ”u darbÄ«bu tiem, kurus plÄnojÄm apzÄ«mÄt kÄ ānesaistÄ«tusā. Es vienkÄrÅ”i iestatÄ«ju maksimÄlo CPU lietojumu ar 20% rezervi un tÄdÄjÄdi atvÄlÄju vietu mezglÄ, ja k8s mÄÄ£inÄtu mezglam pieŔķirt citus pakalpojumus.
KÄ redzams grafikÄ, ir sasniegta maksimÄlÄ procesora slodze 242m CPU kodoli (0.242 procesora kodoli). Procesora pieprasÄ«jumam pietiek ar skaitli, kas ir nedaudz lielÄks par Å”o vÄrtÄ«bu. LÅ«dzu, Åemiet vÄrÄ: tÄ kÄ pakalpojumi ir orientÄti uz lietotÄju, maksimÄlÄs slodzes vÄrtÄ«bas sakrÄ«t ar trafiku.
Dariet to paÅ”u ar atmiÅas lietojumu un vaicÄjumiem, un voila ā viss ir gatavs! Lai nodroÅ”inÄtu lielÄku droŔību, varat pievienot horizontÄlu automÄtisko mÄrogoÅ”anu. TÄdÄjÄdi katru reizi, kad resursu slodze ir liela, automÄtiskÄ mÄrogoÅ”ana radÄ«s jaunus podi, un kubernetes sadalÄ«s tos mezglos ar brÄ«vu vietu. Ja paÅ”Ä klasterÄ« nav atlicis brÄ«vas vietas, varat iestatÄ«t sev brÄ«dinÄjumu vai konfigurÄt jaunu mezglu pievienoÅ”anu, izmantojot to automÄtisko mÄrogoÅ”anu.
No mÄ«nusiem ir vÄrts atzÄ«mÄt, ka mÄs zaudÄjÄm "konteinera blÄ«vums", t.i. konteineru skaits, kas darbojas vienÄ mezglÄ. Mums var bÅ«t arÄ« daudz ārelaksÄcijasā pie zema satiksmes blÄ«vuma, un pastÄv arÄ« iespÄja, ka jÅ«s sasniegsit lielu procesora slodzi, taÄu automÄtiskÄs mÄrogoÅ”anas mezgliem vajadzÄtu palÄ«dzÄt ar pÄdÄjo.
rezultÄtus
Es priecÄjos publicÄt Å”os lieliskos pÄdÄjo nedÄļu eksperimentu rezultÄtus; mÄs jau esam redzÄjuÅ”i bÅ«tiskus uzlabojumus visos pÄrveidotajos pakalpojumos:
MÄs sasniedzÄm labÄkos rezultÄtus mÅ«su mÄjas lapÄ (buffer.com), tur pakalpojums paÄtrinÄjÄs divdesmit divas reizes!
TomÄr lasot kubernetes problÄmas vietnÄ githubuz 2020. gada otro septembri mÄs joprojÄm sastopamies ar pieminÄtiem dažiem Linux projektiem ar lÄ«dzÄ«gu kļūdu. Es uzskatu, ka dažiem Linux izplatÄ«jumiem joprojÄm ir Ŕī kļūda, un tie tikai strÄdÄ pie tÄs novÄrÅ”anas.
Ja jÅ«su izplatÄ«Å”anas versija ir zemÄka par 4.19, es ieteiktu jauninÄt uz jaunÄko, taÄu jebkurÄ gadÄ«jumÄ jums vajadzÄtu mÄÄ£inÄt noÅemt procesora ierobežojumus un pÄrbaudÄ«t, vai droseles darbÄ«ba joprojÄm pastÄv. TÄlÄk ir redzams daļÄjs Kubernetes pÄrvaldÄ«bas pakalpojumu un Linux izplatÄ«jumu saraksts:
Debian: labojums integrÄts jaunÄkajÄ izplatÄ«Å”anas versijÄ, busterun izskatÄs diezgan svaigs (2020. gada augusts). Dažas iepriekÅ”ÄjÄs versijas var arÄ« tikt labotas.
EKS vÄl ir labots 2019. gada decembrÄ«. Ja jÅ«su versija ir zemÄka par Å”o, jums vajadzÄtu atjauninÄt AMI.
kops: No 2020. gada jÅ«nija Ń kops 1.18+ Galvenais saimniekdatora attÄls bÅ«s Ubuntu 20.04. Ja jÅ«su kops versija ir vecÄka, iespÄjams, bÅ«s jÄgaida labojums. MÄs paÅ”i tagad gaidÄm.
Ko darÄ«t, ja labojums novÄrsa droseles problÄmu?
Es neesmu pÄrliecinÄts, ka problÄma ir pilnÄ«bÄ atrisinÄta. Kad tiksim pie kodola versijas ar labojumu, es pÄrbaudÄ«Å”u kopu un atjauninÄÅ”u ziÅu. Ja kÄds jau ir atjauninÄjis, es labprÄt izlasÄ«tu jÅ«su rezultÄtus.
SecinÄjums
Ja strÄdÄjat ar Docker konteineriem operÄtÄjsistÄmÄ Linux (neatkarÄ«gi no Kubernetes, Mesos, Swarm vai citiem), jÅ«su konteineri var zaudÄt veiktspÄju droseles dÄļ;
MÄÄ£iniet atjauninÄt uz jaunÄko izplatÄ«Å”anas versiju, cerot, ka kļūda jau ir novÄrsta;
Procesora ierobežojumu noÅemÅ”ana atrisinÄs problÄmu, taÄu tas ir bÄ«stams paÅÄmiens, kas jÄizmanto ļoti piesardzÄ«gi (labÄk vispirms atjauninÄt kodolu un salÄ«dzinÄt rezultÄtus);
Ja esat noÅÄmis CPU ierobežojumus, rÅ«pÄ«gi pÄrraugiet savu CPU un atmiÅas lietojumu un pÄrliecinieties, vai jÅ«su CPU resursi pÄrsniedz jÅ«su patÄriÅu;
DroÅ”a iespÄja bÅ«tu automÄtiskÄ mÄrogoÅ”ana podiem, lai izveidotu jaunus aplikumus lielas aparatÅ«ras slodzes gadÄ«jumÄ, lai kubernetes pieŔķirtu tos brÄ«vajiem mezgliem.
Es ceru, ka Ŕī ziÅa palÄ«dzÄs jums uzlabot konteineru sistÄmu veiktspÄju.
PS Å eit autore sarakstÄjas ar lasÄ«tÄjiem un komentÄtÄjiem (angļu valodÄ).