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:

Kubernetes: paātriniet savus pakalpojumus, noņemot CPU ierobežojumus

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...

Kubernetes: paātriniet savus pakalpojumus, noņemot CPU ierobežojumus
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.

Saskaroties ar to, mēs drÄ«z atklājām vairākus resursus (problēma github, prezentācija par zadano, ziņu vietnē omio) par pakalpojumu veiktspējas un reakcijas laika samazināŔanos droseles dēļ.

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.

Kubernetes: paātriniet savus pakalpojumus, noņemot CPU ierobežojumus
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.

Kubernetes: paātriniet savus pakalpojumus, noņemot CPU ierobežojumus

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.

Kubernetes: paātriniet savus pakalpojumus, noņemot CPU ierobežojumus

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:

Kubernetes: paātriniet savus pakalpojumus, noņemot CPU ierobežojumus

Mēs sasniedzām labākos rezultātus mūsu mājas lapā (buffer.com), tur pakalpojums paātrinājās divdesmit divas reizes!

Kubernetes: paātriniet savus pakalpojumus, noņemot CPU ierobežojumus

Vai Linux kodola kļūda ir novērsta?

Jā, Kļūda jau ir novērsta, un labojums ir pievienots kodolam izplatÄ«Å”anas versija 4.19 un jaunāka.

Tomēr lasot kubernetes problēmas vietnē github uz 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.
  • Ubuntu: labojums ir integrēts jaunākajā versijā Ubuntu Focal Fossa 20.04
  • 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.
  • GKE (Google Cloud): integrēts labojums 2020. gada janvārÄ«, tomēr ir problēmas ar droseļvārstu joprojām tiek novēroti.

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ā).


Avots: www.habr.com

Pievieno komentāru