{"id":56259,"date":"2020-02-08T00:00:00","date_gmt":"2020-02-07T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih"},"modified":"2020-02-18T14:04:30","modified_gmt":"2020-02-18T11:04:30","slug":"rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Noduri de lucru Kubernetes: multe mici sau c\u00e2teva mari?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Noduri
\nAt the creation of a Kubernetes cluster, questions may arise: how many worker nodes to configure and what types? What is better for an on-premise cluster: to buy several powerful servers or to use a dozen old machines in your data center? And in the cloud, is it better to take eight single-core or two quad-core instances? <\/p>\n

The answers to these questions are in the article by Daniel Weibel, a software engineer and instructor for the training project Learnk8s<\/a><\/noindex> translated by the team Kubernetes aaS de la Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Cluster capacity<\/h2>\n

\nIn general, a Kubernetes cluster can be viewed as a large \"super node.\" Its total computational power is the sum of the capabilities of all its constituent nodes. <\/p>\n

There are several ways to achieve the desired target capacity of the cluster. For example, we need a cluster with a total capacity of 8 CPU cores and 32 GB of RAM because the application set requires that many resources. Then we can install two nodes with 16 GB of memory or four nodes with 8 GB of memory, two quad-core processors or four dual-core ones.<\/p>\n

Here are just two possible ways to create a cluster:<\/p>\n

\"Noduri
\nBoth options yield a cluster with the same capacity, but in the bottom configuration, there are four smaller nodes, while in the top configuration, there are two larger ones. <\/p>\n

Which option is better?<\/h3>\n

\nTo answer this question, let\u2019s consider the advantages of both options. We summarized them in a table.<\/p>\n

Several large nodes<\/p>\n

Many small nodes<\/p>\n

Simpler cluster management (if on-premise)<\/p>\n

Smooth auto-scaling<\/p>\n

Cheaper (if on-premise) <\/p>\n

Cost is not significantly different (in the cloud) <\/p>\n

Can run resource-intensive applications <\/p>\n

Full replication<\/p>\n

Resources are used more efficiently (less overhead on system daemons)
\nHigher cluster fault tolerance<\/p>\n

Note that we are only talking about worker nodes. The choice of the number and size of master nodes is a completely different topic.<\/p>\n

So, let\u2019s discuss each point from the table in more detail.<\/p>\n

The first option: several large nodes<\/h2>\n

\nThe most extreme option is one worker node for the entire capacity of the cluster. In the example above, this would be one worker node with 16 CPU cores and 16 GB of RAM.<\/p>\n

Advantages <\/h3>\n

\nAdvantage #1. Simpler management<\/b>
\nEste mai simplu s\u0103 gestionezi mai multe ma\u0219ini dec\u00e2t un \u00eentreg parc. Actualiz\u0103rile \u0219i corec\u021biile se aplic\u0103 mai repede, iar sincronizarea este mai u\u0219oar\u0103. De asemenea, num\u0103rul de erori \u00een cifre absolute este, de asemenea, mai mic.<\/p>\n

Re\u021bine\u021bi c\u0103 toate cele de mai sus se refer\u0103 la hardware-ul propriu, serverele proprii, \u0219i nu la instan\u021bele cloud.<\/p><\/blockquote>\n

\n\u00cen cloud, situa\u021bia este diferit\u0103. Acolo, furnizorul de servicii cloud se ocup\u0103 de gestionare. Prin urmare, gestionarea a zece noduri \u00een cloud nu se deosebe\u0219te prea mult de gestionarea unui singur nod.<\/p>\n

Rutarea traficului \u0219i distribu\u021bia sarcinii \u00eentre poduri \u00een cloud se realizeaz\u0103 automat<\/a><\/noindex>: traficul venit din internet este direc\u021bionat c\u0103tre principalul balansor de sarcini, care redirec\u021bioneaz\u0103 traficul c\u0103tre portul unuia dintre noduri (serviciul NodePort aloc\u0103 un port \u00een intervalul 30000-32767 pentru fiecare nod din cluster). Regulele stabilite de kube-proxy redirec\u021bioneaz\u0103 traficul de la nod la pod. Iat\u0103 cum arat\u0103 acest lucru pentru zece pod-uri pe dou\u0103 noduri:<\/p>\n

\"Noduri
\nPlusul nr. 2. Costuri mai reduse pe nod<\/b>
\nO ma\u0219in\u0103 puternic\u0103 este mai scump\u0103, dar cre\u0219terea pre\u021bului nu este neap\u0103rat liniar\u0103. Cu alte cuvinte, un server cu zece nuclee \u0219i 10 GB de memorie este, de obicei, mai ieftin dec\u00e2t zece servere cu un singur nucleu, cu aceea\u0219i cantitate de memorie.<\/p>\n

Dar re\u021bine\u021bi c\u0103 aceast\u0103 regul\u0103 nu func\u021bioneaz\u0103 de obicei \u00een serviciile cloud. \u00cen schemele actuale de tarifare ale tuturor furnizorilor principali de servicii cloud, pre\u021burile cresc liniar odat\u0103 cu cre\u0219terea capacit\u0103\u021bii.<\/p><\/blockquote>\n

\nPrin urmare, \u00een cloud, de obicei, nu exist\u0103 economii la serverele mai puternice.<\/p>\n

Plusul nr. 3. Po\u021bi rula aplica\u021bii consumatoare de resurse<\/b>
\nUnele aplica\u021bii necesit\u0103 servere puternice \u00een cluster. De exemplu, dac\u0103 un sistem de \u00eenv\u0103\u021bare automat\u0103 necesit\u0103 8 GB de memorie, nu vei putea s\u0103-l rulezi pe noduri cu 1 GB, ci doar dac\u0103 exist\u0103 cel pu\u021bin un nod de lucru mare.<\/p>\n

Dezavantaje <\/h3>\n

\nMinusul nr. 1. Multe pod-uri pe nod<\/b>
\nDac\u0103 aceea\u0219i sarcin\u0103 este executat\u0103 pe un num\u0103r mai mic de noduri, atunci, evident, pe fiecare dintre ele vor fi mai multe pod-uri.<\/p>\n

Aceasta poate deveni o problem\u0103.<\/p>\n

Motivul este c\u0103 fiecare modul aduce unele costuri indirecte pentru mediu de rulare al containerului (de exemplu, Docker), precum \u0219i kubelet \u0219i cAdvisor.<\/p>\n

De exemplu, kubelet sondajeaz\u0103 cu regularitate despre s\u0103n\u0103tatea tuturor containerelor de pe nod - cu c\u00e2t sunt mai multe containere, cu at\u00e2t mai mult\u0103 munc\u0103 are kubelet.<\/p>\n

CAdvisor colecteaz\u0103 statistici privind utilizarea resurselor tuturor containerelor de pe nod, iar kubelet solicit\u0103 \u00een mod regulat aceste informa\u021bii \u0219i le ofer\u0103 prin API. Din nou, cu c\u00e2t sunt mai multe containere, cu at\u00e2t mai mult\u0103 munc\u0103 exist\u0103 pentru cAdvisor \u0219i kubelet.<\/p>\n

Dac\u0103 num\u0103rul de module cre\u0219te, acest lucru poate \u00eencetini sistemul \u0219i chiar \u00eei poate afecta fiabilitatea.<\/p>\n

\"Noduri
\n\u00cen repository-ul Kubernetes, unii s-au pl\u00e2ns<\/a><\/noindex>, c\u0103 nodurile sar \u00eentre st\u0103rile Ready\/NotReady, deoarece verific\u0103rile regulate ale kubelet pentru toate containerele de pe nod dureaz\u0103 prea mult timp.
\nDin acest motiv, Kubernetes Se recomand\u0103 s\u0103 nu se plaseze mai mult de 110 pod-uri pe nod<\/a><\/noindex>. \u00cen func\u021bie de performan\u021ba nodului, este posibil s\u0103 pute\u021bi rula mai multe pod-uri pe un nod, dar este greu de prezis dac\u0103 vor ap\u0103rea probleme sau dac\u0103 totul va func\u021biona bine. Merit\u0103 s\u0103 testa\u021bi func\u021bionarea din timp. <\/p>\n

Contras #2. Limitarea replic\u0103rii<\/b>
\nUn num\u0103r prea mic de noduri limiteaz\u0103 gradul eficient de replicare a aplica\u021biilor. De exemplu, dac\u0103 ave\u021bi o aplica\u021bie cu \u00eenalt\u0103 disponibilitate format\u0103 din cinci replici, dar numai dou\u0103 noduri, atunci gradul eficient de replicare al aplica\u021biei scade la dou\u0103.<\/p>\n

Cinci replici pot fi distribuite doar pe dou\u0103 noduri, iar dac\u0103 unul dintre ele nu func\u021bioneaz\u0103, mai multe replici sunt imediat afectate.<\/p>\n

Dac\u0103 ave\u021bi cinci noduri sau mai multe, fiecare replic\u0103 va fi executat\u0103 pe un nod separat, iar defectarea unui nod va elimina nu mai mult de o replic\u0103.<\/p>\n

Astfel, cerin\u021bele de \u00eenalt\u0103 disponibilitate pot necesita un anumit num\u0103r minim de noduri \u00een cluster.<\/p>\n

Contras #3. Consecin\u021be mai grave ale defect\u0103rii<\/b>
\nCu un num\u0103r mic de noduri, fiecare defectare are consecin\u021be mai grave. De exemplu, dac\u0103 ave\u021bi doar dou\u0103 noduri \u0219i unul dintre ele se stric\u0103, imediat se pierde jum\u0103tate din module.<\/p>\n

Desigur, Kubernetes va muta sarcina de lucru de pe nodul defect c\u0103tre altele. Dar dac\u0103 ele sunt pu\u021bine, poate s\u0103 nu existe suficient spa\u021biu disponibil. Ca rezultat, unele dintre aplica\u021biile dumneavoastr\u0103 vor fi indisponibile p\u00e2n\u0103 c\u00e2nd ve\u021bi reporni nodul defect.<\/p>\n

Astfel, cu c\u00e2t sunt mai multe noduri, cu at\u00e2t mai pu\u021bin impact au defectele hardware.<\/p>\n

Contras #4. Mai multe etape de autoscalare<\/b>
\n\u00cen Kubernetes, exist\u0103 un sistem de scalare automat\u0103 a clusterului pentru infrastructura cloud, care permite ad\u0103ugarea sau eliminarea automat\u0103 a nodurilor \u00een func\u021bie de nevoile actuale. Cu noduri mari, scalarea devine mai abrupt\u0103 \u0219i mai ne\u00eendem\u00e2natic\u0103. De exemplu, ad\u0103ugarea unui nod suplimentar la dou\u0103 noduri va cre\u0219te capacitatea clusterului imediat cu 50%. \u0218i va trebui s\u0103 pl\u0103ti\u021bi pentru aceste resurse, chiar dac\u0103 nu ave\u021bi nevoie de ele.<\/p>\n

Astfel, dac\u0103 planifica\u021bi s\u0103 utiliza\u021bi scalarea automat\u0103 a clusterului, cu c\u00e2t nodurile sunt mai mici, cu at\u00e2t ve\u021bi ob\u021bine o scalare mai flexibil\u0103 \u0219i mai economic\u0103.<\/p>\n

Acum s\u0103 discut\u0103m avantajele \u0219i dezavantajele unui num\u0103r mare de noduri mici.<\/p>\n

A doua variant\u0103: multe noduri mici<\/h2>\n

\nAvantajele acestei abord\u0103ri deriv\u0103, \u00een esen\u021b\u0103, din dezavantajele op\u021biunii opuse cu c\u00e2teva noduri mari.<\/p>\n

Advantages<\/h3>\n

\nPlus #1. Consecin\u021be mai mici \u00een caz de e\u0219ec<\/b>
\nCu c\u00e2t sunt mai multe noduri, cu at\u00e2t vor fi mai pu\u021bine pod-uri pe fiecare nod. De exemplu, dac\u0103 ave\u021bi o sut\u0103 de module pe zece noduri, fiecare nod va avea \u00een medie zece module.<\/p>\n

Astfel, dac\u0103 unul dintre noduri e\u0219ueaz\u0103, pierde\u021bi doar 10% din sarcina de lucru. Exist\u0103 o probabilitate ca doar un num\u0103r mic de replici s\u0103 fie afectate, iar aplica\u021biile \u00een ansamblu s\u0103 r\u0103m\u00e2n\u0103 func\u021bionale.<\/p>\n

\u00cen plus, pe nodurile r\u0103mase, cel mai probabil vor fi suficiente resurse libere pentru sarcina de lucru a nodului defect, astfel \u00eenc\u00e2t Kubernetes s\u0103 poat\u0103 reproiecta liber pod-urile, iar aplica\u021biile dvs. se vor restabili relativ rapid la starea func\u021bional\u0103.<\/p>\n

Plus #2. Replicare bun\u0103<\/b>
\nDac\u0103 sunt suficiente noduri, programatorul Kubernetes poate aloca tuturor replicilor noduri diferite. Astfel, \u00een caz de e\u0219ec al unui nod, va fi afectat\u0103 doar o singur\u0103 replic\u0103, iar aplica\u021bia va r\u0103m\u00e2ne disponibil\u0103.<\/p>\n

Dezavantaje <\/h3>\n

\nMinus #1. Management mai dificil<\/b>
\nGestionarea unui num\u0103r mare de noduri este mai complicat\u0103. De exemplu, fiecare nod Kubernetes trebuie s\u0103 interac\u021bioneze cu toate celelalte, adic\u0103 num\u0103rul conexiunilor cre\u0219te p\u0103tratic, iar toate aceste conexiuni trebuie monitorizate.<\/p>\n

Controlerul de noduri \u00een managerul de controlere Kubernetes verific\u0103 periodic toate nodurile din cluster pentru a verifica func\u021bionalitatea \u2014 cu c\u00e2t sunt mai multe noduri, cu at\u00e2t mai mare este sarcina pe controler.<\/p>\n

De asemenea, cre\u0219te sarcina asupra bazei de date etcd \u2014 fiecare kubelet \u0219i kube-proxy efectueaz\u0103 watcher<\/a><\/noindex> pentru etcd (prin API), la care etcd trebuie s\u0103 transmit\u0103 actualiz\u0103rile obiectului.<\/p>\n

\u00cen general, fiecare nod de lucru impune o sarcin\u0103 suplimentar\u0103 asupra componentelor sistemului nodurilor principale.<\/p>\n

\"Noduri
\nKubernetes suport\u0103 oficial clustere cu un num\u0103r de noduri de p\u00e2n\u0103 la 5000<\/a><\/noindex>. Totu\u0219i, \u00een practic\u0103, deja 500 de noduri pot cauza probleme non-triviale<\/a><\/noindex>.<\/p>\n

Pentru a gestiona un num\u0103r mare de noduri de lucru, este necesar s\u0103 alegi noduri principale mai performante. De exemplu, kube-up instaleaz\u0103 automat<\/a><\/noindex> dimensiunea corect\u0103 a VM pentru nodul principal \u00een func\u021bie de num\u0103rul de noduri de lucru. Cu alte cuvinte, cu c\u00e2t sunt mai multe noduri de lucru, cu at\u00e2t nodurile principale trebuie s\u0103 fie mai performante. <\/p>\n

Pentru a aborda aceste probleme specifice, exist\u0103 solu\u021bii speciale, cum ar fi Virtual Kubelet<\/a><\/noindex>. Acest sistem permite ocolirea limit\u0103rilor \u0219i construirea de clustere cu un num\u0103r enorm de noduri de lucru.<\/p>\n

Dezavantaj Nr. 2. Mai multe costuri indirecte<\/b>
\nPe fiecare nod de lucru, Kubernetes ruleaz\u0103 un set de demoni de sistem \u2014 acestea includ mediul de execu\u021bie a containerelor (de exemplu, Docker), kube-proxy \u0219i kubelet, inclusiv cAdvisor. \u00cempreun\u0103, aceste componente consum\u0103 o anumit\u0103 cantitate fix\u0103 de resurse.<\/p>\n

Dac\u0103 ai multe noduri mici, cota acestor costuri indirecte pe fiecare nod este mai mare. De exemplu, imagineaz\u0103-\u021bi c\u0103 to\u021bi demonii de sistem de pe un nod folosesc \u00eempreun\u0103 0,1 nuclee CPU \u0219i 0,1 GB de memorie. Dac\u0103 ai un nod cu zece nuclee \u0219i 10 GB de memorie, demonii consum\u0103 1% din capacitatea clusterei. Pe de alt\u0103 parte, pe zece noduri cu un nucleu fiecare \u0219i 1 GB de memorie, demonii vor consuma 10% din capacitatea clusterei.<\/p>\n

Prin urmare, cu c\u00e2t sunt mai pu\u021bine noduri, cu at\u00e2t infrastructura este utilizat\u0103 mai eficient.<\/p>\n

Dezavantaj Nr. 3. Utilizarea ineficient\u0103 a resurselor<\/b>
\nPe noduri mici, se poate \u00eent\u00e2mpla ca fragmentele r\u0103mase de resurse s\u0103 fie prea mici pentru a le aloca o sarcin\u0103 de lucru, astfel c\u0103 acestea r\u0103m\u00e2n neutilizate.<\/p>\n

De exemplu, fiecare pod necesit\u0103 0,75 GB de memorie. Dac\u0103 ave\u021bi zece noduri, iar fiecare are 1 GB de memorie, pute\u021bi rula zece pod-uri \u2014 \u00een final, pe fiecare nod va r\u0103m\u00e2ne 0,25 GB de memorie neutilizat\u0103.<\/p>\n

Aceasta \u00eenseamn\u0103 c\u0103 25% din memoria total\u0103 a clusterei este cheltuit\u0103 f\u0103r\u0103 rost.<\/p>\n

Pe un nod mare cu 10 GB de memorie, po\u021bi rula 13 astfel de module \u2014 \u0219i va r\u0103m\u00e2ne doar un fragment neutilizat de 0,25 GB.<\/p>\n

\u00cen acest caz, doar 2,5% din memorie este cheltuit\u0103 f\u0103r\u0103 rost.<\/p>\n

Astfel, resursele sunt utilizate mai eficient pe noduri mari.<\/p>\n

C\u00e2teva noduri mari sau multe noduri mici?<\/h2>\n

\nDeci, ce este mai bine: c\u00e2teva noduri mari \u00eentr-un cluster sau multe noduri mici? Ca de obicei, nu exist\u0103 un r\u0103spuns clar. Multe depind de tipul aplica\u021biei.<\/p>\n

De exemplu, dac\u0103 aplica\u021bia necesit\u0103 10 GB de memorie, alegerea evident\u0103 este nodurile mari. Iar dac\u0103 aplica\u021bia necesit\u0103 replicare de zece ori pentru disponibilitate ridicat\u0103, cu siguran\u021b\u0103 nu ar trebui s\u0103 risca\u021bi s\u0103 plasa\u021bi replicile pe doar dou\u0103 noduri \u2014 ar trebui s\u0103 existe cel pu\u021bin zece noduri \u00een cluster.<\/p>\n

\u00cen situa\u021bii intermediare, face\u021bi alegerea \u00een func\u021bie de avantajele \u0219i dezavantajele fiec\u0103rei op\u021biuni. Poate c\u0103 unele argumente sunt mai relevante pentru situa\u021bia dvs. dec\u00e2t altele.<\/p>\n

\u0218i nu este deloc obligatoriu s\u0103 ave\u021bi toate nodurile de aceea\u0219i dimensiune. Nimic nu \u00eempiedic\u0103 experimentarea mai \u00eent\u00e2i cu noduri de aceea\u0219i dimensiune, apoi ad\u0103ugarea de noduri de dimensiuni diferite, combin\u00e2ndu-le \u00een cluster. Nodurile de lucru ale clusterului Kubernetes pot fi complet heterogene. Deci, pute\u021bi \u00eencerca s\u0103 combina\u021bi avantajele ambelor abord\u0103ri.<\/p>\n

Nu exist\u0103 o re\u021bet\u0103 unic\u0103, iar fiecare situa\u021bie are nuan\u021bele sale, iar doar produc\u021bia va ar\u0103ta adev\u0103rul.<\/p>\n

Traducerea a fost preg\u0103tit\u0103 de echipa platformei de cloud Solu\u021bii Cloud Mail.ru<\/a><\/noindex>.<\/i><\/p>\n

\u00cenc\u0103 despre Kubernetes: 25 de instrumente utile pentru gestionarea \u0219i desf\u0103\u0219urarea clusterelor<\/a><\/noindex>.<\/p>\n

Sursa: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kubernetes \u043c\u043e\u0433\u0443\u0442 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441\u044b: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u0443\u0437\u043b\u043e\u0432 \u0438 \u043a\u0430\u043a\u043e\u0433\u043e \u0442\u0438\u043f\u0430? \u0427\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 on-premise: \u043a\u0443\u043f\u0438\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0449\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438\u043b\u0438 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0434\u0435\u0441\u044f\u0442\u043e\u043a \u0441\u0442\u0430\u0440\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0432 \u0432\u0430\u0448\u0435\u043c \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0435? \u0410 \u0432 \u043e\u0431\u043b\u0430\u043a\u0435 \u043b\u0443\u0447\u0448\u0435 \u0432\u0437\u044f\u0442\u044c \u0432\u043e\u0441\u0435\u043c\u044c \u043e\u0434\u043d\u043e\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043b\u0438 \u0434\u0432\u0430 \u0447\u0435\u0442\u044b\u0440\u0435\u0445\u044a\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043d\u0441\u0442\u0430\u043d\u0441\u0430? \u041e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u044d\u0442\u0438 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u2014 \u0432 \u0441\u0442\u0430\u0442\u044c\u0435 \u0414\u0430\u043d\u0438\u044d\u043b\u044f \u0412\u0430\u0439\u0431\u0435\u043b\u044f, \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430-\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430 \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044f \u043e\u0431\u0443\u0447\u0430\u044e\u0449\u0435\u0433\u043e […]<\/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-56259","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Noduri de lucru Kubernetes: multe mici sau c\u00e2teva mari? | ProHoster","description":"Atunci c\u00e2nd crea\u021bi un cluster.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","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\u0420\u0430\u0431\u043e\u0447\u0438\u0435 \u0443\u0437\u043b\u044b Kubernetes: \u043c\u043d\u043e\u0433\u043e \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445 \u0438\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u043e\u043b\u044c\u0448\u0438\u0445? | ProHoster","og:description":"\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","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-02-07T21:00:00+00:00","article:modified_time":"2020-02-18T11:04:30+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"56259","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:28:23","updated":"2022-10-03 08:08:38","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\/56259","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=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}