🥇Mga limitasyon sa CPU ug agresibo nga throttling sa Kubernetes

Nota. transl.: Kining makapabuka sa mata nga kasaysayan sa Omio—usa ka European travel aggregator—nagkuha sa mga magbabasa gikan sa batakang teorya ngadto sa makaiikag nga praktikal nga mga kakuti sa Kubernetes configuration. Ang pagkapamilyar sa ingon nga mga kaso makatabang dili lamang sa pagpalapad sa imong mga panglantaw, apan usab sa pagpugong sa dili importante nga mga problema.

Nakasinati ka na ba usa ka aplikasyon nga na-stuck sa lugar, hunong sa pagtubag sa mga pagsusi sa kahimsog, ug wala mahibal-an kung ngano? Ang usa ka posible nga katin-awan adunay kalabotan sa mga limitasyon sa quota sa kapanguhaan sa CPU. Kini ang atong hisgotan niining artikuloha.

TL; DR:
Kami kusganong nagrekomendar sa pag-disable sa mga limitasyon sa CPU sa Kubernetes (o pag-disable sa CFS quota sa Kubelet) kung ikaw naggamit ug bersyon sa Linux kernel nga adunay CFS quota bug. Sa kinauyokan magamit seryoso ug ilado kaayo usa ka bug nga mosangpot sa sobra nga throttling ug mga paglangan.

Sa Omio ang tibuok imprastraktura gidumala sa Kubernetes. Ang tanan namong stateful ug stateless nga workloads ekslusibo nga nagdagan sa Kubernetes (among gigamit ang Google Kubernetes Engine). Sa miaging unom ka bulan, nagsugod kami sa pag-obserbar sa random nga paghinay. Ang mga aplikasyon nag-freeze o mihunong sa pagtubag sa mga pagsusi sa kahimsog, nawala ang koneksyon sa network, ug uban pa. Kini nga kinaiya nakapalibog kanamo sa dugay nga panahon, ug sa katapusan nakahukom kami nga seryosohon ang problema.

Sumaryo sa artikulo:

Pipila ka mga pulong mahitungod sa mga sudlanan ug Kubernetes;
Giunsa gipatuman ang mga hangyo ug limitasyon sa CPU;
Giunsa paglihok ang limitasyon sa CPU sa mga multi-core nga palibot;
Sa unsa nga paagi sa pagsubay sa CPU throttling;
Solusyon sa problema ug mga nuances.

Pipila ka mga pulong bahin sa mga sudlanan ug Kubernetes

Ang Kubernetes sa esensya mao ang modernong sumbanan sa kalibutan sa imprastraktura. Ang panguna nga tahas niini mao ang orkestra sa sudlanan.

Mga sudlanan

Kaniadto, kinahanglan namon nga maghimo mga artifact sama sa Java JARs/WARs, Python Eggs, o mga executable aron modagan sa mga server. Bisan pa, aron mahimo kini nga molihok, kinahanglan nga buhaton ang dugang nga trabaho: pag-install sa runtime nga palibot (Java/Python), pagbutang sa kinahanglan nga mga file sa husto nga mga lugar, pagsiguro sa pagkaangay sa usa ka piho nga bersyon sa operating system, ug uban pa. Sa laing pagkasulti, ang mabinantayon nga pagtagad kinahanglan ibayad sa pagdumala sa pag-configure (nga kasagaran usa ka tinubdan sa panagbingkil tali sa mga developers ug system administrator).

Gibag-o sa mga sudlanan ang tanan. Karon ang artifact usa ka sulud nga imahe. Mahimo kini nga irepresentar isip usa ka matang sa gipalapad nga executable file nga adunay sulod dili lamang sa programa, kondili usa usab ka hingpit nga execution environment (Java/Python/...), ingon man ang gikinahanglan nga mga file/packages, pre-installed ug andam sa dagan. Ang mga sudlanan mahimong ma-deploy ug modagan sa lainlaing mga server nga wala’y dugang nga mga lakang.

Dugang pa, ang mga sudlanan naglihok sa ilang kaugalingon nga palibot sa sandbox. Sila adunay ilang kaugalingon nga virtual network adapter, ilang kaugalingon nga file system nga adunay limitado nga pag-access, ilang kaugalingon nga hierarchy sa mga proseso, ilang kaugalingon nga mga limitasyon sa CPU ug memorya, ug uban pa. Kining tanan gipatuman salamat sa usa ka espesyal nga subsystem sa Linux kernel - namespaces.

Kubernetes

Sama sa giingon sa sayo pa, ang Kubernetes usa ka container orchestrator. Kini molihok sama niini: hatagan nimo kini og usa ka pool sa mga makina, ug dayon isulti: "Hoy, Kubernetes, ilunsad nato ang napulo ka mga higayon sa akong sudlanan nga adunay 2 nga mga processor ug 3 GB nga memorya matag usa, ug ipadayon kini sa pagdagan!" Kubernetes na ang bahala sa uban. Makapangita kini nga libre nga kapasidad, maglunsad og mga sudlanan ug i-restart kini kung gikinahanglan, i-roll out ang usa ka update kung mag-ilis sa mga bersyon, ug uban pa. Sa esensya, gitugotan ka sa Kubernetes nga i-abstract ang sangkap sa hardware ug maghimo usa ka daghang lainlain nga sistema nga angay alang sa pag-deploy ug pagpadagan sa mga aplikasyon.

Kubernetes gikan sa punto sa panglantaw sa layko

Unsa ang mga hangyo ug limitasyon sa Kubernetes

Okay, gitabonan namo ang mga sudlanan ug Kubernetes. Nahibal-an usab namon nga daghang mga sudlanan ang mahimong magpuyo sa parehas nga makina.

Ang usa ka analohiya mahimong makuha sa usa ka komunal nga apartment. Ang usa ka lapad nga lugar (mga makina/unit) gikuha ug giabangan sa daghang mga saop (mga sudlanan). Ang Kubernetes naglihok isip usa ka realtor. Ang pangutana mitungha, unsaon pagpugong sa mga saop gikan sa mga panagbangi sa usag usa? Unsa kaha kon ang usa kanila, ingnon ta, mohukom nga manghulam sa banyo sulod sa tunga sa adlaw?

Dinhi ang mga hangyo ug mga limitasyon moabut sa pagdula. CPU hangyo gikinahanglan lamang alang sa mga katuyoan sa pagplano. Kini usa ka butang nga sama sa usa ka "lista sa pangandoy" sa sudlanan, ug kini gigamit sa pagpili sa labing angay nga node. Sa samang higayon ang CPU Utlanan mahimong itandi sa usa ka abang nga kasabutan - sa diha nga kita mopili sa usa ka yunit alang sa sudlanan, ang dili pwede lapas sa gitakdang mga limitasyon. Ug dinhi mitungha ang problema...

Giunsa gipatuman ang mga hangyo ug limitasyon sa Kubernetes

Ang Kubernetes naggamit ug throttling mechanism (laktaw nga mga siklo sa orasan) nga gitukod sa kernel aron ipatuman ang mga limitasyon sa CPU. Kung ang usa ka aplikasyon molapas sa limitasyon, ang throttling gipagana (pananglitan, nakadawat kini og gamay nga mga siklo sa CPU). Ang mga hangyo ug mga limitasyon alang sa memorya giorganisar sa lahi nga paagi, mao nga kini mas sayon nga makit-an. Aron mahimo kini, susiha lang ang katapusang restart status sa pod: kung kini ba "OOMKilled". Ang CPU throttling dili kaayo yano, tungod kay ang K8s naghimo lamang sa mga sukatan nga magamit pinaagi sa paggamit, dili sa mga cgroup.

Pangayo sa CPU

Giunsa gipatuman ang hangyo sa CPU

Alang sa kayano, atong tan-awon ang proseso gamit ang usa ka makina nga adunay 4-core nga CPU isip pananglitan.

Ang K8s naggamit ug mekanismo sa control group (cgroups) aron makontrol ang alokasyon sa mga kahinguhaan (memorya ug processor). Adunay usa ka hierarchical nga modelo alang niini: ang bata makapanunod sa mga limitasyon sa ginikanan nga grupo. Ang mga detalye sa pag-apod-apod gitipigan sa usa ka virtual file system (/sys/fs/cgroup). Sa kaso sa usa ka processor mao kini /sys/fs/cgroup/cpu,cpuacct/*.

Ang K8s naggamit sa file cpu.share sa paggahin sa mga kapanguhaan sa processor. Sa among kaso, ang root cgroup nakakuha og 4096 nga bahin sa mga kapanguhaan sa CPU - 100% sa magamit nga gahum sa processor (1 core = 1024; kini usa ka piho nga kantidad). Ang gamut nga grupo nag-apod-apod sa mga kapanguhaan nga proporsyonal depende sa bahin sa mga kaliwat nga narehistro cpu.share, ug sila, sa baylo, nagbuhat sa sama sa ilang mga kaliwat, ug uban pa. Sa kasagarang Kubernetes node, ang root cgroup adunay tulo ka mga anak: system.slice, user.slice и kubepods. Ang unang duha ka mga subgroup gigamit sa pag-apod-apod sa mga kahinguhaan tali sa mga kritikal nga sistema sa load ug mga programa sa user gawas sa K8s. Katapusan nga - kubepods — gihimo sa Kubernetes aron ipang-apod-apod ang mga kapanguhaan taliwala sa mga pod.

Ang dayagram sa ibabaw nagpakita nga ang una ug ikaduhang subgroup nakadawat sa matag usa 1024 shares, uban sa kuberpod subgroup nga gigahin 4096 shares Giunsa kini mahimo: pagkahuman, ang gamut nga grupo adunay access lamang 4096 bahin, ug ang sumada sa mga bahin sa iyang mga kaliwat milapas sa kini nga gidaghanon (6144)? Ang punto mao nga ang bili naghimo sa lohikal nga kahulugan, mao nga ang Linux scheduler (CFS) naggamit niini sa proporsyonal nga paggahin sa mga kapanguhaan sa CPU. Sa among kaso, ang unang duha ka grupo nakadawat 680 tinuod nga bahin (16,6% sa 4096), ug kubepod makadawat sa nahibilin 2736 shares Sa kaso sa downtime, ang unang duha ka grupo dili mogamit sa gigahin nga mga kapanguhaan.

Maayo na lang, ang scheduler adunay mekanismo aron malikayan ang pag-usik sa wala magamit nga mga kapanguhaan sa CPU. Gibalhin niini ang "idle" nga kapasidad ngadto sa usa ka global pool, diin kini giapod-apod sa mga grupo nga nanginahanglan dugang nga gahum sa processor (ang pagbalhin mahitabo sa mga batch aron malikayan ang mga pagkawala sa rounding). Ang susamang paagi gipadapat sa tanang kaliwat sa mga kaliwat.

Kini nga mekanismo nagsiguro sa usa ka patas nga pag-apod-apod sa gahum sa processor ug nagsiguro nga walay usa nga nagproseso nga "makakawat" sa mga kapanguhaan gikan sa uban.

Limitasyon sa CPU

Bisan pa sa kamatuoran nga ang mga pag-configure sa mga limitasyon ug mga hangyo sa K8s susama nga tan-awon, ang ilang pagpatuman lahi kaayo: kini labing makapahisalaag ug ang pinakagamay nga dokumentado nga bahin.

Nag-apil ang K8s CFS quota nga mekanismo sa pagpatuman sa mga limitasyon. Ang ilang mga setting gitakda sa mga file cfs_period_us и cfs_quota_us sa direktoryo sa cgroup (ang file nahimutang usab didto cpu.share).

Dili sama sa cpu.share, ang quota gibase sa yugto sa panahon, ug dili sa magamit nga gahum sa processor. cfs_period_us nagtino sa gidugayon sa panahon (panahon) - kini kanunay nga 100000 μs (100 ms). Adunay usa ka kapilian sa pag-usab niini nga bili sa K8s, apan kini anaa lamang sa alpha sa pagkakaron. Gigamit sa scheduler ang panahon aron i-restart ang gigamit nga mga quota. Ikaduha nga file cfs_quota_us, nagtino sa magamit nga oras (quota) sa matag panahon. Timan-i nga gipiho usab kini sa microseconds. Ang quota mahimong molapas sa gitas-on sa panahon; sa laing pagkasulti, kini mahimong labaw pa sa 100 ms.

Atong tan-awon ang duha ka mga senaryo sa 16-core nga mga makina (ang labing komon nga matang sa kompyuter nga anaa kanato sa Omio):

Scenario 1: 2 ka thread ug 200 ms limit. Walay throttling

Scenario 2: 10 ka thread ug 200 ms limit. Magsugod ang throttling pagkahuman sa 20 ms, ang pag-access sa mga kapanguhaan sa processor ipadayon pagkahuman sa laing 80 ms

Ingnon ta nga imong gitakda ang limitasyon sa CPU sa 2 mga lugas; Ang mga Kubernetes maghubad niini nga kantidad ngadto sa 200 ms. Kini nagpasabot nga ang sudlanan makagamit sa labing taas nga 200ms sa oras sa CPU nga walay throttling.

Ug dinhi nagsugod ang kalingawan. Sama sa gihisgutan sa ibabaw, ang magamit nga quota mao ang 200 ms. Kung nagtrabaho ka sa parallel napulo mga thread sa usa ka 12-core nga makina (tan-awa ang ilustrasyon para sa scenario 2), samtang ang tanan nga uban nga mga pod walay trabaho, ang quota mahurot sa 20 ms lamang (sukad sa 10 * 20 ms = 200 ms), ug ang tanan nga mga thread niini nga pod magbitay. » (throttle) alang sa sunod nga 80 ms. Ang nahisgutan na scheduler bug, tungod niini mahitabo ang sobra nga throttling ug ang sudlanan dili gani makatuman sa kasamtangan nga quota.

Sa unsa nga paagi sa pagtimbang-timbang sa throttling sa pods?

Pag-login lang sa pod ug i-execute cat /sys/fs/cgroup/cpu/cpu.stat.

nr_periods - ang kinatibuk-ang gidaghanon sa mga yugto sa scheduler;
nr_throttled - gidaghanon sa mga throttled nga mga panahon sa komposisyon nr_periods;
throttled_time - cumulative throttled nga oras sa nanoseconds.

Unsa man gyud ang nahitabo?

Ingon usa ka sangputanan, nakakuha kami taas nga throttling sa tanan nga mga aplikasyon. Usahay naa siya usa ug tunga ka beses mas kusgan kay sa kalkulado!

Nagdala kini sa lainlaing mga sayup - mga kapakyasan sa pagsusi sa pagkaandam, pag-freeze sa sudlanan, pagkaguba sa koneksyon sa network, mga oras sa sulod sa mga tawag sa serbisyo. Kini sa katapusan moresulta sa dugang nga latency ug mas taas nga error rate.

Desisyon ug mga sangputanan

Ang tanan yano dinhi. Gibiyaan namo ang mga limitasyon sa CPU ug gisugdan ang pag-update sa OS kernel sa mga cluster ngadto sa pinakabag-o nga bersyon, diin ang bug naayo. Ang gidaghanon sa mga sayup (HTTP 5xx) sa among mga serbisyo mius-os dayon:

Mga sayop sa HTTP 5xx

Mga sayop sa HTTP 5xx alang sa usa ka kritikal nga serbisyo

Oras sa pagtubag p95

Ang latency sa hangyo sa kritikal nga serbisyo, ika-95 nga porsyento

Mga gasto sa operasyon

Gidaghanon sa mga oras nga gigugol

Unsa man ang kuha?

Ingon sa gipahayag sa sinugdanan sa artikulo:

Ang usa ka analohiya mahimong madrowing sa usa ka komunal nga apartment... Ang Kubernetes naglihok isip usa ka realtor. Apan unsaon pagpugong sa mga saop gikan sa panagbangi sa usag usa? Unsa kaha kon ang usa kanila, ingnon ta, mohukom nga manghulam sa banyo sulod sa tunga sa adlaw?

Ania ang kuha. Ang usa ka walay pagtagad nga sudlanan mahimong makakaon sa tanang anaa nga mga kapanguhaan sa CPU sa usa ka makina. Kung ikaw adunay usa ka intelihente nga stack sa aplikasyon (pananglitan, ang JVM, Go, Node VM husto nga gi-configure), nan kini dili usa ka problema: mahimo ka magtrabaho sa ingon nga mga kondisyon sa dugay nga panahon. Apan kung ang mga aplikasyon dili maayo nga na-optimize o wala gyud ma-optimize (FROM java:latest), ang sitwasyon mahimong dili makontrol. Sa Omio kami adunay automated nga base Dockerfiles nga adunay igong default nga mga setting alang sa mayor nga stack sa pinulongan, mao nga kini nga isyu wala maglungtad.

Girekomenda namon ang pagmonitor sa mga sukatan PAGGAMIT (paggamit, saturation ug mga kasaypanan), mga paglangan sa API ug mga rate sa sayup. Siguroha nga ang mga resulta makaabot sa mga gilauman.

mga pakisayran

Mao ni among story. Ang mosunod nga mga materyales nakatabang pag-ayo sa pagsabot sa nahitabo:

Mga ulat sa bug sa Kubernetes:

Nakasugat ka ba og susama nga mga problema sa imong praktis o adunay kasinatian nga may kalabutan sa throttling sa containerized production environment? Ipakigbahin ang imong istorya sa mga komento!

PS gikan sa tighubad

Basaha usab sa among blog:

Source: www.habr.com

Mga limitasyon sa CPU ug agresibo nga pag-throttling sa Kubernetes