2016. gadā mēs vietnē Buffer , un tagad aptuveni 60 mezgli (uz AWS) un 1500 konteineri strādā mūsu k8s klasterī, ko pārvalda . 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, . 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 , 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.
Saskaroties ar to, mēs drīz atklājām vairākus resursus (, , ) 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: "kodola ietvaros" Linux Ir kļūda, kas izraisa nevajadzīgu konteineru ierobežošanu ar norādītajiem centrālā procesora ierobežojumiem." Ja jūs interesē problēmas būtība, varat apskatīt prezentāciju ( и 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 .
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 "", 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ā (), tur pakalpojums paātrinājās divdesmit divas reizes!
Vai kodola kļūda ir izlabota? Linux?
Jā, izplatīšanas versija 4.19 un jaunāka.
Tomēr lasot uz 2020. gada otro septembri mēs joprojām sastopamies ar atsaucēm uz dažiem Linux-projekti ar līdzīgu kļūdu. Es uzskatu, ka dažos izplatījumos Linux Šī kļūda joprojām pastāv, un pašlaik notiek darbs pie tās labošanas.
Ja jūsu izplatītā versija ir vecāka par 4.19, es ieteiktu jaunināt uz jaunāko versiju, taču jums joprojām vajadzētu mēģināt noņemt centrālā procesora ierobežojumus un pārbaudīt, vai ierobežošana joprojām pastāv. Zemāk ir daļējs Kubernetes pārvaldības pakalpojumu saraksts. Linux sadalījumi:
- Debian: labojums ir integrēts jaunākajā izplatīšanas versijā, un izskatās diezgan svaigs (). Dažas iepriekšējās versijas var arī tikt labotas.
- Ubuntu: labojums integrēts jaunākajā versijā
- EKS vēl ir labots . Ja jūsu versija ir zemāka par šo, jums vajadzētu atjaunināt AMI.
- kops: у
kops 1.18+galvenais resursdatora attēls būs Ubuntu 20.04. aprīlis. Ja jūsu Kops versija ir vecāka, jums, iespējams, būs jāgaida labojums. Mēs paši pašlaik gaidām labojumu. - GKE (Google Cloud): integrēts labojums , tomēr ir problēmas ar droseļvārstu .
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, izmantojot Linux (neatkarīgi no tā, vai tas ir Kubernetes, Mesos, Swarm vai jebkas cits), 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 autore sarakstējas ar lasītājiem un komentētājiem (angļu valodā).
Avots: www.habr.com
