{"id":55712,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat"},"modified":"2020-02-18T14:03:51","modified_gmt":"2020-02-18T11:03:51","slug":"tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","title":{"rendered":"Trei niveluri de autoscalare \u00een Kubernetes: cum s\u0103 le folose\u0219ti eficient","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Trei niveluri de autoscalare \u00een Kubernetes: cum s\u0103 le folose\u0219ti eficient\" src=\"\/wp-content\/uploads\/2020\/01\/0b076d65db116cabdd1b4ae380d3777d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPentru o st\u0103p\u00e2nire complet\u0103 a Kubernetes, este necesar s\u0103 cunoa\u0219tem diverse metode de scalare a resurselor clusterului: dup\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/speakerdeck.com\/thockin\/everything-you-ever-wanted-to-know-about-resource-scheduling-dot-dot-dot-almost\">cuvintele dezvoltatorilor sistemului<\/a><\/noindex>, aceasta este una dintre principalele sarcini ale Kubernetes. Am preg\u0103tit un rezumat la nivel \u00eenalt al mecanismelor de autoscalare orizontal\u0103 \u0219i vertical\u0103 \u0219i al redimension\u0103rii clusterelor, precum \u0219i recomand\u0103ri despre cum s\u0103 le utiliz\u0103m eficient.<\/p>\n<p>Articolul <noindex><a rel=\"nofollow\" href=\"https:\/\/www.magalix.com\/blog\/kubernetes-autoscaling-101\">Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler, and Vertical Pod Autoscaler<\/a><\/noindex> a fost tradus de echipa care a implementat autoscalarea \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/containers\/\">Kubernetes aaS de la Mail.ru<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>De ce este important s\u0103 ne g\u00e2ndim la scalare <\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/blog\/kubernetes-for-much-stuff\">Kubernetes<\/a><\/noindex> \u2014 un instrument pentru gestionarea resurselor \u0219i orchestrare. Desigur, este bine s\u0103 experiment\u0103m cu func\u021biile interesante de implementare, monitorizare \u0219i gestionare a pod-urilor (modulul pod \u2014 un grup de containere care sunt lansate ca r\u0103spuns la o cerere). <\/p>\n<p>Cu toate acestea, trebuie s\u0103 ne g\u00e2ndim \u0219i la urm\u0103toarele \u00eentreb\u0103ri:<\/p>\n<ol>\n<li>Cum se scalazeaz\u0103 modulele \u0219i aplica\u021biile?\n<\/li>\n<li>Cum se men\u021bin containerele \u00een stare operativ\u0103 \u0219i eficient\u0103?\n<\/li>\n<li>Cum se r\u0103spunde la schimb\u0103rile constante din cod \u0219i la sarcinile de lucru ale utilizatorilor?\n<\/li>\n<\/ol>\n<p>\nConfigurarea clusterelor Kubernetes pentru echilibrarea resurselor \u0219i a performan\u021bei poate fi o sarcin\u0103 complex\u0103, necesit\u00e2nd cuno\u0219tin\u021be experte despre func\u021bionarea intern\u0103 a Kubernetes. Sarcina de lucru a aplica\u021biei sau serviciilor dumneavoastr\u0103 poate fluctua pe parcursul zilei sau chiar \u00eentr-o singur\u0103 or\u0103, a\u0219a c\u0103 echilibrarea ar trebui considerat\u0103 un proces continuu.<\/p>\n<h2>Nivelurile de autoscalare Kubernetes<\/h2>\n<p>\nAutoscalarea eficient\u0103 necesit\u0103 coordonare \u00eentre dou\u0103 niveluri: <\/p>\n<ol>\n<li>Nivelul de poduri, care include scalarea orizontal\u0103 (Horizontal Pod Autoscaler, HPA) \u0219i scalarea vertical\u0103 (Vertical Pod Autoscaler, VPA). Aceasta implic\u0103 dimensionarea resurselor existente pentru containerele tale.\n<\/li>\n<li>Nivelul clusterului, gestionat de sistemul de autoscalare a clusterului (Cluster Autoscaler, CA), care cre\u0219te sau scade num\u0103rul de noduri din interiorul clusterului.\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Modulul de autoscalare orizontal\u0103 (HPA)<\/h2>\n<p>\nA\u0219a cum sugereaz\u0103 numele, HPA scalaz\u0103 num\u0103rul de replici ale podurilor. Ca trigeri pentru modificarea num\u0103rului de replici, majoritatea DevOps-urilor folosesc \u00eenc\u0103rcarea pe procesor \u0219i memorie. Cu toate acestea, sistemul poate fi scalat pe baza <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/#support-for-custom-metrics\">metricilor personalizate<\/a><\/noindex>, combina\u021bia lor <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/tasks\/run-application\/horizontal-pod-autoscale\/#support-for-multiple-metrics\">metricilor externe<\/a><\/noindex> sau chiar <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/kubernetes-engine\/docs\/tutorials\/external-metrics-autoscaling\">Schema de func\u021bionare la nivel \u00eenalt a HPA:<\/a><\/noindex>.<\/p>\n<p>Schema de func\u021bionare de nivel \u00eenalt HPA:<\/p>\n<ol>\n<li>HPA verific\u0103 \u00een mod constant valorile metricale specificate la instalare, cu un interval implicit de 30 de secunde.\n<\/li>\n<li>HPA \u00eencearc\u0103 s\u0103 creasc\u0103 num\u0103rul de module dac\u0103 pragul specificat este atins.\n<\/li>\n<li>HPA actualizeaz\u0103 num\u0103rul de replici \u00een cadrul controlerului de desf\u0103\u0219urare\/relicare.\n<\/li>\n<li>Controlerul de desf\u0103\u0219urare\/relicare desf\u0103\u0219oar\u0103 apoi toate modulele suplimentare necesare.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Trei niveluri de autoscalare \u00een Kubernetes: cum s\u0103 le folose\u0219ti eficient\" src=\"\/wp-content\/uploads\/2020\/01\/e98534431712eb3303668446b0fe567b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>HPA ini\u021biaz\u0103 procesul de desf\u0103\u0219urare a modulelor c\u00e2nd se atinge valoarea prag.<\/i><\/p>\n<p>C\u00e2nd folosi\u021bi HPA, lua\u021bi \u00een considerare urm\u0103toarele:<\/p>\n<ul>\n<li>Intervalul de verificare implicit al HPA este de 30 de secunde. Acesta se stabile\u0219te printr-un flag. <i>horizontal-pod-autoscaler-sync-period<\/i> \u00een managerul de controlere.\n<\/li>\n<li>Precizia relativ\u0103 implicit\u0103 este de 10%.\n<\/li>\n<li>Dup\u0103 ultima cre\u0219tere a num\u0103rului de module, HPA a\u0219teapt\u0103 stabilizarea metricelor timp de trei minute. Acest interval se stabile\u0219te printr-un flag. <i>horizontal-pod-autoscaler-upscale-delay<\/i>.\n<\/li>\n<li>Dup\u0103 ultima sc\u0103dere a num\u0103rului de module, HPA a\u0219teapt\u0103 stabilizarea timp de cinci minute. Acest interval se stabile\u0219te printr-un flag. <i>horizontal-pod-autoscaler-downscale-delay<\/i>.\n<\/li>\n<li>HPA func\u021bioneaz\u0103 cel mai bine cu obiecte de desf\u0103\u0219urare, nu cu controlere de replicare. Scalarea automat\u0103 orizontal\u0103 nu este compatibil\u0103 cu actualizarea secven\u021bial\u0103 (rolling update), care manipuleaz\u0103 direct controlerele de replicare. La desf\u0103\u0219urare, num\u0103rul de replici depinde direct de obiectele de desf\u0103\u0219urare.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Scalarea vertical\u0103 a podurilor<\/h2>\n<p>\nScalarea vertical\u0103 (VPA) aloc\u0103 mai mult (sau mai pu\u021bin) timp pe procesor sau memorie pentru podurile existente. Este potrivit\u0103 pentru podurile cu stare (stateful) sau f\u0103r\u0103 (stateless), dar este \u00een principal destinat\u0103 serviciilor stateful. Totu\u0219i, po\u021bi aplica VPA \u0219i pentru module f\u0103r\u0103 stare, dac\u0103 este necesar s\u0103 ajustezi automat cantitatea de resurse alocate ini\u021bial. <\/p>\n<p>VPA r\u0103spunde, de asemenea, la evenimentele OOM (out of memory, lips\u0103 de memorie). Pentru a modifica timpul procesorului \u0219i volumul memoriei, este necesar\u0103 repornirea podurilor. Atunci c\u00e2nd reporne\u0219te, VPA respect\u0103 bugetul de alocare (<noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/disruptions\/\">pods distribution budget, PDB<\/a><\/noindex>), pentru a garanta num\u0103rul minim necesar de module. <\/p>\n<p>Pute\u021bi stabili o capacitate minim\u0103 \u0219i maxim\u0103 de resurse pentru fiecare modul. Astfel, pute\u021bi limita capacitatea maxim\u0103 de memorie alocat\u0103 la 8 GB. Acest lucru este util, dac\u0103 nodurile actuale nu pot aloca mai mult de 8 GB de memorie pe container. Specifica\u021bii detaliate \u0219i mecanismul de func\u021bionare sunt descrise \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/community\/blob\/master\/contributors\/design-proposals\/autoscaling\/vertical-pod-autoscaler.md\">wiki-ul oficial VPA<\/a><\/noindex>.<\/p>\n<p>\u00cen plus, VPA dispune de o func\u021bie interesant\u0103 de recomand\u0103ri (VPA Recommender). Aceasta urm\u0103re\u0219te utilizarea resurselor \u0219i evenimentele OOM ale tuturor modulelor, pentru a sugera noi valori pentru memorie \u0219i timp de procesare, baz\u00e2ndu-se pe un algoritm inteligent care ia \u00een considerare metricile istorice. De asemenea, exist\u0103 o interfa\u021b\u0103 API care prime\u0219te descriptorul pod-ului \u0219i returneaz\u0103 valorile de resurse recomandate.<\/p>\n<p>Este important de men\u021bionat c\u0103 VPA Recommender nu urm\u0103re\u0219te \"limita\" resurselor. Acest lucru poate duce la monopolizarea resurselor de c\u0103tre un modul \u00een interiorul nodurilor. Este mai bine s\u0103 stabili\u021bi o limit\u0103 la nivel de spa\u021biu de nume pentru a evita un consum excesiv de memorie sau timp de procesare.<\/p>\n<p>Schema de func\u021bionare la un nivel \u00eenalt a VPA:<\/p>\n<ol>\n<li>VPA verific\u0103 continuu valorile metricilor specificate la instalare, cu un interval implicit de 10 secunde.\n<\/li>\n<li>Dac\u0103 se atinge pragul stabilit, VPA \u00eencearc\u0103 s\u0103 modifice cantitatea de resurse alocate.\n<\/li>\n<li>VPA actualizeaz\u0103 cantitatea de resurse \u00een cadrul controller-ului de implementare\/replicare.\n<\/li>\n<li>La repornirea modulelor, toate noile resurse se aplic\u0103 instan\u021belor create.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Trei niveluri de autoscalare \u00een Kubernetes: cum s\u0103 le folose\u0219ti eficient\" src=\"\/wp-content\/uploads\/2020\/01\/324702d5e36e9fcf45ced8b3f276db52.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>VPA adaug\u0103 cantitatea necesar\u0103 de resurse <\/i><\/p>\n<p>\u021aine\u021bi cont de urm\u0103toarele aspecte atunci c\u00e2nd utiliza\u021bi VPA:<\/p>\n<ul>\n<li>Scalarea necesit\u0103 repornirea obligatorie a podului. Acest lucru este necesar pentru a evita func\u021bionarea instabil\u0103 dup\u0103 efectuarea modific\u0103rilor. Pentru fiabilitate, modulele sunt repornite \u0219i distribuite \u00eentre noduri pe baza noilor resurse alocate.\n<\/li>\n<li>VPA \u0219i HPA nu sunt \u00eenc\u0103 compatibile \u00eentre ele \u0219i nu pot func\u021biona pe acelea\u0219i poduri. Dac\u0103 aplici ambele mecanisme de scalare \u00eentr-un singur cluster, asigur\u0103-te c\u0103 set\u0103rile nu le permit s\u0103 se activeze pe acelea\u0219i obiecte.\n<\/li>\n<li>VPA configureaz\u0103 cererile containerelor pentru resurse, baz\u00e2ndu-se doar pe utilizarea lor anterioar\u0103 \u0219i actual\u0103. Nu stabilesc limite de utilizare a resurselor. Pot ap\u0103rea probleme cu func\u021bionarea incorect\u0103 a aplica\u021biilor care vor \u00eencepe s\u0103 consume tot mai multe resurse, ceea ce va duce la deconectarea acestui pod de c\u0103tre Kubernetes.\n<\/li>\n<li>VPA este \u00eenc\u0103 \u00eentr-o etap\u0103 timpurie de dezvoltare. Fi\u021bi preg\u0103ti\u021bi c\u0103 \u00een cur\u00e2nd sistemul poate suferi unele modific\u0103ri. Pute\u021bi citi despre <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/autoscaler\/tree\/master\/vertical-pod-autoscaler#known-limitations-of-the-alpha-version\">limit\u0103rile cunoscute<\/a><\/noindex> \u0219i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/community\/blob\/master\/contributors\/design-proposals\/autoscaling\/vertical-pod-autoscaler.md#future-work\">planurile de dezvoltare<\/a><\/noindex>. Astfel, exist\u0103 planuri de implementare a colabor\u0103rii \u00eentre VPA \u0219i HPA, precum \u0219i desf\u0103\u0219urarea modulelor \u00eempreun\u0103 cu o politic\u0103 de scalare vertical\u0103 pentru acestea (de exemplu, o etichet\u0103 special\u0103 'requires VPA').\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Scalarea automat\u0103 a clusterului Kubernetes<\/h2>\n<p>\nScalarea automat\u0103 a clusterului (Cluster Autoscaler, CA) modific\u0103 num\u0103rul de noduri \u00een func\u021bie de num\u0103rul de module pod \u00een a\u0219teptare. Sistemul verific\u0103 periodic existen\u021ba modulelor \u00een a\u0219teptare \u0219i cre\u0219te dimensiunea clusterului dac\u0103 sunt necesare mai multe resurse \u0219i dac\u0103 clusterul respect\u0103 limitele stabilite. CA interac\u021bioneaz\u0103 cu furnizorul de servicii cloud, solicit\u00e2nd noduri suplimentare sau eliber\u00e2ndu-le pe cele inactive. Prima versiune public\u0103 a CA a fost lansat\u0103 \u00een Kubernetes 1.8.<\/p>\n<p>Schema de func\u021bionare la nivel \u00eenalt a CA:<\/p>\n<ol>\n<li>CA verific\u0103 existen\u021ba modulelor \u00een stare de a\u0219teptare la un interval implicit de 10 secunde.\n<\/li>\n<li>Dac\u0103 unul sau mai multe module sunt \u00een a\u0219teptare deoarece nu sunt suficiente resurse disponibile \u00een cluster pentru a le aloca, \u00eencearc\u0103 s\u0103 preg\u0103teasc\u0103 unul sau mai multe noduri suplimentare.\n<\/li>\n<li>C\u00e2nd furnizorul de servicii cloud aloc\u0103 nodul necesar, acesta se al\u0103tur\u0103 clusterului \u0219i este gata s\u0103 serveasc\u0103 modulele pod.\n<\/li>\n<li>Planificatorul Kubernetes aloc\u0103 modulele \u00een a\u0219teptare pe un nou nod. Dac\u0103 dup\u0103 aceasta unele module r\u0103m\u00e2n \u00een continuare \u00een a\u0219teptare, procesul se repet\u0103 - iar noduri noi sunt ad\u0103ugate \u00een cluster.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Trei niveluri de autoscalare \u00een Kubernetes: cum s\u0103 le folose\u0219ti eficient\" src=\"\/wp-content\/uploads\/2020\/01\/2cd3c97f5d1b040b813940a4e804365e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Alocarea automat\u0103 a nodurilor \u00een cluster \u00een cloud<\/i><\/p>\n<p>Lua\u021bi \u00een considerare urm\u0103toarele atunci c\u00e2nd utiliza\u021bi CA:<\/p>\n<ul>\n<li>CA garanteaz\u0103 c\u0103 toate modulele din cluster au loc pentru a rula, indiferent de nivelul de \u00eenc\u0103rcare a procesorului. \u00cen plus, acesta \u00eencearc\u0103 s\u0103 garanteze c\u0103 \u00een cluster nu exist\u0103 noduri inutile.\n<\/li>\n<li>CA \u00eenregistreaz\u0103 necesitatea de scalare la aproximativ 30 de secunde.\n<\/li>\n<li>Dup\u0103 ce un nod devine inutil, CA a\u0219teapt\u0103 \u00een mod implicit 10 minute \u00eenainte de a scala sistemul.\n<\/li>\n<li>\u00cen sistemul de autoscalare exist\u0103 conceptul de extensori (expanders). Acestea sunt diferite strategii pentru a alege grupul de noduri \u00een care vor fi ad\u0103ugate noi.\n<\/li>\n<li>Aplica\u021bi \u00een mod responsabil op\u021biunea <i>cluster-autoscaler.kubernetes.io\/safe-to-evict (true)<\/i>. Dac\u0103 instalezi multe poduri sau dac\u0103 multe dintre ele sunt distribuite pe toate nodurile, vei pierde \u00een mare m\u0103sur\u0103 capacitatea de a reduce dimensiunea clusterului.\n<\/li>\n<li>Windows VPS pentru lucru la distan\u021b\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/pods\/disruptions\/\">PodDisruptionBudgets<\/a><\/noindex>, pentru a preveni \u0219tergerea podurilor, ceea ce ar putea face ca o parte din aplica\u021bia ta s\u0103 e\u0219ueze complet.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Cum interac\u021bioneaz\u0103 sistemele de autoscalare Kubernetes \u00eentre ele<\/h2>\n<p>\nPentru o armonie perfect\u0103, ar trebui s\u0103 aplici scalarea automat\u0103 at\u00e2t la nivelul podurilor (HPA\/VPA), c\u00e2t \u0219i la nivelul clusterului. Acestea interac\u021bioneaz\u0103 relativ u\u0219or \u00eentre ele:<\/p>\n<ol>\n<li>HPA sau VPA actualizeaz\u0103 replicile pod-urilor sau resursele alocate pentru pod-urile existente.\n<\/li>\n<li>Dac\u0103 nu sunt suficiente noduri pentru scalarea planificat\u0103, CA observ\u0103 prezen\u021ba pod-urilor \u00een a\u0219teptare.\n<\/li>\n<li>CA aloc\u0103 noduri noi.\n<\/li>\n<li>Modulele sunt distribuite pe noduri noi.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Trei niveluri de autoscalare \u00een Kubernetes: cum s\u0103 le folose\u0219ti eficient\" src=\"\/wp-content\/uploads\/2020\/01\/09379f30f349a235bb26a670ad0d0bfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Un sistem comun de scale \u00een sistemele Kubernetes<\/i><\/p>\n<h2>Erori tipice \u00een autoscalarea Kubernetes<\/h2>\n<p>\nExist\u0103 c\u00e2teva probleme tipice cu care se confrunt\u0103 DevOps atunci c\u00e2nd \u00eencearc\u0103 s\u0103 aplice autoscalarea.<\/p>\n<p>HPA \u0219i VPA depind de metrici \u0219i de anumite date istorice. Dac\u0103 resursele alocate sunt insuficiente, modulele vor fi restr\u00e2nse \u0219i nu vor putea genera metrici. \u00cen acest caz, autoscalarea nu va avea loc niciodat\u0103.<\/p>\n<p>Opera\u021biunea de scalare este sensibil\u0103 la timp. Ne dorim ca modulele \u0219i clusterul s\u0103 se scaleze rapid \u2014 \u00eenainte ca utilizatorii s\u0103 observe probleme \u0219i defec\u021biuni. De aceea, trebuie s\u0103 lu\u0103m \u00een considerare timpul mediu de scalare a pod-urilor \u0219i a clusterului.<\/p>\n<p>Scenariul ideal \u2014 4 minute:<\/p>\n<ol>\n<li>30 de secunde. Actualizarea metricilor \u021bint\u0103: 30-60 de secunde.\n<\/li>\n<li>30 de secunde. HPA verific\u0103 valorile metricilor: 30 de secunde.\n<\/li>\n<li>Mai pu\u021bin de 2 secunde. Modulele pod sunt create \u0219i trec \u00een stare de a\u0219teptare: 1 secund\u0103.\n<\/li>\n<li>Mai pu\u021bin de 2 secunde. CA vede modulele \u00een a\u0219teptare \u0219i trimite apeluri pentru preg\u0103tirea nodurilor: 1 secund\u0103.\n<\/li>\n<li>3 minute. Providerul de cloud aloc\u0103 noduri. K8s a\u0219teapt\u0103 p\u00e2n\u0103 c\u00e2nd acestea sunt gata: p\u00e2n\u0103 la 10 minute (depinde de mai mul\u021bi factori).\n<\/li>\n<\/ol>\n<p>\nCel mai r\u0103u (mai realist) scenariu \u2014 12 minute:<\/p>\n<ol>\n<li>30 de secunde. Actualizarea metricilor \u021bint\u0103.\n<\/li>\n<li>30 de secunde. HPA verific\u0103 valorile metricalor.\n<\/li>\n<li>Mai pu\u021bin de 2 secunde. Modulele pod sunt create \u0219i trec \u00een stare de a\u0219teptare.\n<\/li>\n<li>Mai pu\u021bin de 2 secunde. CA vede modulele \u00een a\u0219teptare \u0219i trimite solicit\u0103ri pentru preg\u0103tirea nodurilor.\n<\/li>\n<li>10 minute. Providerul de cloud aloc\u0103 noduri. K8s a\u0219teapt\u0103 p\u00e2n\u0103 c\u00e2nd acestea sunt gata. Timpul de a\u0219teptare depinde de mai mul\u021bi factori, cum ar fi \u00eent\u00e2rzierea providerului, \u00eent\u00e2rzierea OS, activitatea instrumentelor auxiliare.\n<\/li>\n<\/ol>\n<p>\nNu confunda\u021bi mecanismele de scalare ale furnizorilor de cloud cu CA noastr\u0103. Ultima func\u021bioneaz\u0103 \u00een interiorul clusterului Kubernetes, \u00een timp ce mecanismul furnizorului de cloud se bazeaz\u0103 pe distribu\u021bia nodurilor. Acesta nu \u0219tie ce se \u00eent\u00e2mpl\u0103 cu pod-urile sau aplica\u021bia dumneavoastr\u0103. Aceste sisteme func\u021bioneaz\u0103 \u00een paralel. <\/p>\n<h2>Cum s\u0103 gestiona\u021bi scalarea \u00een Kubernetes<\/h2>\n<p><\/p>\n<ol>\n<li>Kubernetes este un instrument de gestionare a resurselor \u0219i orchestrare. Opera\u021biunile de gestionare a pod-urilor \u0219i resurselor clusterului sunt etape esen\u021biale \u00een \u00eenv\u0103\u021barea Kubernetes.\n<\/li>\n<li>\u00cen\u021belege\u021bi logica scalabilit\u0103\u021bii pod-urilor lu\u00e2nd \u00een considerare HPA \u0219i VPA.\n<\/li>\n<li>CA ar trebui utilizat doar dac\u0103 \u00een\u021belege\u021bi bine nevoile pod-urilor \u0219i containerelor dumneavoastr\u0103.\n<\/li>\n<li>Pentru o configurare optim\u0103 a clusterului, trebuie s\u0103 \u00een\u021belege\u021bi cum func\u021bioneaz\u0103 \u00eempreun\u0103 diferitele sisteme de scalare.\n<\/li>\n<li>Atunci c\u00e2nd evalua\u021bi timpul de scalare, ave\u021bi \u00een vedere cele mai rele \u0219i cele mai bune scenarii.\n<\/li>\n<\/ol>\n<p>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/484344\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e \u043e\u0441\u0432\u043e\u0435\u043d\u0438\u044f Kubernetes \u043d\u0443\u0436\u043d\u043e \u0437\u043d\u0430\u0442\u044c \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0441\u043f\u043e\u0441\u043e\u0431\u044b \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043d\u044b\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432: \u043f\u043e \u0441\u043b\u043e\u0432\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u044d\u0442\u043e \u043e\u0434\u043d\u0430 \u0438\u0437 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0437\u0430\u0434\u0430\u0447 Kubernetes. \u041c\u044b \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0443\u0440\u043e\u0432\u043d\u0435\u0432\u044b\u0439 \u043e\u0431\u0437\u043e\u0440 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u043e\u0432 \u0433\u043e\u0440\u0438\u0437\u043e\u043d\u0442\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u0438 \u0432\u0435\u0440\u0442\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u0430\u0432\u0442\u043e\u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0440\u0430\u0437\u043c\u0435\u0440\u0430 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0438, \u043a\u0430\u043a \u0438\u0445 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c. \u0421\u0442\u0430\u0442\u044c\u044e Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler, and Vertical Pod Autoscaler \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55712","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e.\" \/>\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\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat\" \/>\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\u0422\u0440\u0438 \u0443\u0440\u043e\u0432\u043d\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes: \u043a\u0430\u043a \u0438\u0445 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat\" \/>\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-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:51+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\udd47 Trei niveluri de auto-scalare \u00een Kubernetes: cum s\u0103 le utiliza\u021bi eficient | ProHoster","description":"Pentru completare.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","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\u0422\u0440\u0438 \u0443\u0440\u043e\u0432\u043d\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes: \u043a\u0430\u043a \u0438\u0445 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c | ProHoster","og:description":"\u0414\u043b\u044f \u043f\u043e\u043b\u043d\u043e\u0433\u043e.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/tri-urovnya-avtomasshtabirovaniya-v-kubernetes-kak-ih-effektivno-ispolzovat","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-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55712","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 19:38:31","updated":"2022-09-29 14:33:55","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\/55712","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=55712"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/55712\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=55712"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=55712"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=55712"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}