{"id":77693,"date":"2020-04-13T01:42:39","date_gmt":"2020-04-12T23:42:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes"},"modified":"2020-04-13T01:42:39","modified_gmt":"2020-04-12T23:42:39","slug":"cpu-limity-i-agressivnyj-trottling-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","title":{"rendered":"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota traduc\u0103torului.<\/b>: aceast\u0103 poveste instructiv\u0103 a Omio \u2014 aggregatorul de c\u0103l\u0103torii din Europa \u2014 \u00eendrum\u0103 cititorii de la teoria de baz\u0103 la subtilit\u0103\u021bi captivante \u00een configurarea Kubernetes. Familiarizarea cu astfel de cazuri nu doar l\u0103rge\u0219te orizonturile, ci ajut\u0103 \u0219i la prevenirea problemelor netriviale.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/1175c9df746e43b5a7d81476164929db.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA\u021bi \u00eent\u00e2mpinat vreodat\u0103 problema ca aplica\u021bia s\u0103 \"r\u0103m\u00e2n\u0103 blocat\u0103\" \u0219i s\u0103 nu r\u0103spund\u0103 la cererile de verificare a st\u0103rii (health check) \u0219i s\u0103 nu reu\u0219i\u021bi s\u0103 \u00een\u021belege\u021bi cauza acestui comportament? Una dintre explica\u021bii este legat\u0103 de limita cotelor pe resursele CPU. Despre aceasta va fi vorba \u00een acest articol.<\/p>\n<p><b>TL;DR:<br \/>\nV\u0103 recomand\u0103m insistent s\u0103 renun\u021ba\u021bi la limitele CPU \u00een Kubernetes (sau s\u0103 dezactiva\u021bi cot\u0103rile CFS \u00een Kubelet), dac\u0103 utiliza\u021bi o versiune a kernelului Linux cu eroarea de cotare CFS. <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">exist\u0103<\/a><\/noindex> o eroare grav\u0103 \u0219i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">bine cunoscut\u0103<\/a><\/noindex> care duce la throttling excesiv \u0219i \u00eent\u00e2rzieri<\/b>.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>La Omio <b>\u00eentreaga infrastructur\u0103 este gestionat\u0103 de Kubernetes<\/b>. Toate sarcinile noastre de lucru stateful \u0219i stateless func\u021bioneaz\u0103 exclusiv pe Kubernetes (folosim Google Kubernetes Engine). \u00cen ultimele \u0219ase luni, am \u00eenceput s\u0103 observ\u0103m \u00eent\u00e2rzieri aleatorii. Aplica\u021biile se blocheaz\u0103 sau nu r\u0103spund la health checks, pierd conexiunea la re\u021bea etc. Un astfel de comportament ne-a pus \u00een \u00eencurc\u0103tur\u0103 pentru o vreme, \u0219i, La final, am decis s\u0103 ne ocup\u0103m serios de problem\u0103.<\/p>\n<p>Rezumatul articolului:<\/p>\n<ul>\n<li> C\u00e2teva cuvinte despre containere \u0219i Kubernetes;<\/li>\n<li> Cum sunt implementate cererile \u0219i limitele CPU;<\/li>\n<li> Cum func\u021bioneaz\u0103 limitarea CPU \u00een medii cu mai multe nuclee;<\/li>\n<li> Cum s\u0103 monitoriz\u0103m throttlingul CPU;<\/li>\n<li> Solu\u021bia problemei \u0219i nuan\u021bele.<\/li>\n<\/ul>\n<p><\/p>\n<h2>C\u00e2teva cuvinte despre containere \u0219i Kubernetes<\/h2>\n<p>\nKubernetes este, \u00een esen\u021b\u0103, standardul modern \u00een lumea infrastructurii. Sarcina sa principal\u0103 este orchestrarea containerelor.<\/p>\n<h3>Containere<\/h3>\n<p>\n\u00cen trecut, era necesar s\u0103 cre\u0103m artefacte precum Java JAR\/WAR, Python Egg sau fi\u0219iere executabile pentru a fi rulate ulterior pe servere. Cu toate acestea, pentru a le face s\u0103 func\u021bioneze, era necesar s\u0103 facem munc\u0103 suplimentar\u0103: s\u0103 instal\u0103m mediul de execu\u021bie (Java\/Python), s\u0103 plas\u0103m fi\u0219ierele necesare \u00een locurile corecte, s\u0103 asigur\u0103m compatibilitatea cu o anumit\u0103 versiune a sistemului de operare etc. Cu alte cuvinte, trebuia s\u0103 acord\u0103m o aten\u021bie deosebit\u0103 gestion\u0103rii configura\u021biilor (ceea ce adesea provoca conflicte \u00eentre dezvoltatori \u0219i administratori de sistem).<\/p>\n<p><b>Containerele au schimbat totul.<\/b> Acum, artefactul este o imagine de container. Poate fi v\u0103zut ca un fel de fi\u0219ier executabil extins, care con\u021bine nu doar programul, ci \u0219i un mediu de execu\u021bie complet (Java\/Python\/\u2026) \u0219i fi\u0219iere\/pachete necesare, preinstalate \u0219i gata de rulat. Containerele pot fi desf\u0103\u0219urate \u0219i rulate pe diverse servere f\u0103r\u0103 alte ac\u021biuni suplimentare.<\/p>\n<p>\u00cen plus, containerele func\u021bioneaz\u0103 \u00eentr-un mediu sandbox propriu. Au propriul adaptator de re\u021bea virtual, sistem de fi\u0219iere cu acces restric\u021bionat, propria ierarhie de procese, limit\u0103ri pe CPU \u0219i memorie etc. Toate acestea sunt realizate datorit\u0103 unei subsisteme speciale din kernelul Linux \u2014 namespaces (spa\u021bii de nume).<\/p>\n<h3>Kubernetes<\/h3>\n<p>\nA\u0219a cum s-a men\u021bionat mai devreme, Kubernetes este un orchestrator de containere. Func\u021bioneaz\u0103 \u00een felul urm\u0103tor: \u00eei oferi\u021bi un grup de ma\u0219ini \u0219i apoi spune\u021bi: \u201eHei, Kubernetes, ruleaz\u0103 zece instan\u021be ale containerului meu cu 2 procesoare \u0219i 3 GB de RAM fiecare \u0219i men\u021bine-le func\u021bionale!\u201d. Kubernetes se va ocupa de restul. Va g\u0103si resursele disponibile, va lansa containerele \u0219i le va reporni c\u00e2nd este necesar, va rula upgrade-uri la schimbarea versiunilor etc. Practic, Kubernetes permite abstraherea de componenta hardware \u0219i face ca diversitatea sistemelor s\u0103 fie potrivit\u0103 pentru desf\u0103\u0219urarea \u0219i func\u021bionarea aplica\u021biilor.<\/p>\n<p><img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/6509bb1b66a4a0f5e9a479d0bd6ececb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kubernetes din perspectiva unui simplu cet\u0103\u021bean<\/i><\/p>\n<h2>Ce sunt cererile \u0219i limitele \u00een Kubernetes<\/h2>\n<p>\nBun, am \u00een\u021beles containerele \u0219i Kubernetes. De asemenea, \u0219tim c\u0103 mai multe containere pot fi rulate pe aceea\u0219i ma\u0219in\u0103.<\/p>\n<p>Se poate face o analogie cu o garsonier\u0103. Se ia o \u00eenc\u0103pere spa\u021bioas\u0103 (ma\u0219ini\/noduri) \u0219i se \u00eenchiriaz\u0103 mai multor chiria\u0219i (containere). Kubernetes joac\u0103 rolul agentului imobiliar. Se na\u0219te \u00eentrebarea, cum putem preveni conflictele \u00eentre chiria\u0219i? Ce se \u00eent\u00e2mpl\u0103 dac\u0103 unul dintre ei, s\u0103 zicem, decide s\u0103 ocupe baia timp de o jum\u0103tate de zi?<\/p>\n<p>Aici intervin cererile \u0219i limitele CPU. <b>Request<\/b> este necesar exclusiv pentru planificare. Este ca un \u00ablista de dorin\u021be\u00bb a containerului, folosit pentru a g\u0103si nodul cel mai potrivit. \u00cen acela\u0219i timp, CPU <b>Limit<\/b> poate fi comparat cu un contract de \u00eenchiriere - de \u00eendat\u0103 ce g\u0103sim un nod pentru container, acesta <b>nu va putea<\/b> dep\u0103\u0219i limitele stabilite. \u0218i aici apare problema\u2026<\/p>\n<h3>Cum sunt implementate cererile \u0219i limitele \u00een Kubernetes<\/h3>\n<p>\nKubernetes folose\u0219te un mecanism de throttling (reglare a vitezei) \u00eencorporat \u00een kernel pentru a implementa limitele CPU. Dac\u0103 aplica\u021bia dep\u0103\u0219e\u0219te limita, se activeaz\u0103 throttling (adic\u0103 prime\u0219te mai pu\u021bin timp CPU). Cererile \u0219i limitele pentru memorie sunt organizate diferit, iar acestea sunt mai u\u0219or de detectat. Este suficient s\u0103 verific\u0103m ultimul status de restart al pod-ului: nu este \"OOMKilled\". Cu throttling-ul CPU, lucrurile nu sunt at\u00e2t de simple, deoarece K8s ofer\u0103 doar metrici de utilizare, nu \u0219i despre cgroups.<\/p>\n<h4>CPU Request<\/h4>\n<p>\n<img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/fbc8bf3f775ffd9513374ce94b20535d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Cum este implementat CPU request<\/i><\/p>\n<p>Pentru simplitate, s\u0103 lu\u0103m ca exemplu un proces pe o ma\u0219in\u0103 cu un CPU cu 4 nuclee.<\/p>\n<p>K8s utilizeaz\u0103 un mecanism de grupuri de control (cgroups) pentru a gestiona distribu\u021bia resurselor (memorie \u0219i procesor). Este disponibil un model ierarhic: un copil mo\u0219tene\u0219te limitele grupului p\u0103rinte. Detalii despre distribu\u021bie sunt stocate \u00een sistemul de fi\u0219iere virtual.<code>\/sys\/fs\/cgroup<\/code>). \u00cen cazul procesorului, aceasta este <code>\/sys\/fs\/cgroup\/cpu,cpuacct\/*<\/code>.<\/p>\n<p>K8s utilizeaz\u0103 fi\u0219ierul <code>cpu.share<\/code> pentru a distribui resursele procesorului. \u00cen cazul nostru, grupul de control r\u0103d\u0103cin\u0103 prime\u0219te 4096 de p\u0103r\u021bi din resursele CPU \u2014 100% din capacitatea total\u0103 a procesorului (1 nucleu = 1024; aceasta este o valoare fix\u0103). Grupul r\u0103d\u0103cin\u0103 distribuie resursele propor\u021bional \u00een func\u021bie de p\u0103r\u021bile urma\u0219ilor, specificate \u00een <code>cpu.share<\/code>, ace\u0219tia, la r\u00e2ndul lor, procedeaz\u0103 similar cu urma\u0219ii lor etc. \u00centr-un nod tipic Kubernetes, grupul de control r\u0103d\u0103cin\u0103 are trei urma\u0219i: <code>system.slice<\/code>, <code>user.slice<\/code> \u0219i <code>kubepods<\/code>. Primile dou\u0103 subgrupuri sunt utilizate pentru a distribui resurse \u00eentre sarcinile de sistem critic \u0219i aplica\u021biile utilizatorilor \u00een afara K8s. Ultimul \u2014 <code>kubepods<\/code> \u2014 este creat de Kubernetes pentru a distribui resursele \u00eentre pod-uri.<\/p>\n<p>\u00cen schema de mai sus, se observ\u0103 c\u0103 prima \u0219i a doua subgrup\u0103 au primit c\u00e2te <b>1024<\/b> par\u021bi, iar subgrupa kuberpod a primit <b>4096<\/b> p\u0103r\u021bi. Cum este posibil asta: av\u00e2nd \u00een vedere c\u0103 grupului r\u0103d\u0103cin\u0103 \u00eei sunt disponibile doar <b>4096<\/b> p\u0103r\u021bi, iar suma p\u0103r\u021bilor descenden\u021bilor s\u0103i dep\u0103\u0219e\u0219te semnificativ acest num\u0103r (<b>6144<\/b>)? Problema este c\u0103 acest lucru are sens logic, prin urmare, programatorul Linux (CFS) \u00eel utilizeaz\u0103 pentru a distribui propor\u021bional resursele CPU. \u00cen cazul nostru, primele dou\u0103 grupuri primesc c\u00e2te <b>680<\/b> p\u0103r\u021bi reale (16,6% din 4096), iar kubepod prime\u0219te restul de <b>2736<\/b> p\u0103r\u021bi. \u00cen cazul de inactivitate, primele dou\u0103 grupuri nu vor utiliza resursele alocate.<\/p>\n<p>Din fericire, \u00een programator exist\u0103 un mecanism care ajut\u0103 la evitarea pierderii resurselor CPU neutilizate. Acesta transfer\u0103 puterea 'inactiv\u0103' \u00een un fond global, din care acestea sunt redistribuite c\u0103tre grupurile care necesit\u0103 capacit\u0103\u021bi suplimentare de procesor (trasferul se face pe loturi pentru a evita pierderile din rotunjire). O metod\u0103 similar\u0103 este aplicat\u0103 tuturor descenden\u021bilor.<\/p>\n<p>Acest mecanism asigur\u0103 o distribu\u021bie echitabil\u0103 a capacit\u0103\u021bilor procesorului \u0219i se asigur\u0103 c\u0103 niciun proces nu 'fura' resurse de la altele.<\/p>\n<h4>Limit\u0103 CPU<\/h4>\n<p>\nDe\u0219i configura\u021biile limitelor \u0219i cererilor \u00een K8s par asem\u0103n\u0103toare, implementarea lor este radical diferit\u0103: aceasta <b>cea mai \u00een\u0219el\u0103toare<\/b> \u0219i cea mai pu\u021bin documentat\u0103 parte.<\/p>\n<p>K8s utilizeaz\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">mecanismul de cote CFS<\/a><\/noindex> pentru a implementa limitele. Set\u0103rile acestora sunt definite \u00een fi\u0219ierele <code>cfs_period_us<\/code> \u0219i <code>cfs_quota_us<\/code> din directorul cgroup (acolo se afl\u0103 \u0219i fi\u0219ierul <code>cpu.share<\/code>).<\/p>\n<p>Spre deosebire de <code>cpu.share<\/code>, cota se bazeaz\u0103 pe <b>perioada de timp<\/b>, nu pe capacitatea disponibil\u0103 a procesorului. <code>cfs_period_us<\/code> stabile\u0219te durata perioadei (epocii) \u2014 aceasta este \u00eentotdeauna 100000 \u03bcs (100 ms). \u00cen K8s exist\u0103 op\u021biunea de a schimba aceast\u0103 valoare, cu toate c\u0103 aceasta este disponibil\u0103 doar \u00een versiunea alpha. Programatorul folose\u0219te epoca pentru a reporni cotelor utilizate. Al doilea fi\u0219ier, <code>cfs_quota_us<\/code>, stabile\u0219te timpul disponibil (cota) \u00een fiecare epoc\u0103. Re\u021bine\u021bi c\u0103 acesta este de asemenea specificat \u00een microsecunde. Cota poate dep\u0103\u0219i durata epocii; cu alte cuvinte, poate fi mai mare de 100 ms.<\/p>\n<p>S\u0103 lu\u0103m \u00een considerare dou\u0103 scenarii pe ma\u0219ini cu 16 nuclee (cel mai comun tip de computere pentru noi la Omio):<\/p>\n<p><img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/61c6105320af3a92a91cec1007da0d45.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Scenariul 1: 2 fluxuri \u0219i limit\u0103 de 200 ms. F\u0103r\u0103 throttling<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/c33993341d5395bb73dda1f4c8482a11.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Scenariul 2: 10 fluxuri \u0219i limit\u0103 de 200 ms. Throttling-ul \u00eencepe dup\u0103 20 ms, accesul la resursele procesorului este reluat dup\u0103 \u00eenc\u0103 80 ms<\/i><\/p>\n<p>S\u0103 presupunem c\u0103 a\u021bi setat limita CPU pe <b>2<\/b> nuclee; Kubernetes va traduce aceast\u0103 valoare \u00een 200 ms. Asta \u00eenseamn\u0103 c\u0103 containerul poate folosi maximum 200 ms de timp de procesor f\u0103r\u0103 throttling.<\/p>\n<p>\u0218i aici \u00eencepe partea interesant\u0103. A\u0219a cum s-a men\u021bionat mai sus, cota disponibil\u0103 este de 200 ms. Dac\u0103 ave\u021bi simultan <b>zece<\/b> fluxuri pe o ma\u0219in\u0103 cu 12 nuclee (vezi ilustra\u021bia pentru scenariul 2), timp \u00een care toate celelalte pod-uri sunt inactive, cota va fi epuizat\u0103 \u00een doar 20 ms (deoarece 10 * 20 ms = 200 ms), \u0219i toate fluxurile acestui pod se vor \u201ebloca\u201d. <i>(throttle)<\/i> pentru urm\u0103toarele 80 ms. Situa\u021bia este agravat\u0103 de deja men\u021bionat <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">bug al planificatorului<\/a><\/noindex>, care cauzeaz\u0103 throttling excesiv \u0219i containerul nu poate genera nici m\u0103car cota disponibil\u0103.<\/p>\n<h2>Cum s\u0103 evalu\u0103m throttling-ul \u00een pod-uri?<\/h2>\n<p>\nPur \u0219i simplu intra\u021bi \u00een pod \u0219i executa\u021bi <code>cat \/sys\/fs\/cgroup\/cpu\/cpu.stat<\/code>.<\/p>\n<ul>\n<li> <code>nr_periods<\/code> \u2014 num\u0103rul total de perioade ale planificatorului;<\/li>\n<li> <code>nr_throttled<\/code> \u2014 num\u0103rul de perioade throttled din <code>nr_periods<\/code>;<\/li>\n<li> <code>throttled_time<\/code> \u2014 timpul total throttled \u00een nanosecunde.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/a1818614914a8c31f7f7f1331cc02e8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Ce se \u00eent\u00e2mpl\u0103 de fapt?<\/h3>\n<p>\n\u00cen concluzie, ob\u021binem un throttling ridicat \u00een toate aplica\u021biile. Uneori este de <b>1,5 ori<\/b> mai mare dec\u00e2t cel estimat!<\/p>\n<p>Acest lucru duce la diverse erori \u2014 e\u0219ecuri ale verific\u0103rilor de disponibilitate (readiness), \u00eenghe\u021barea containerelor, \u00eentreruperi ale conexiunilor de re\u021bea, timeout-uri \u00een cadrul apelurilor de serviciu. \u00cen cele din urm\u0103, acest lucru se traduce prin o \u00eent\u00e2rziere crescut\u0103 \u0219i o cre\u0219tere a erorilor.<\/p>\n<h2>Solu\u021bia \u0219i consecin\u021bele<\/h2>\n<p>\nAici este simplu. Am renun\u021bat la limitele CPU \u0219i ne-am ocupat de actualizarea kernel-ului OS \u00een clustere la cea mai recent\u0103 versiune, \u00een care bug-ul a fost rezolvat. Num\u0103rul de erori (HTTP 5xx) \u00een serviciile noastre a sc\u0103zut imediat semnificativ:<\/p>\n<h3>Erori HTTP 5xx<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/86ab1694b952b5451a4ae075cbda2788.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Erori HTTP 5xx ale unui serviciu critic<\/i><\/p>\n<h3>Timpul de r\u0103spuns p95<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/63922c8eb468366a7d05154a3adf40e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>\u00cent\u00e2rzierea cererilor pentru un serviciu critic, percentila 95<\/i><\/p>\n<h3>Cheltuieli opera\u021bionale<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limit\u0103rile CPU \u0219i throttlingul agresiv \u00een Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/8405c26fcbd82853e296fa7e3bcba131.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Num\u0103rul de ore de instan\u021b\u0103 consumate<\/i><\/p>\n<h2>Care este capcana?<\/h2>\n<p>\nA\u0219a cum s-a spus la \u00eenceputul articolului:<\/p>\n<blockquote><p>Se poate face o analogie cu un apartament comun\u2026 Kubernetes ac\u021bioneaz\u0103 ca un agent imobiliar. Dar cum s\u0103 \u00eempiedici chiria\u0219ii s\u0103 intre \u00een conflict \u00eentre ei? Ce se \u00eent\u00e2mpl\u0103 dac\u0103 unul dintre ei, s\u0103 zicem, decide s\u0103 ocupe baia timp de o jum\u0103tate de zi?<\/p><\/blockquote>\n<p>\nAici este capcana. Un container neglijent poate consuma toate resursele disponibile ale procesorului pe ma\u0219in\u0103. Dac\u0103 ai un stiv\u0103 de aplica\u021bii bine configurat\u0103 (de exemplu, JVM-uri, Go, Node VM configurate corespunz\u0103tor), atunci nu este o problem\u0103: po\u021bi func\u021biona \u00een aceste condi\u021bii pentru o perioad\u0103 lung\u0103 de timp. Dar dac\u0103 aplica\u021biile sunt prost optimizate sau complet neoptimizate (<code>FROM java:latest<\/code>), situa\u021bia poate sc\u0103pa de sub control. La Omio avem fi\u0219ier Docker de baz\u0103 automatizate cu set\u0103ri adecvate implicite pentru stiva principalelor limbaje, astfel \u00eenc\u00e2t aceast\u0103 problem\u0103 nu a existat.<\/p>\n<p>Recomand\u0103m s\u0103 monitoriz\u0103m metricele <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/usemethod.html\">USE<\/a><\/noindex> (utilizare, satura\u021bie \u0219i erori), \u00eent\u00e2rzierile API \u0219i frecven\u021ba erorilor. Asigura\u021bi-v\u0103 c\u0103 rezultatele se aliniaz\u0103 cu a\u0219tept\u0103rile.<\/p>\n<h2>Linkuri<\/h2>\n<p>\nAceasta este povestea noastr\u0103. Materialele urm\u0103toare ne-au ajutat foarte mult s\u0103 \u00een\u021belegem ce se \u00eent\u00e2mpl\u0103:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">kernel.org \u2192 CFS Scheduler<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-bwc.txt\">kernel.org \u2192 CFS Bandwidth Control<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/engineering.squarespace.com\/blog\/2017\/understanding-linux-container-scheduling\">\u00cen\u021belegerea program\u0103rii containerelor Linux<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.linuxjournal.com\/content\/everything-you-need-know-about-linux-containers-part-i-linux-control-groups-and-process\">Tot ce trebuie s\u0103 \u0219ti\u021bi despre containerele Linux, Partea I: Grupuri de control Linux \u0219i Izolarea proceselor<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/k8s.af\/\">Povestiri despre e\u0219ecurile Kubernetes<\/a><\/noindex> \u2014 c\u0103uta\u021bi \u00abcpu throttling\u00bb.<\/li>\n<\/ul>\n<p>\nRaportele de erori Kubernetes:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/51135#issuecomment-373454012\">#51135: Avoid setting CPU limits for Guaranteed pods<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">#67577: CFS quotas can lead to unnecessary throttling<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gist.github.com\/bobrik\/2030ff040fad360327a5fab7a09c4ff1\">CFS prea agresiv<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nTe-ai confruntat cu probleme similare \u00een practica ta sau ai experien\u021be legate de throttling \u00een medii de produc\u021bie containerizate? \u00cemp\u0103rt\u0103\u0219e\u0219te-\u021bi povestea \u00een comentarii!<\/p>\n<h2>P.S. de la traduc\u0103tor<\/h2>\n<p>\nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/459326\/\">Autoscalarea \u0219i gestionarea resurselor \u00een Kubernetes (prezentare general\u0103 \u0219i videoclip prezentare)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/418269\/\">Cum func\u021bioneaz\u0103 CPU Manager \u00een Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/342822\/\">Ce se \u00eent\u00e2mpl\u0103 \u00een Kubernetes c\u00e2nd lansezi kubectl run? Partea 2<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/489668\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes. \u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 \u0442\u0430\u043a\u0438\u043c\u0438 \u0441\u043b\u0443\u0447\u0430\u044f\u043c\u0438 \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u044f\u0442\u044c \u043a\u0440\u0443\u0433\u043e\u0437\u043e\u0440, \u043d\u043e \u0438 \u043f\u0440\u0435\u0434\u043e\u0442\u0432\u0440\u0430\u0449\u0430\u0442\u044c \u043d\u0435\u0442\u0440\u0438\u0432\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b. \u0414\u043e\u0432\u043e\u0434\u0438\u043b\u043e\u0441\u044c \u043b\u0438 \u0432\u0430\u043c \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0442\u0435\u043c, \u0447\u0442\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u00ab\u0437\u0430\u0441\u0442\u0440\u0435\u0432\u0430\u043b\u043e\u00bb \u043d\u0430 \u043c\u0435\u0441\u0442\u0435, \u043f\u0435\u0440\u0435\u0441\u0442\u0430\u0432\u0430\u043b\u043e \u043e\u0442\u0432\u0435\u0447\u0430\u0442\u044c \u043d\u0430 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u043e \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0435 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77694,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77693","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47CPU-\u043b\u0438\u043c\u0438\u0442\u044b \u0438 \u0430\u0433\u0440\u0435\u0441\u0441\u0438\u0432\u043d\u044b\u0439 \u0442\u0440\u043e\u0442\u0442\u043b\u0438\u043d\u0433 \u0432 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-04-12T23:42:39+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-12T23:42:39+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Limitele CPU \u0219i throttlingul agresiv \u00een Kubernetes | ProHoster","description":"Nota traduc\u0103torului: aceast\u0103 poveste instructiv\u0103 a Omio \u2014 agregator european de c\u0103l\u0103torii \u2014 conduce cititorii de la teoria de baz\u0103 la nuan\u021bele fascinante \u00een configurarea Kubernetes.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47CPU-\u043b\u0438\u043c\u0438\u0442\u044b \u0438 \u0430\u0433\u0440\u0435\u0441\u0441\u0438\u0432\u043d\u044b\u0439 \u0442\u0440\u043e\u0442\u0442\u043b\u0438\u043d\u0433 \u0432 Kubernetes | ProHoster","og:description":"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-12T23:42:39+00:00","article:modified_time":"2020-04-12T23:42:39+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"77693","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:13:23","updated":"2022-09-29 12:06:45","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/77693","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=77693"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/77693\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/77694"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=77693"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=77693"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=77693"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}