{"id":94262,"date":"2020-09-14T19:42:34","date_gmt":"2020-09-14T17:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod"},"modified":"2020-09-14T19:42:34","modified_gmt":"2020-09-14T17:42:34","slug":"kak-poluchit-dostup-k-resursam-kubernetes-pod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","title":{"rendered":"Cum s\u0103 ob\u021bii acces la resursele Kubernetes Pod","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Cum s\u0103 ob\u021bii acces la resursele Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/3d6760d512ef456daad121f7d1ddbcf8.jpg\" style=\"display:block;margin: 0 auto;\" \/><noindex><a rel=\"nofollow\" href=\"https:\/\/www.deviantart.com\/tohad\/art\/The-Reward-549720998\"><i>Recompensa de Tohad<\/i><\/a><\/noindex><\/p>\n<p>La \u00eenceputul lucrului cu Kubernetes, de obicei se uit\u0103 la configurarea resurselor containerelor. \u00cen aceast\u0103 etap\u0103, este suficient s\u0103 te asiguri c\u0103 imaginea Docker func\u021bioneaz\u0103 \u0219i poate fi desf\u0103\u0219urat\u0103 \u00een clusterul Kubernetes.<\/p>\n<p>\u00cens\u0103, mai t\u00e2rziu, aplica\u021bia trebuie desf\u0103\u0219urat\u0103 \u00een clusterul de produc\u021bie \u00eempreun\u0103 cu alte aplica\u021bii. Pentru aceasta, trebuie alocate resurse pentru container \u0219i asigurate suficiente pentru a porni \u0219i func\u021biona aplica\u021bia, f\u0103r\u0103 a provoca probleme altor aplica\u021bii rulate.<\/p>\n<p>Comanda <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Kubernetes aaS de la Mail.ru<\/a><\/noindex> am tradus articolul despre resursele containerelor (CPU &amp; MEM), cererile \u0219i limit\u0103rile resurselor. Vei afla ce avantaje ofer\u0103 aceste set\u0103ri \u0219i ce se \u00eent\u00e2mpl\u0103 dac\u0103 nu sunt configurate.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Resurse de calcul<\/h2>\n<p>\nAvem dou\u0103 tipuri de resurse cu urm\u0103toarele unit\u0103\u021bi:<\/p>\n<ul>\n<li>Unitate central\u0103 de procesare (CPU) - nuclee;<\/li>\n<li>Memorie (MEM) - bi\u021bi.<\/li>\n<\/ul>\n<p>\nResursele se specific\u0103 pentru fiecare container. \u00cen urm\u0103torul fi\u0219ier YAML al Pod-ului, vei vedea sec\u021biunea resurselor, care con\u021bine resursele solicitate \u0219i limitele resurselor:<\/p>\n<ul>\n<li>Resursele solicitate ale Pod-ului = suma resurselor solicitate de toate containerele;<\/li>\n<li>Resursele limitate ale Pod-ului = suma resurselor limitate de toate containerele.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: v1\nkind: Pod\nmetadata:\n  name: backend-pod-name\n  labels:\n    application: backend\nspec:\n  containers:\n    \u2014 name: main-container\n      image: my-backend\n      tag: v1\n      ports:\n      \u2014 containerPort: 8080\n      resources:\n        requests:\n          cpu: 0.2 # CPU SOLICITAT: 200m nuclee\n          memory: \"1Gi\" # MEM SOLICITAT: 1Gi\n        limits:\n          cpu: 1 # UTILIZARE MAXIM\u0102 CPU: 1 nucleu\n          memory: \"1Gi\" # UTILIZARE MAXIM\u0102 MEM:  1Gi\n    \u2014 name: other-container\n      image: other-app\n      tag: v1\n      ports:\n      \u2014 containerPort: 8000\n      resources:\n        requests:\n          cpu: \"200m\" # CPU SOLICITAT: 200m nuclee\n          memory: \"0.5Gi\" # MEM SOLICITAT: 0.5Gi\n        limits:\n          cpu: 1 # UTILIZARE MAXIM\u0102 CPU: 1 nucleu\n          memory: \"1Gi\" # UTILIZARE MAXIM\u0102 MEM:  1Gi<\/code><\/pre>\n<p>Exemplu de resurse solicitate \u0219i limitate<\/p>\n<p>C\u00e2mp <code>resources.requested<\/code> din specifica\u021bia Pod-ului - unul dintre elementele folosite pentru a c\u0103uta nodul necesar. Pe acesta poate fi programat\u0103 desf\u0103\u0219urarea Pod-ului. Cum se caut\u0103 nodul potrivit?<\/p>\n<p>Kubernetes este format din mai multe componente, inclusiv con\u021bine un nod principal sau un nod master (Kubernetes Control Plane). \u00cen nodul master exist\u0103 mai multe procese: kube-apiserver, kube-controller-manager \u0219i kube-scheduler. <\/p>\n<p>Procesul kube-scheduler se ocup\u0103 cu vizualizarea modulelor recent create \u0219i c\u0103utarea nodurilor de lucru posibile care corespund tuturor cerin\u021belor modulelor, inclusiv la num\u0103rul de resurse solicitate. Lista nodurilor g\u0103site de kube-scheduler este clasificat\u0103. Pod-ul este programat pe nodul cu cele mai mari punctaje.<\/p>\n<p><img decoding=\"async\" alt=\"Cum s\u0103 ob\u021bii acces la resursele Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/b489991a3cbbd5359c99701886d488e5.jpg\" style=\"display:block;margin: 0 auto;\" \/>Unde va fi plasat Pod-ul violet?<\/p>\n<p>\u00cen imagine se observ\u0103 c\u0103 kube-scheduler trebuie s\u0103 planifice un nou Pod violet. Clusterul Kubernetes con\u021bine dou\u0103 noduri: A \u0219i B. Dup\u0103 cum se poate observa, kube-scheduler nu poate planifica Podul pe nodul A \u2014 resursele disponibile (necerute) nu corespund cerin\u021belor Podului violet. Astfel, memoria solicitat\u0103 de Podul violet, de 1 GB, nu se va \u00eencadra pe nodul A, deoarece volumul de memorie disponibil este de 0,5 GB. Dar nodul B are suficiente resurse. \u00cen cele din urm\u0103, kube-scheduler decide c\u0103 destina\u021bia Podului violet este nodul B.<\/p>\n<p>Acum \u0219tim cum resursele solicitate influen\u021beaz\u0103 alegerea nodului pentru a rula un Pod. Dar cum influen\u021beaz\u0103 resursele limit\u0103?<\/p>\n<p>Resursele limit\u0103 reprezint\u0103 limitele pe care CPU\/MEM nu le pot dep\u0103\u0219i. Totu\u0219i, resursa CPU este flexibil\u0103, a\u0219a c\u0103 containerele care ating valorile limit\u0103 la CPU nu vor duce la oprirea Podului. \u00cen schimb, se va activa throttling-ul CPU. Dac\u0103 \u00eens\u0103 se atinge limita de utilizare a MEM, atunci containerul va fi oprit din cauza OOM-Killer \u0219i va fi repornit dac\u0103 acest lucru este permis de setarea RestartPolicy.<\/p>\n<h2>Resursele solicitate \u0219i limit\u0103 \u00een detalii<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Cum s\u0103 ob\u021bii acces la resursele Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/22e672100940e8895ae42a56a681111f.jpg\" style=\"display:block;margin: 0 auto;\" \/>Leg\u0103tura resurselor \u00eentre Docker \u0219i Kubernetes<\/p>\n<p>Cel mai bun mod de a explica cum func\u021bioneaz\u0103 resursele solicitate \u0219i limit\u0103 este de a reprezenta leg\u0103tura dintre Kubernetes \u0219i Docker. \u00cen imaginea de mai sus, pute\u021bi vedea cum sunt corelate c\u00e2mpurile Kubernetes \u0219i flag-urile de pornire Docker.<\/p>\n<h2>Memorie: solicitare \u0219i limit\u0103<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     memory: \"0.5Gi\"\n   limits:\n     memory: \"1Gi\"\n<\/code><\/pre>\n<p>\nDup\u0103 cum s-a men\u021bionat anterior, memoria este m\u0103surat\u0103 \u00een octe\u021bi. Pe baza <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-resources-containers\/#meaning-of-memory\">documenta\u021bia Kubernetes<\/a><\/noindex>, putem specifica memoria sub form\u0103 de num\u0103r. De obicei, este un \u00eentreg, de exemplu 2678 \u2014 adic\u0103 2678 octe\u021bi. De asemenea, se pot folosi sufixe <code>G<\/code> \u0219i <code>Gi<\/code>, este important s\u0103 re\u021binem c\u0103 acestea nu sunt echivalente. Primul este zecimal, iar al doilea este binar. Ca exemplu, men\u021bionat \u00een documenta\u021bia k8s: <code>128974848<\/code>, <code>129e6<\/code>, <code>129M<\/code>, <code>123Mi<\/code> \u2014 ele sunt practic echivalente.<\/p>\n<p>Parameterul Kubernetes <code>limits.memory<\/code> corespunde flag-ului <code>--memory<\/code> din Docker. \u00cen cazul lui <code>request.memory<\/code> s\u0103geata pentru Docker lipse\u0219te, deoarece Docker nu folose\u0219te acest c\u00e2mp. Te po\u021bi \u00eentreba, este acesta cu adev\u0103rat necesar? Da, este. Dup\u0103 cum am spus, c\u00e2mpul are valoare pentru Kubernetes. Pe baza informa\u021biilor din acesta, kube-scheduler decid\u0103 pe ce nod s\u0103 planifice Podul.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 se solicit\u0103 o memorie insuficient\u0103?<\/strong><\/p>\n<p>Dac\u0103 containerul atinge limitele memoriei solicitate, Podul este plasat \u00eentr-un grup de Poduri care se opresc \u00een caz de insuficien\u021b\u0103 de memorie \u00een nod.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 se seteaz\u0103 o limit\u0103 prea mic\u0103 pentru memorie?<\/strong><\/p>\n<p>Dac\u0103 un container dep\u0103\u0219e\u0219te limita de memorie, acesta va fi oprit din cauza OOM-Killed. \u0218i va fi repornit, dac\u0103 acest lucru este posibil \u00een func\u021bie de RestartPolicy, unde valoarea implicit\u0103 este <code>\u00centotdeauna<\/code>.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 nu se specific\u0103 memoria cerut\u0103?<\/strong><\/p>\n<p>Kubernetes va lua limita de memorie \u0219i o va stabili ca valoare implicit\u0103.<\/p>\n<p><strong>Ce se poate \u00eent\u00e2mpla dac\u0103 nu se specific\u0103 limita de memorie?<\/strong><\/p>\n<p>Containerul nu are restric\u021bii, poate utiliza at\u00e2ta memorie c\u00e2t dore\u0219te. Dac\u0103 \u00eencepe s\u0103 foloseasc\u0103 \u00eentreaga memorie disponibil\u0103 a nodului, atunci va fi oprit de OOM. Apoi, containerul va fi repornit, dac\u0103 acest lucru este posibil pe baza RestartPolicy.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 nu se specific\u0103 limitele de memorie?<\/strong><\/p>\n<p>Acesta este cel mai r\u0103u scenariu: planificatorul nu \u0219tie c\u00e2te resurse sunt necesare pentru container, iar acest lucru poate provoca probleme serioase pe nod. \u00cen acest caz, ar fi bine s\u0103 existe limite implicite \u00een spa\u021biul de nume (stabilite de LimitRange). Nu exist\u0103 limite implicite - Pod-ul nu are restric\u021bii, poate folosi at\u00e2ta memorie c\u00e2t dore\u0219te.<\/p>\n<p>Dac\u0103 memoria cerut\u0103 este mai mare dec\u00e2t poate oferi nodul - Pod-ul nu va fi planificat. Este important de re\u021binut c\u0103 <code>Requests.memory<\/code> nu este o valoare minim\u0103. Aceasta descrie cantitatea de memorie suficient\u0103 pentru func\u021bionarea constant\u0103 a containerului. <\/p>\n<p>De obicei, se recomand\u0103 s\u0103 se stabileasc\u0103 aceea\u0219i valoare pentru <code>request.memory<\/code> \u0219i <code>limit.memory<\/code>. Datorit\u0103 acestui fapt, Kubernetes nu va planifica Pod-ul pe un nod care are suficient\u0103 memorie pentru a rula Pod-ul, dar insuficient\u0103 pentru a func\u021biona. Re\u021bine\u021bi: \u00een timpul planific\u0103rii Pod-ului, Kubernetes ia \u00een considerare doar <code>requests.memory<\/code>, iar <code>limits.memory<\/code> nu ia \u00een considerare.<\/p>\n<h2>CPU: cerere \u0219i limit\u0103<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     cpu: 1\n   limits:\n     cpu: \"1200m\"\n<\/code><\/pre>\n<p>\nReferitor la CPU, lucrurile sunt pu\u021bin mai complicate. Revenind la imaginea cu rela\u021bia dintre Kubernetes \u0219i Docker, se poate observa c\u0103 <code>request.cpu<\/code> corespunde <code>--cpu-shares<\/code>, \u00een timp ce <code>limit.cpu<\/code> corespunde flag-ului <code>cpus<\/code> \u00een Docker.<\/p>\n<p>CPU-ul cerut de Kubernetes se \u00eenmul\u021be\u0219te cu 1024 \u2014 propor\u021bia ciclurilor CPU. Dac\u0103 dori\u021bi s\u0103 solicita\u021bi 1 nucleu complet, trebuie s\u0103 ad\u0103uga\u021bi <code>cpu: 1<\/code>, a\u0219a cum este prezentat mai sus. <\/p>\n<p>Cererea pentru un nucleu complet (propor\u021bie = 1024) nu \u00eenseamn\u0103 c\u0103 containerul dumneavoastr\u0103 \u00eel va primi. Dac\u0103 serverul dumneavoastr\u0103 gazd\u0103 are un singur nucleu \u0219i folosi\u021bi mai multe containere, atunci toate containerele trebuie s\u0103 \u00eempart\u0103 CPU-ul disponibil \u00eentre ele. Cum se \u00eent\u00e2mpl\u0103 asta? Hai s\u0103 arunc\u0103m o privire la imagine.<\/p>\n<p><img decoding=\"async\" alt=\"Cum s\u0103 ob\u021bii acces la resursele Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/7f4b20642708ef3a7e773d7900161267.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCererea CPU \u2014 sistem cu un singur nucleu<\/p>\n<p>Imagina\u021bi-v\u0103 c\u0103 ave\u021bi un sistem gazd\u0103 cu un singur nucleu, pe care ruleaz\u0103 containere. Mama (Kubernetes) a f\u0103cut o pl\u0103cint\u0103 (CPU) \u0219i vrea s\u0103 o \u00eempart\u0103 \u00eentre copii (containere). Trei copii vor fiecare o pl\u0103cint\u0103 \u00eentreag\u0103 (propor\u021bie = 1024), iar un alt copil vrea o jum\u0103tate de pl\u0103cint\u0103 (512). Mama vrea s\u0103 fie corect\u0103 \u0219i face un calcul simplu.<\/p>\n<pre><code class=\"plaintext\"># \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0445\u043e\u0442\u044f\u0442 \u0434\u0435\u0442\u0438?\n# 3 \u0440\u0435\u0431\u0435\u043d\u043a\u0430 \u0445\u043e\u0442\u044f\u0442 \u043f\u043e \u0446\u0435\u043b\u043e\u043c\u0443 \u043f\u0438\u0440\u043e\u0433\u0443 \u0438 \u0435\u0449\u0435 \u043e\u0434\u0438\u043d \u0445\u043e\u0447\u0435\u0442 \u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0443 \u043f\u0438\u0440\u043e\u0433\u0430\ncakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5\n# \u0412\u044b\u0440\u0430\u0436\u0435\u043d\u0438\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f \u0442\u0430\u043a:\n3 (\u0440\u0435\u0431\u0435\u043d\u043a\u0430\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430) * 1 (\u0446\u0435\u043b\u044b\u0439 \u043f\u0438\u0440\u043e\u0433\/\u043f\u043e\u043b\u043d\u043e\u0435 \u044f\u0434\u0440\u043e) + 1 (\u0440\u0435\u0431\u0435\u043d\u043e\u043a\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440) * 0.5 (\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u043f\u0438\u0440\u043e\u0433\u0430\/\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u044f\u0434\u0440\u0430)\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0438\u0441\u043f\u0435\u0447\u0435\u043d\u043e?\navailableCakesNumber = 1\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u0430 (\u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e) \u0434\u0435\u0442\u0438 \u0440\u0435\u0430\u043b\u044c\u043d\u043e \u043c\u043e\u0433\u0443\u0442 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c?\nnewMaxRequest = 1 \/ 3.5 =~ 28%<\/code><\/pre>\n<p>\nConform calculului, cei trei copii vor primi c\u00e2te 28% dintr-un nucleu, \u0219i nu un nucleu \u00eentreg. Al patrulea copil va primi 14% dintr-un nucleu complet, \u0219i nu jum\u0103tate. Dar totul va fi diferit dac\u0103 ave\u021bi un sistem multicore.<\/p>\n<p><img decoding=\"async\" alt=\"Cum s\u0103 ob\u021bii acces la resursele Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/7bf71d97add9adcf7cf0260941526590.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCererea CPU \u2014 sistem multicore (4)<\/p>\n<p>\u00cen imaginea de mai sus, se vede c\u0103 trei copii vor fiecare o pl\u0103cint\u0103 \u00eentreag\u0103, iar unul \u2014 o jum\u0103tate. Deoarece mama a f\u0103cut patru pl\u0103cinte, fiecare dintre copiii ei va primi tot ce dore\u0219te. \u00centr-un sistem multicore, resursele procesorului sunt distribuite \u00eentre toate nucleele disponibile. Dac\u0103 un container este limitat la mai pu\u021bin de un nucleu complet de CPU, tot poate folosi 100% din acesta. <\/p>\n<p>Calculurile de mai sus sunt simplificate pentru a \u00een\u021belege cum se distribuie CPU-ul \u00eentre containere. Desigur, pe l\u00e2ng\u0103 containere, exist\u0103 \u0219i alte procese care folosesc resursele CPU. Atunci c\u00e2nd procesele dintr-un container sunt inactive, altele pot folosi resursele acestuia. <code>CPU: \"200m\"<\/code> corespunde <code>CPU: 0,2<\/code>, ceea ce \u00eenseamn\u0103 aproximativ 20% dintr-un nucleu.<\/p>\n<p>Acum s\u0103 discut\u0103m despre <code>limit.cpu<\/code>. CPU-ul, care limiteaz\u0103 Kubernetes, este \u00eenmul\u021bit cu 100. Rezultatul este cantitatea de timp pe care containerul o poate folosi la fiecare 100 \u00b5s (<code>cpu-period<\/code>). <\/p>\n<p><code>limit.cpu<\/code> corespunde flag-ului Docker <code>--cpus<\/code>. Aceasta reprezint\u0103 o nou\u0103 combina\u021bie a vechilor <code>--cpu-period<\/code> \u0219i <code>--cpu-quota<\/code>. Stabilindu-l, indic\u0103m c\u00e2t din resursele CPU poate folosi containerul p\u00e2n\u0103 nu \u00eencepe restric\u021bionarea:<\/p>\n<ul>\n<li><strong>cpus<\/strong> \u2014 combina\u021bia <code>cpu-period<\/code> \u0219i <code>cpu-quota. cpus = 1.5<\/code> echivaleaz\u0103 cu setarea <code>cpu-period = 100000<\/code> \u0219i <code>cpu-quota = 150000<\/code>;<\/li>\n<li><strong>cpu-period<\/strong> \u2014 perioada <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Completely_Fair_Scheduler\">planificatorului CPU CFS<\/a><\/noindex>, implicit 100 microsecunde;<\/li>\n<li><strong>cpu-quota<\/strong> \u2014 num\u0103rul de microsecunde \u00een cadrul <code>cpu-period<\/code>, la care este limitat containerul.<\/li>\n<\/ul>\n<p>\n<strong>Ce se va \u00eent\u00e2mpla dac\u0103 se stabile\u0219te un CPU insuficient solicitat?<\/strong><\/p>\n<p>Dac\u0103 containerului \u00eei este necesar mai mult dec\u00e2t este alocat, va fura CPU de la alte procese.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 se stabile\u0219te un limit\u0103 insuficient\u0103 de CPU?<\/strong><\/p>\n<p>Deoarece resursa CPU este reglementat\u0103, se va activa throttling-ul.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 nu se specific\u0103 solicitarea de CPU?<\/strong><\/p>\n<p>La fel ca \u00een cazul memoriei, valoarea solicit\u0103rii este egal\u0103 cu limita.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 nu se specific\u0103 limita de CPU?<\/strong><\/p>\n<p>Containerul va folosi c\u00e2t CPU are nevoie. Dac\u0103 \u00een spa\u021biul de nume este definit\u0103 o politic\u0103 de CPU implicit\u0103 (LimitRange), atunci aceast\u0103 limit\u0103 va fi folosit\u0103 \u0219i pentru container.<\/p>\n<p><strong>Ce se va \u00eent\u00e2mpla dac\u0103 nu se specific\u0103 nici solicitarea, nici limita de CPU?<\/strong><\/p>\n<p>La fel ca \u00een cazul memoriei, acesta este cel mai r\u0103u scenariu. Planificatorul nu \u0219tie c\u00e2te resurse are nevoie containerul t\u0103u, iar aceasta poate provoca probleme serioase pe nod. Pentru a evita acest lucru, trebuie s\u0103 se stabileasc\u0103 limitele implicite pentru spa\u021biile de nume (LimitRange).<\/p>\n<p>Aminti\u021bi-v\u0103: dac\u0103 solicita\u021bi mai mult CPU dec\u00e2t pot oferi nodurile, pod-ul nu va fi planificat. <code>Requests.cpu<\/code> \u2014 nu o valoare minim\u0103, ci o valoare suficient\u0103 pentru a porni pod-ul \u0219i a func\u021biona f\u0103r\u0103 erori. Dac\u0103 aplica\u021bia nu efectueaz\u0103 calcule complexe, cea mai bun\u0103 op\u021biune este s\u0103 stabili\u021bi <code>request.cpu &lt;= 1<\/code> \u0219i s\u0103 lansa\u021bi at\u00e2tea replici c\u00e2te sunt necesare.<\/p>\n<h2>Cantitatea ideal\u0103 de resurse solicitate sau limitate<\/h2>\n<p>\nAm \u00eenv\u0103\u021bat despre limitarea resurselor computa\u021bionale. Acum este timpul s\u0103 r\u0103spundem la \u00eentrebarea: \"C\u00e2te resurse necesit\u0103 pod-ul meu pentru a rula aplica\u021bia f\u0103r\u0103 probleme? Ce cantitate este ideal\u0103?\". <\/p>\n<p>Din p\u0103cate, nu exist\u0103 r\u0103spunsuri clare la aceste \u00eentreb\u0103ri. Dac\u0103 nu \u0219ti\u021bi cum func\u021bioneaz\u0103 aplica\u021bia dumneavoastr\u0103, c\u00e2te CPU sau memorie \u00eei sunt necesare, cea mai bun\u0103 op\u021biune este s\u0103 \u00eei oferi\u021bi multe resurse de memorie \u0219i CPU \u0219i apoi s\u0103 rula\u021bi teste de performan\u021b\u0103.<\/p>\n<p>\u00cen plus fa\u021b\u0103 de teste de performan\u021b\u0103, observa\u021bi comportamentul aplica\u021biei \u00een monitorizare timp de o s\u0103pt\u0103m\u00e2n\u0103. Dac\u0103 din grafice reiese c\u0103 aplica\u021bia dumneavoastr\u0103 consum\u0103 mai pu\u021bine resurse dec\u00e2t a\u021bi solicitat, atunci pute\u021bi reduce cantitatea de CPU sau memorie solicitat\u0103.<\/p>\n<p>Ca exemplu, consulta\u021bi acest <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/grafana\/dashboards\/7187\">dashboard Grafana<\/a><\/noindex>. Acesta afi\u0219eaz\u0103 diferen\u021ba dintre resursele solicitate sau limita de resurse \u0219i utilizarea actual\u0103 a resurselor.<\/p>\n<h2>Concluzie<\/h2>\n<p>\nCererea \u0219i limitarea resurselor ajut\u0103 la men\u021binerea func\u021bion\u0103rii clusterei Kubernetes. O configura\u021bie corect\u0103 a limitelor minimizeaz\u0103 costurile \u0219i men\u021bine constant aplica\u021biile func\u021bionale.<\/p>\n<p>Pe scurt, trebuie s\u0103 avem \u00een vedere c\u00e2teva aspecte:<\/p>\n<ol>\n<li>Resursele solicitate reprezint\u0103 configura\u021bia luat\u0103 \u00een considerare \u00een timpul lans\u0103rii (c\u00e2nd Kubernetes planific\u0103 plasarea aplica\u021biei). \u00cen schimb, limitarea resurselor este important\u0103 \u00een timpul func\u021bion\u0103rii \u2014 c\u00e2nd aplica\u021bia este deja lansat\u0103 pe nod.<\/li>\n<li>Spre deosebire de memorie, CPU este o resurs\u0103 reglementat\u0103. \u00cen cazul unei insuficien\u021be de CPU, Pod-ul t\u0103u nu se va opri, ci va activa mecanismul de throttling.<\/li>\n<li>Resursele solicitate \u0219i limita de resurse nu reprezint\u0103 valori minime \u0219i maxime! Stabilind resursele solicitate, te asiguri c\u0103 aplica\u021bia va func\u021biona f\u0103r\u0103 probleme.<\/li>\n<li>O practic\u0103 bun\u0103 este s\u0103 setezi cererea de memorie egal\u0103 cu limita de memorie.<\/li>\n<li>Este bine s\u0103 setezi resursa solicitat\u0103 <code>CPU &lt;=1<\/code>, dac\u0103 aplica\u021bia nu efectueaz\u0103 calcule complexe.<\/li>\n<li>Dac\u0103 solici\u021bi mai multe resurse dec\u00e2t sunt disponibile pe nod, Pod-ul nu va fi niciodat\u0103 programat pe acest nod.<\/li>\n<li>Pentru a determina cantitatea corect\u0103 de resurse solicitate\/limite de resurse, folose\u0219te testarea de \u00eenc\u0103rcare \u0219i monitorizarea.<\/li>\n<\/ol>\n<p>\nSper c\u0103 acest articol te va ajuta s\u0103 \u00een\u021belegi conceptul de baz\u0103 al limit\u0103rii resurselor. \u0218i c\u0103 vei putea aplica aceste cuno\u0219tin\u021be \u00een munca ta.<\/p>\n<p>Good luck!<\/p>\n<p><strong>Ce altceva s\u0103 cite\u0219ti:<\/strong><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/500504\/\">Observabilitatea SRE: spa\u021bii de nume \u0219i structura metricilor<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/blog\/poleznye-instrumenty-dlya-kubernetes\">90+ instrumente utile pentru Kubernetes: desf\u0103\u0219urare, gestionare, monitorizare, securitate \u0219i altele<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tele.click\/k8s_mail\">Our Around Kubernetes channel on Telegram<\/a><\/noindex>.<\/li>\n<\/ol>\n<p>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/516014\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>The Reward by Tohad \u0412 \u043d\u0430\u0447\u0430\u043b\u0435 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 Kubernetes \u043e\u0431\u044b\u0447\u043d\u043e \u0437\u0430\u0431\u044b\u0432\u0430\u044e\u0442 \u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0435 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432. \u041d\u0430 \u044d\u0442\u043e\u043c \u044d\u0442\u0430\u043f\u0435 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u0440\u0430\u0437 Docker \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0438 \u0435\u0433\u043e \u043c\u043e\u0436\u043d\u043e \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u041d\u043e \u043f\u043e\u0437\u0434\u043d\u0435\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u043c\u0438. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043d\u0443\u0436\u043d\u043e \u0432\u044b\u0434\u0435\u043b\u0438\u0442\u044c \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u0434\u043b\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0438 \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94263,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94262","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.2.1 - aioseo.com -->\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\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\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\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\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-09-14T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-14T17:42:34+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\udd47Cum s\u0103 accesezi resursele Kubernetes Pod | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","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\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","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-09-14T17:42:34+00:00","article:modified_time":"2020-09-14T17:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94262","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 11:30:27","updated":"2022-10-02 18:20:09","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\/94262","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=94262"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/94262\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/94263"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=94262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=94262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=94262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}