{"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\/fr\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"N\u0153uds de travail Kubernetes : beaucoup de petits ou quelques grands ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"N\u0153uds
\nLors de la cr\u00e9ation d'un cluster Kubernetes, plusieurs questions peuvent se poser : combien de n\u0153uds de travail configurer et quel type ? Qu'est-ce qui est mieux pour un cluster on-premise : acheter plusieurs serveurs puissants ou utiliser une dizaine de machines anciennes dans votre centre de donn\u00e9es ? Et dans le cloud, vaut-il mieux choisir huit instances uniprocesseur ou deux instances quadruple processeur ? <\/p>\n

Les r\u00e9ponses \u00e0 ces questions se trouvent dans l'article de Daniel Weibler, ing\u00e9nieur-programmeur et enseignant dans le projet d'apprentissage Learnk8s<\/a><\/noindex> dans la traduction de l'\u00e9quipe Kubernetes aaS de Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Capacit\u00e9 du cluster<\/h2>\n

\nEn g\u00e9n\u00e9ral, un cluster Kubernetes peut \u00eatre vu comme un grand \u00ab super-n\u0153ud \u00bb. Sa puissance de calcul totale est la somme des puissances de tous les n\u0153uds qui le composent. <\/p>\n

Il existe plusieurs fa\u00e7ons d'atteindre la capacit\u00e9 cible souhait\u00e9e du cluster. Par exemple, nous avons besoin d'un cluster avec une capacit\u00e9 totale de 8 c\u0153urs CPU et 32 Go de RAM, car l'ensemble d'applications n\u00e9cessite cette quantit\u00e9 de ressources. On peut alors configurer deux n\u0153uds de 16 Go de RAM ou quatre n\u0153uds de 8 Go, avec soit deux processeurs quadruple c\u0153ur, soit quatre processeurs double c\u0153ur.<\/p>\n

Voici juste deux fa\u00e7ons possibles de cr\u00e9er un cluster :<\/p>\n

\"N\u0153uds
\nLes deux options donnent un cluster avec la m\u00eame capacit\u00e9, mais la configuration du bas contient quatre n\u0153uds plus petits, tandis que la configuration du haut contient deux grands n\u0153uds. <\/p>\n

Quelle option est la meilleure ?<\/h3>\n

\nPour r\u00e9pondre \u00e0 cette question, examinons les avantages de chaque option. Nous les avons r\u00e9sum\u00e9s dans un tableau.<\/p>\n

Plusieurs grands n\u0153uds<\/p>\n

Beaucoup de petits n\u0153uds<\/p>\n

Gestion du cluster plus simple (s'il est on-premise)<\/p>\n

Mise \u00e0 l'\u00e9chelle automatique fluide<\/p>\n

Moins cher (s'il est on-premise) <\/p>\n

Le prix est \u00e0 peine diff\u00e9rent (dans le cloud) <\/p>\n

Peut ex\u00e9cuter des applications gourmandes en ressources <\/p>\n

R\u00e9plicabilit\u00e9 compl\u00e8te<\/p>\n

Les ressources sont utilis\u00e9es plus efficacement (moins de surcharge pour les d\u00e9mons syst\u00e8me)
\nMeilleure r\u00e9silience du cluster<\/p>\n

Notez que nous parlons uniquement des n\u0153uds de travail. Le choix du nombre et de la taille des n\u0153uds principaux est un sujet totalement diff\u00e9rent.<\/p>\n

Donc, examinons plus en d\u00e9tail chaque point du tableau.<\/p>\n

Premi\u00e8re option : plusieurs grands n\u0153uds<\/h2>\n

\nLa mani\u00e8re la plus extr\u00eame est d'avoir un seul n\u0153ud de travail pour l'ensemble de la capacit\u00e9 du cluster. Dans l'exemple ci-dessus, cela aurait \u00e9t\u00e9 un n\u0153ud de travail avec 16 c\u0153urs CPU et 16 Go de RAM.<\/p>\n

Avantages <\/h3>\n

\nAvantage n\u00b0 1. Gestion plus simple<\/b>
\nIl est plus facile de g\u00e9rer plusieurs machines que tout un parc. Les mises \u00e0 jour et les corrections sont plus rapides \u00e0 appliquer et la synchronisation est plus simple. Le nombre d'incidents en chiffres absolus est \u00e9galement moindre.<\/p>\n

Veuillez noter que tout ce qui pr\u00e9c\u00e8de concerne votre propre mat\u00e9riel, vos propres serveurs, et non les instances cloud.<\/p><\/blockquote>\n

\nLa situation est diff\u00e9rente dans le cloud. L\u00e0, la gestion est assur\u00e9e par le fournisseur de services cloud. En cons\u00e9quence, g\u00e9rer dix n\u0153uds dans le cloud ne diff\u00e8re gu\u00e8re de la gestion d'un unique n\u0153ud.<\/p>\n

La routage du trafic et la r\u00e9partition de la charge entre les pods dans le cloud s'effectue automatiquement<\/a><\/noindex>: le trafic entrant d'Internet est dirig\u00e9 vers le r\u00e9partiteur de charge principal, qui redirige le trafic vers le port de l'un des n\u0153uds (le service NodePort expose un port dans la plage 30000-32767 sur chaque n\u0153ud du cluster). Les r\u00e8gles \u00e9tablies par kube-proxy redirigent le trafic du n\u0153ud vers le pod. Voici \u00e0 quoi cela ressemble pour dix pods sur deux n\u0153uds :<\/p>\n

\"N\u0153uds
\nAvantage n\u00b0 2. Moins de co\u00fbts par n\u0153ud<\/b>
\nUne machine puissante co\u00fbte plus cher, mais la hausse des prix n'est pas n\u00e9cessairement lin\u00e9aire. En d'autres termes, un serveur \u00e0 dix c\u0153urs avec 10 Go de m\u00e9moire est g\u00e9n\u00e9ralement moins cher que dix serveurs \u00e0 un c\u0153ur avec la m\u00eame quantit\u00e9 de m\u00e9moire.<\/p>\n

Mais veuillez noter que cette r\u00e8gle ne s'applique g\u00e9n\u00e9ralement pas aux services cloud. Dans les sch\u00e9mas de tarification actuels de tous les principaux fournisseurs de services cloud, les prix augmentent lin\u00e9airement avec la capacit\u00e9.<\/p><\/blockquote>\n

\nAinsi, dans le cloud, il n'est g\u00e9n\u00e9ralement pas possible de faire des \u00e9conomies sur des serveurs plus puissants.<\/p>\n

Avantage n\u00b0 3. Possibilit\u00e9 d'ex\u00e9cuter des applications gourmandes en ressources<\/b>
\nCertaines applications n\u00e9cessitent des serveurs puissants dans le cluster. Par exemple, si un syst\u00e8me d'apprentissage automatique n\u00e9cessite 8 Go de m\u00e9moire, vous ne pourrez pas l'ex\u00e9cuter sur des n\u0153uds de 1 Go, sauf si vous avez au moins un grand n\u0153ud de travail.<\/p>\n

Inconv\u00e9nients <\/h3>\n

\nInconv\u00e9nient n\u00b0 1. Beaucoup de pods sur un n\u0153ud<\/b>
\nSi la m\u00eame t\u00e2che est ex\u00e9cut\u00e9e sur moins de n\u0153uds, il y aura naturellement plus de pods sur chacun d'eux.<\/p>\n

Cela peut poser probl\u00e8me.<\/p>\n

La raison en est que chaque module entra\u00eene des frais g\u00e9n\u00e9raux pour l'environnement d'ex\u00e9cution des conteneurs (par exemple, Docker), ainsi que pour kubelet et cAdvisor.<\/p>\n

Par exemple, kubelet sonde r\u00e9guli\u00e8rement la disponibilit\u00e9 de tous les conteneurs sur le n\u0153ud - plus il y a de conteneurs, plus le travail pour kubelet est important.<\/p>\n

CAdvisor collecte des statistiques sur l'utilisation des ressources de tous les conteneurs sur le n\u0153ud, et kubelet demande r\u00e9guli\u00e8rement ces informations et les fournit via l'API. Encore une fois, plus il y a de conteneurs, plus le travail augmente pour cAdvisor et kubelet.<\/p>\n

Si le nombre de modules augmente, cela peut ralentir le syst\u00e8me et m\u00eame compromettre sa fiabilit\u00e9.<\/p>\n

\"N\u0153uds
\nDans le d\u00e9p\u00f4t Kubernetes, certains se sont plaints<\/a><\/noindex>, que les n\u0153uds fluctuent entre les statuts Ready\/NotReady, car les v\u00e9rifications r\u00e9guli\u00e8res de kubelet pour tous les conteneurs sur le n\u0153ud prennent trop de temps.
\nPour cette raison, Kubernetes Il est recommand\u00e9 de ne pas placer plus de 110 pods sur un n\u0153ud.<\/a><\/noindex>. En fonction de la performance du n\u0153ud, vous pouvez ex\u00e9cuter plus de pods par n\u0153ud, mais il est difficile de pr\u00e9dire si des probl\u00e8mes surviendront ou si tout fonctionnera bien. Il est recommand\u00e9 de tester le fonctionnement \u00e0 l'avance. <\/p>\n

Inconv\u00e9nient n\u00b0 2. Limite de r\u00e9plication<\/b>
\nUn nombre trop r\u00e9duit de n\u0153uds limite le degr\u00e9 efficace de r\u00e9plication des applications. Par exemple, si vous avez une application \u00e0 haute disponibilit\u00e9 compos\u00e9e de cinq r\u00e9pliques, mais seulement deux n\u0153uds, le degr\u00e9 efficace de r\u00e9plication de l'application est r\u00e9duit \u00e0 deux.<\/p>\n

Cinq r\u00e9pliques ne peuvent \u00eatre r\u00e9parties que sur deux n\u0153uds, et si l'un d'eux tombe en panne, plusieurs r\u00e9pliques sont imm\u00e9diatement hors service.<\/p>\n

Si vous avez cinq n\u0153uds ou plus, chaque r\u00e9plique sera ex\u00e9cut\u00e9e sur un n\u0153ud distinct, et la d\u00e9faillance d'un n\u0153ud n'\u00e9liminera qu'une seule r\u00e9plique.<\/p>\n

Ainsi, les exigences de haute disponibilit\u00e9 peuvent n\u00e9cessiter un nombre minimum de n\u0153uds dans le cluster.<\/p>\n

Inconv\u00e9nient n\u00b0 3. Cons\u00e9quences plus graves en cas de d\u00e9faillance<\/b>
\nAvec un faible nombre de n\u0153uds, chaque d\u00e9faillance a des cons\u00e9quences plus importantes. Par exemple, si vous avez seulement deux n\u0153uds, et que l'un d'eux tombe en panne, la moiti\u00e9 de vos modules est imm\u00e9diatement hors service.<\/p>\n

Bien s\u00fbr, Kubernetes d\u00e9placera la charge de travail du n\u0153ud d\u00e9faillant vers d'autres. Mais s'ils sont peu nombreux, il se peut qu'il n'y ait pas assez de capacit\u00e9 disponible. En cons\u00e9quence, une partie de vos applications sera inaccessible tant que vous ne red\u00e9marrez pas le n\u0153ud d\u00e9faillant.<\/p>\n

Ainsi, plus il y a de n\u0153uds, moins l'impact des d\u00e9faillances mat\u00e9rielles est important.<\/p>\n

Inconv\u00e9nient n\u00b0 4. Plus de d\u00e9marches d'autoscaling<\/b>
\nDans Kubernetes, un syst\u00e8me d'autoscaling de cluster fonctionne pour l'infrastructure cloud, ce qui permet d'ajouter ou de supprimer automatiquement des n\u0153uds en fonction des besoins actuels. Avec de grands n\u0153uds, l'autoscaling devient plus abrupt et maladroit. Par exemple, sur deux n\u0153uds, l'ajout d'un n\u0153ud suppl\u00e9mentaire augmentera la capacit\u00e9 du cluster de 50 % imm\u00e9diatement. Et vous devrez payer pour ces ressources, m\u00eame si vous n'en avez pas besoin.<\/p>\n

Ainsi, si vous pr\u00e9voyez d'utiliser l'autoscaling de cluster, plus les n\u0153uds sont petits, plus l'\u00e9chelle se r\u00e9v\u00e8le flexible et \u00e9conomique.<\/p>\n

Examinons maintenant les avantages et les inconv\u00e9nients d'un grand nombre de petits n\u0153uds.<\/p>\n

Deuxi\u00e8me option : de nombreux petits n\u0153uds<\/h2>\n

\nLes avantages de cette approche d\u00e9coulent essentiellement des inconv\u00e9nients de l'option oppos\u00e9e avec quelques grands n\u0153uds.<\/p>\n

Avantages<\/h3>\n

\nAvantage n\u00b0 1. Moins de cons\u00e9quences en cas de d\u00e9faillance<\/b>
\nPlus il y a de n\u0153uds, moins il y a de pods sur chaque n\u0153ud. Par exemple, si vous avez cent modules sur dix n\u0153uds, il y aura en moyenne dix modules par n\u0153ud.<\/p>\n

Ainsi, si l'un des n\u0153uds tombe en panne, vous ne perdez que 10 % de la charge de travail. Il est probable qu'un petit nombre de r\u00e9pliques soit touch\u00e9, et les applications restent globalement op\u00e9rationnelles.<\/p>\n

De plus, les n\u0153uds restants auront probablement suffisamment de ressources libres pour g\u00e9rer la charge de travail du n\u0153ud d\u00e9faillant, ce qui permettra \u00e0 Kubernetes de replanifier les pods sans probl\u00e8me, et vos applications retrouveront un \u00e9tat fonctionnel relativement rapidement.<\/p>\n

Avantage n\u00b0 2. Bonne r\u00e9plication<\/b>
\nS'il y a suffisamment de n\u0153uds, le planificateur Kubernetes peut attribuer toutes les r\u00e9pliques \u00e0 des n\u0153uds diff\u00e9rents. Ainsi, en cas de d\u00e9faillance d'un n\u0153ud, une seule r\u00e9plique est touch\u00e9e, et l'application reste disponible.<\/p>\n

Inconv\u00e9nients <\/h3>\n

\nInconv\u00e9nient n\u00b0 1. Gestion plus difficile<\/b>
\nG\u00e9rer un grand nombre de n\u0153uds est plus compliqu\u00e9. Par exemple, chaque n\u0153ud Kubernetes doit interagir avec tous les autres, ce qui signifie que le nombre de connexions cro\u00eet de mani\u00e8re quadratique, et toutes ces connexions doivent \u00eatre suivies.<\/p>\n

Le contr\u00f4leur de n\u0153uds dans le contr\u00f4leur manager Kubernetes parcourt r\u00e9guli\u00e8rement tous les n\u0153uds du cluster pour v\u00e9rifier leur \u00e9tat de fonctionnement \u2014 plus il y a de n\u0153uds, plus la charge sur le contr\u00f4leur est \u00e9lev\u00e9e.<\/p>\n

La charge sur la base de donn\u00e9es etcd augmente \u00e9galement \u2014 chaque kubelet et kube-proxy appelle watcher<\/a><\/noindex> pour etcd (via l'API), auquel etcd doit transmettre les mises \u00e0 jour d'objet.<\/p>\n

En g\u00e9n\u00e9ral, chaque n\u0153ud de travail impose une charge suppl\u00e9mentaire sur les composants syst\u00e8me des n\u0153uds ma\u00eetres.<\/p>\n

\"N\u0153uds
\nOfficiellement, Kubernetes prend en charge des clusters avec jusqu'\u00e0 5000 n\u0153uds.<\/a><\/noindex>Cependant, en pratique, d\u00e9j\u00e0 500 n\u0153uds peuvent poser des probl\u00e8mes non triviaux.<\/a><\/noindex>.<\/p>\n

Pour g\u00e9rer un grand nombre de n\u0153uds de travail, il est pr\u00e9f\u00e9rable de choisir des n\u0153uds ma\u00eetres plus performants. Par exemple, kube-up installe automatiquement<\/a><\/noindex> la taille correcte de la machine virtuelle pour le n\u0153ud ma\u00eetre en fonction du nombre de n\u0153uds de travail. C'est-\u00e0-dire que plus il y a de n\u0153uds de travail, plus les n\u0153uds ma\u00eetres doivent \u00eatre performants. <\/p>\n

Pour r\u00e9soudre ces probl\u00e8mes sp\u00e9cifiques, il existe des d\u00e9veloppements sp\u00e9ciaux, tels que Virtual Kubelet.<\/a><\/noindex>Ce syst\u00e8me permet de contourner les limitations et de construire des clusters avec un nombre \u00e9norme de n\u0153uds de travail.<\/p>\n

Inconv\u00e9nient n\u00b0 2. Plus de frais g\u00e9n\u00e9raux.<\/b>
\nSur chaque n\u0153ud de travail, Kubernetes ex\u00e9cute un ensemble de d\u00e9mons syst\u00e8me \u2014 cela inclut l'environnement d'ex\u00e9cution des conteneurs (par exemple, Docker), kube-proxy et kubelet, y compris cAdvisor. Ensemble, ils consomment une certaine quantit\u00e9 fixe de ressources.<\/p>\n

Si vous avez beaucoup de petits n\u0153uds, la part de ces frais g\u00e9n\u00e9raux sur chaque n\u0153ud est plus importante. Par exemple, imaginez que tous les d\u00e9mons syst\u00e8me d'un n\u0153ud consomment ensemble 0,1 c\u0153ur de processeur et 0,1 Go de m\u00e9moire. Si vous avez un n\u0153ud d\u00e9cac\u0153ur avec 10 Go de m\u00e9moire, alors les d\u00e9mons consomment 1 % de la capacit\u00e9 du cluster. En revanche, sur dix n\u0153uds monocores avec 1 Go de m\u00e9moire, les d\u00e9mons prendront 10 % de la capacit\u00e9 du cluster.<\/p>\n

Ainsi, moins il y a de n\u0153uds, plus l'infrastructure est utilis\u00e9e efficacement.<\/p>\n

Inconv\u00e9nient n\u00b0 3. Utilisation inefficace des ressources.<\/b>
\nSur de petits n\u0153uds, il se peut que les fragments de ressources restants soient trop petits pour leur attribuer une charge de travail, donc ils restent inutilis\u00e9s.<\/p>\n

Par exemple, chaque pod n\u00e9cessite 0,75 Go de m\u00e9moire. Si vous avez dix n\u0153uds, et qu'il y a 1 Go de m\u00e9moire sur chacun, vous pouvez ex\u00e9cuter dix pods \u2014 au final, il restera 0,25 Go de m\u00e9moire inutilis\u00e9e sur chaque n\u0153ud.<\/p>\n

Cela signifie que 25 % de la m\u00e9moire totale du cluster est gaspill\u00e9e.<\/p>\n

Sur un grand n\u0153ud avec 10 Go de m\u00e9moire, vous pouvez ex\u00e9cuter 13 de ces modules \u2014 et il ne restera qu'un seul fragment inutilis\u00e9 de 0,25 Go.<\/p>\n

Dans ce cas, seulement 2,5 % de la m\u00e9moire est gaspill\u00e9e.<\/p>\n

Ainsi, les ressources sont mieux utilis\u00e9es sur de grands n\u0153uds.<\/p>\n

Plusieurs grands n\u0153uds ou beaucoup de petits ?<\/h2>\n

\nAlors, qu'est-ce qui est mieux : plusieurs grands n\u0153uds dans un cluster ou beaucoup de petits ? Comme toujours, il n'y a pas de r\u00e9ponse unique. Tout d\u00e9pend du type d'application.<\/p>\n

Par exemple, si une application n\u00e9cessite 10 Go de m\u00e9moire, le choix en faveur de grands n\u0153uds est \u00e9vident. Et si l'application n\u00e9cessite une r\u00e9plication dix fois pour une haute disponibilit\u00e9, il serait risqu\u00e9 de placer les r\u00e9pliques uniquement sur deux n\u0153uds - un cluster devrait avoir au moins dix n\u0153uds.<\/p>\n

Dans les situations interm\u00e9diaires, faites un choix en fonction des avantages et des inconv\u00e9nients de chaque option. Certains arguments peuvent \u00eatre plus pertinents pour votre situation que d'autres.<\/p>\n

Il n'est pas n\u00e9cessaire de rendre tous les n\u0153uds de la m\u00eame taille. Rien n'emp\u00eache d'exp\u00e9rimenter d'abord avec des n\u0153uds de m\u00eame taille, puis d'ajouter des n\u0153uds d'une autre taille, en les combinant dans le cluster. Les n\u0153uds de travail du cluster Kubernetes peuvent \u00eatre enti\u00e8rement h\u00e9t\u00e9rog\u00e8nes. Vous pouvez donc essayer de combiner les avantages des deux approches.<\/p>\n

Il n'existe pas de recette unique, chaque situation ayant ses nuances, et seule la production montrera la v\u00e9rit\u00e9.<\/p>\n

La traduction a \u00e9t\u00e9 pr\u00e9par\u00e9e par l'\u00e9quipe de la plateforme cloud Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

Encore sur Kubernetes : 25 outils utiles pour la gestion et le d\u00e9ploiement de clusters<\/a><\/noindex>.<\/p>\n

Source : 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\udd47N\u0153uds de travail Kubernetes : beaucoup de petits ou quelques grands ? | ProHoster","description":"Lors de la cr\u00e9ation d'un cluster.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}