CPU mugak eta throttling oldarkorra Kubernetes-en

Ohar. itzul.: Omioren —Europako bidai-agregatzailea den— historia ikusgarri honek irakurleak oinarrizko teoriatik Kubernetes konfigurazioaren konplexutasun praktiko liluragarrietara eramaten ditu. Horrelako kasuak ezagutzeak zure horizontea zabaltzen ez ezik, arazo ez-hutsak saihesten ere laguntzen du.

Inoiz izan al duzu aplikazio bat itsatsita geratu, osasun-kontrolei erantzutea utzi eta ezin izan al zaizu zergatik asmatu? Azalpen posible bat CPU baliabideen kuoten mugekin lotuta dago. Horri buruz hitz egingo dugu artikulu honetan.

TL; DR:
Kubernetesen CPU mugak desgaitzea gomendatzen dugu (edo Kubelet-en CFS kuotak desgaitzea) Linux kernelaren bertsio bat erabiltzen ari bazara CFS kuota akats batekin. Muinean eskuragarri dago larri eta ezagun gehiegizko throttling eta atzerapenak eragiten dituen akatsa.

Omioan azpiegitura osoa Kubernetesek kudeatzen du. Gure egoera eta estaturik gabeko lan-karga guztiak Kubernetes-en soilik exekutatzen dira (Google Kubernetes Engine erabiltzen dugu). Azken sei hilabeteetan, ausazko moteltzeak ikusten hasi ginen. Aplikazioak izoztu egiten dira edo osasun-kontrolei erantzutea uzten dute, sarerako konexioa galtzen dute, etab. Jokabide honek denbora luzez harritu gintuen, eta azkenean arazoa serio hartzea erabaki genuen.

Artikuluaren laburpena:

• Edukiontziei eta Kubernetesei buruzko hitz batzuk;
• CPU eskaerak eta mugak nola ezartzen diren;
• CPU mugak nola funtzionatzen duen nukleo anitzeko inguruneetan;
• Nola jarraitu CPU throttling;
• Arazoaren konponbidea eta ñabardurak.

Edukiontziei eta Kubernetesei buruzko hitz batzuk

Kubernetes funtsean azpiegituren munduko estandar modernoa da. Bere zeregin nagusia edukiontzien orkestrazioa da.

edukiontzi

Iraganean, Java JARs/WARs, Python Eggs edo exekutagarriak bezalako artifaktuak sortu behar izan genituen zerbitzarietan exekutatzeko. Hala ere, funtzionatzeko, lan osagarriak egin behar izan dira: exekuzio-ingurunea instalatu (Java/Python), beharrezko fitxategiak leku egokietan jartzea, sistema eragilearen bertsio zehatz batekin bateragarritasuna bermatzea, etab. Beste era batera esanda, arreta handiz jarri behar zen konfigurazioen kudeaketari (sarritan garatzaileen eta sistema-administratzaileen arteko eztabaida-iturri zen).

Edukiontziek dena aldatu zuten. Orain artefaktua edukiontziaren irudia da. Programa ez ezik, exekuzio-ingurune oso bat (Java/Python/...) eta beharrezko fitxategi/paketeak, aurrez instalatuta eta prest dauden fitxategi exekutagarri hedatu gisa irudika daiteke. Korrika egin. Edukiontziak zerbitzari desberdinetan hedatu eta exekutatu daitezke urrats gehigarririk gabe.

Horrez gain, edukiontziak beren sandbox ingurunean funtzionatzen dute. Sare birtualaren egokitzaile propioa dute, sarbide mugatuko fitxategi sistema propioa, prozesuen hierarkia propioa, CPU eta memorian dituzten mugak, etab. Hori guztia Linux kernelaren azpisistema berezi bati esker inplementatzen da: izen-espazioak.

Kubernetes

Lehen esan bezala, Kubernetes edukiontzi-orkestratzailea da. Honela funtzionatzen du: makina multzo bat ematen diozu, eta, ondoren, esan: "Aizu, Kubernetes, abiarazi ditzagun nire edukiontziaren hamar instantzia 2 prozesadore eta 3 GB memoriarekin, eta jarraitu ditzagun martxan!" Kubernetes arduratuko da gainerakoaz. Doako edukiera aurkituko du, edukiontziak abiarazi eta behar izanez gero berrabiaraziko ditu, bertsioak aldatzean eguneraketa bat zabalduko du, etab. Funtsean, Kubernetes-ek hardware osagaia abstraitzea ahalbidetzen du eta hainbat sistema egokiak egiten ditu aplikazioak hedatzeko eta exekutatzeko.

Kubernetes profanoaren ikuspuntutik

Zer diren eskaerak eta mugak Kubernetesen

Ados, edukiontziak eta Kubernetes estali ditugu. Badakigu ere ontzi anitz egon daitezkeela makina berean.

Analogia bat egin daiteke apartamentu komun batekin. Lokal zabal bat (makinak/unitateak) hartu eta alokatzen zaie hainbat maizterri (edukiontziak). Kubernetes-ek higiezinen agente gisa jarduten du. Galdera sortzen da, nola mantendu maizterrak elkarren arteko gatazketatik? Zer gertatzen da haietako batek, esate baterako, bainugela egun erdirako maileguan hartzea erabakitzen badu?

Hor sartzen dira eskaerak eta mugak. CPU Eskaera plangintza helburuetarako soilik behar da. Hau edukiontziaren "desioen zerrenda" bezalako zerbait da, eta nodo egokiena hautatzeko erabiltzen da. Aldi berean CPUa Mugatu alokairu-kontratu batekin alderatu daiteke - edukiontzirako unitate bat hautatu bezain laster ezin ezarritako mugak gainditu. Eta hemen sortzen da arazoa...

Eskaerak eta mugak nola ezartzen diren Kubernetesen

Kubernetes-ek nukleoan integratutako throttling mekanismo bat erabiltzen du (erloju-zikloak saltatzea) CPU mugak ezartzeko. Aplikazio batek muga gainditzen badu, throttling gaituta dago (hau da, PUZaren ziklo gutxiago jasotzen ditu). Memoriaren eskaerak eta mugak modu ezberdinean antolatzen dira, beraz, errazago detektatzen dira. Horretarako, egiaztatu pod-aren azken berrabiarazi egoera: "OOMKilled" den. CPU throttling ez da hain erraza, K8s-ek neurketak erabileraren arabera soilik jartzen baititu eskuragarri, ez cgroups-ek.

CPU eskaera

CPU eskaera nola inplementatzen den

Sinpletasuna lortzeko, ikus dezagun prozesua adibide gisa 4 nukleoko CPU bat duen makina bat erabiliz.

K8sek kontrol-taldeen mekanismoa (cgroups) erabiltzen du baliabideen (memoria eta prozesadorea) esleipena kontrolatzeko. Eredu hierarkiko bat dago eskuragarri: haurrak guraso taldearen mugak heredatzen ditu. Banaketa xehetasunak fitxategi sistema birtual batean gordetzen dira (/sys/fs/cgroup). Prozesadore baten kasuan hau da /sys/fs/cgroup/cpu,cpuacct/*.

K8s fitxategia erabiltzen du cpu.share prozesadorearen baliabideak esleitzeko. Gure kasuan, root cgroup-ek CPU baliabideen 4096 parte hartzen ditu - erabilgarri dagoen prozesadorearen potentziaren % 100 (nukleo 1 = 1024; hau balio finkoa da). Erro-taldeak baliabideak proportzionalki banatzen ditu erroldatutako ondorengoen kuoten arabera cpu.share, eta haiek, berriz, berdin egiten dute ondorengoekin, etab. Kubernetes nodo tipiko batean, root cgroup-ak hiru seme-alaba ditu: system.slice, user.slice и kubepods. Lehenengo bi azpitaldeak baliabideak banatzeko erabiltzen dira sistemaren karga kritikoen eta K8-tik kanpoko erabiltzaile-programen artean. Azkena - kubepods — Kubernetes-ek sortua baliabideak poden artean banatzeko.

Goiko diagramak erakusten du lehenengo eta bigarren azpitaldeek jaso zutela bakoitza 1024 akzioak, kuberpod azpitaldea esleituta 4096 akzioak Nola da posible hau: azken finean, root taldeak bakarrik du sarbidea 4096 akzioak, eta bere ondorengoen akzioen baturak kopuru hori nabarmen gainditzen du (6144)? Kontua da balioak zentzu logikoa duela, beraz, Linux-en programatzaileak (CFS) erabiltzen du CPU baliabideak proportzionalki esleitzeko. Gure kasuan, lehenengo bi taldeek jasotzen dute 680 akzio errealak (16,6ren %4096), eta kubepod-ek jasotzen du gainerakoa 2736 akzioak Geldialdien kasuan, lehenengo bi taldeek ez dituzte esleitutako baliabideak erabiliko.

Zorionez, programatzaileak mekanismo bat dauka erabiltzen ez diren CPU baliabideak alferrik gal ez dadin. Ahalmen "inaiktiboa" igerileku global batera transferitzen du, eta handik prozesadorearen potentzia gehigarria behar duten taldeetara banatzen da (transferentzia loteka gertatzen da biribilketa galerak ekiditeko). Antzeko metodoa ondorengoen ondorengo guztiei aplikatzen zaie.

Mekanismo honek prozesadorearen potentziaren banaketa zuzena bermatzen du eta prozesu batek besteei baliabiderik "lapurtzen" ez diela ziurtatzen du.

CPU muga

K8-en mugen eta eskaeren konfigurazioak antzekoak izan arren, haien inplementazioa zeharo ezberdina da: hau engainagarriena eta gutxien dokumentatutako zatia.

K8s engaiatzen da CFS kuota mekanismoa mugak ezartzeko. Haien ezarpenak fitxategietan zehazten dira cfs_period_us и cfs_quota_us cgroup direktorioan (fitxategia ere bertan dago cpu.share).

Ez bezala cpu.share, kuota oinarritzen da denbora-tartea, eta ez eskuragarri dagoen prozesadorearen potentzian. cfs_period_us aldiaren (garaia) iraupena zehazten du - beti 100000 μs (100 ms) da. K8s-en balio hori aldatzeko aukera dago, baina oraingoz alfa-n bakarrik dago eskuragarri. Antolatzaileak garaia erabiltzen du erabilitako kuotak berrabiarazteko. Bigarren fitxategia cfs_quota_us, garai bakoitzean erabilgarri dagoen denbora (kuota) zehazten du. Kontuan izan mikrosegundotan ere zehazten dela. Kuotak aroaren iraupena gainditu dezake; hau da, 100 ms baino handiagoa izan daiteke.

Ikus ditzagun 16 nukleoko makinen bi eszenatoki (Omio-n daukagun ordenagailu mota ohikoena):

1. eszenatokia: 2 hari eta 200 ms-ko muga. Uzkurdurarik ez

2. eszenatokia: 10 hari eta 200 ms-ko muga. Mugimendua 20 ms-ren buruan hasten da, prozesadorearen baliabideetarako sarbidea beste 80 ms-ren ondoren berrekingo da

Demagun CPU muga ezarri duzula 2 nukleoak; Kubernetes-ek balio hori 200 ms-ra itzuliko du. Horrek esan nahi du edukiontziak gehienez 200 ms-ko CPU denbora erabil dezakeela mugatu gabe.

Eta hemen hasten da dibertsioa. Goian esan bezala, erabilgarri dagoen kuota 200 ms-koa da. Paraleloan lanean ari bazara hamar hariak 12 nukleoko makina batean (ikus 2. agertokirako ilustrazioa), gainerako pod guztiak inaktibo dauden bitartean, kuota 20 ms-tan agortuko da (10 * 20 ms = 200 ms geroztik), eta pod honen hari guztiak zintzilik egongo dira. » (gasilua) hurrengo 80 msetarako. Lehen aipatutakoa antolatzailearen akatsa, hori dela eta, gehiegizko throttling gertatzen da eta edukiontziak ezin du dagoen kuota ere bete.

Nola ebaluatu throttling lekak?

Hasi saioa pod-ean eta exekutatu cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods — programatzaile-aldien guztizko kopurua;
• nr_throttled — konposizioko strottled aldi kopurua nr_periods;
• throttled_time — throttled denbora metatua nanosegundotan.

Zer ari da gertatzen benetan?

Ondorioz, throttling handia lortzen dugu aplikazio guztietan. Batzuetan sartzen da aldiz bat eta erdi kalkulatua baino indartsuagoa!

Horrek hainbat errore ekartzen ditu: prest dauden egiaztapenaren hutsegiteak, edukiontziak izozteak, sareko konexio-hausteak, zerbitzu-deien denbora-muga. Horrek, azken finean, latentzia handiagoa eta errore-tasa handiagoak eragiten ditu.

Erabakia eta ondorioak

Hemen dena sinplea da. CPU mugak alde batera utzi eta OS nukleoa klusterren azken bertsiora eguneratzen hasi ginen, akatsa konpondu baitzen. Gure zerbitzuetako errore kopurua (HTTP 5xx) berehala jaitsi zen nabarmen:

HTTP 5xx erroreak

HTTP 5xx erroreak zerbitzu kritiko baterako

Erantzun denbora p95

Zerbitzu kritikoaren eskaeraren latentzia, 95. pertzentilea

Funtzionamendu-kostuak

Instantzia-ordu kopurua

Zer da harrapaketa?

Artikuluaren hasieran esan bezala:

Apartamentu komunal batekin analogia bat egin daiteke... Kubernetes-ek higiezinen agente gisa jarduten du. Baina nola mantendu maizterrak elkarren arteko gatazketatik? Zer gertatzen da haietako batek, esate baterako, bainugela egun erdirako maileguan hartzea erabakitzen badu?

Hona hemen harrapaketa. Axolagabeko edukiontzi batek makina batean dauden CPU baliabide guztiak jan ditzake. Aplikazio-pila adimendun bat baduzu (adibidez, JVM, Go, Node VM behar bezala konfiguratuta daude), orduan hau ez da arazoa: horrelako baldintzetan lan egin dezakezu denbora luzez. Baina aplikazioak gaizki optimizatuta edo batere optimizatuta ez badaude (FROM java:latest), egoera kontroletik kanpo atera daiteke. Omio-n oinarrizko Dockerfile automatizatuak ditugu hizkuntza pila nagusirako ezarpen lehenetsi egokiekin, beraz, arazo hau ez zen existitzen.

Neurrien jarraipena egitea gomendatzen dugu ERABILI (erabilera, saturazioa eta akatsak), API atzerapenak eta errore tasak. Ziurtatu emaitzek itxaropenak betetzen dituztela.

Erreferentziak

Hau da gure istorioa. Material hauek asko lagundu zuten gertatzen ari zena ulertzen:

• kernel.org → CFS Scheduler;
• kernel.org → CFS Bandwidth Control;
• Linux edukiontzien programazioa ulertzea;
• Linux edukiontziei buruz jakin behar duzun guztia, I. zatia: Linux kontrol-taldeak eta prozesuen isolamendua;
• Kubernetes hutsegite istorioak - bilatu "cpu throttling".

Kubernetes akatsen txostenak:

• #51135: Saihestu PUZaren mugak ezartzea Bermatutako leketarako;
• #67577: CFS-ko kuotek alferrikako murrizketa ekar dezakete;
• CFS oldarkorregia.

Antzeko arazoak aurkitu dituzu zure praktikan edo edukiontzidun produkzio-inguruneetan murrizketarekin lotutako esperientziarik? Partekatu zure istorioa iruzkinetan!

PS itzultzailetik

Irakurri ere gure blogean:

• «Autoeskala eta baliabideen kudeaketa Kubernetes-en (berrikuspena eta bideo-txostena)»;
• «CPU Kudeatzaileak nola funtzionatzen duen Kubernetes-en»;
• «Zer gertatzen da Kubernetesen kubectl run exekutatzen duzunean? 2. zatia'.

Iturria: www.habr.com