{"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\/es\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Nodos de trabajo de Kubernetes: \u00bfmuchos peque\u00f1os o unos pocos grandes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nodos
\nAl crear un cl\u00faster de Kubernetes pueden surgir preguntas: \u00bfcu\u00e1ntos nodos de trabajo configurar y de qu\u00e9 tipo? \u00bfQu\u00e9 es mejor para un cl\u00faster on-premise: comprar varios servidores potentes o utilizar una docena de m\u00e1quinas antiguas en su centro de datos? \u00bfY en la nube, es mejor elegir ocho instancias de un solo n\u00facleo o dos de cuatro n\u00facleos? <\/p>\n

Las respuestas a estas preguntas est\u00e1n en el art\u00edculo de Daniel Weibel, ingeniero de software y docente del proyecto de aprendizaje Learnk8s<\/a><\/noindex> en la traducci\u00f3n del equipo Kubernetes aaS de Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Capacidad del cl\u00faster<\/h2>\n

\nEn general, un cl\u00faster de Kubernetes puede verse como un gran 'supernodo'. Su potencia computacional total es la suma de las potencias de todos los nodos componentes. <\/p>\n

Existen varias formas de alcanzar la capacidad objetivo deseada del cl\u00faster. Por ejemplo, necesitamos un cl\u00faster con una capacidad total de 8 n\u00facleos de CPU y 32 GB de RAM, porque el conjunto de aplicaciones requiere esa cantidad de recursos. Entonces, se pueden instalar dos nodos de 16 GB de memoria o cuatro nodos de 8 GB de memoria, dos procesadores de cuatro n\u00facleos o cuatro de dos n\u00facleos.<\/p>\n

Aqu\u00ed hay solo dos formas posibles de crear un cl\u00faster:<\/p>\n

\"Nodos
\nAmbas opciones dan como resultado un cl\u00faster con la misma capacidad, pero en la configuraci\u00f3n inferior se establecen cuatro nodos m\u00e1s peque\u00f1os, mientras que en la configuraci\u00f3n superior hay dos nodos m\u00e1s grandes. <\/p>\n

\u00bfCu\u00e1l opci\u00f3n es mejor?<\/h3>\n

\nPara responder a esta pregunta, consideremos las ventajas de ambas opciones. Las hemos resumido en una tabla.<\/p>\n

Varios nodos grandes<\/p>\n

Muchos nodos peque\u00f1os<\/p>\n

M\u00e1s f\u00e1cil administrar el cl\u00faster (si es on-premise)<\/p>\n

Escalado autom\u00e1tico fluido<\/p>\n

M\u00e1s econ\u00f3mico (si es on-premise) <\/p>\n

El precio es poco diferente (en la nube) <\/p>\n

Se pueden ejecutar aplicaciones que consumen muchos recursos <\/p>\n

Replicaci\u00f3n completa<\/p>\n

Los recursos se utilizan de manera m\u00e1s eficiente (menos sobrecarga por demonios del sistema)
\nMayor resistencia a fallos del cl\u00faster<\/p>\n

Tenga en cuenta que solo estamos hablando de nodos de trabajo. La elecci\u00f3n de la cantidad y tama\u00f1o de los nodos maestros es un tema completamente diferente.<\/p>\n

As\u00ed que analicemos en detalle cada punto de la tabla.<\/p>\n

Primera opci\u00f3n: varios nodos grandes<\/h2>\n

\nLa opci\u00f3n m\u00e1s extrema ser\u00eda tener un solo nodo de trabajo para toda la capacidad del cl\u00faster. En el ejemplo anterior, esto ser\u00eda un solo nodo de trabajo con 16 n\u00facleos de CPU y 16 GB de RAM.<\/p>\n

Ventajas <\/h3>\n

\nVentaja #1. M\u00e1s f\u00e1cil de administrar<\/b>
\nEs m\u00e1s f\u00e1cil gestionar varias m\u00e1quinas que todo un parque. Las actualizaciones y correcciones se aplican m\u00e1s r\u00e1pidamente y es m\u00e1s sencillo sincronizar. La cantidad de fallos en cifras absolutas tambi\u00e9n es menor.<\/p>\n

Tenga en cuenta que todo lo anterior se refiere a su propio hardware, a sus propios servidores, no a instancias en la nube.<\/p><\/blockquote>\n

\nEn la nube la situaci\u00f3n es diferente. All\u00ed, la gesti\u00f3n est\u00e1 a cargo del proveedor de servicios en la nube. As\u00ed, gestionar diez nodos en la nube no es significativamente diferente de gestionar un solo nodo.<\/p>\n

La ruta del tr\u00e1fico y la distribuci\u00f3n de la carga entre los pods en la nube se realiza autom\u00e1ticamente<\/a><\/noindex>: el tr\u00e1fico entrante de Internet se dirige al equilibrador de carga principal, que a su vez env\u00eda el tr\u00e1fico al puerto de uno de los nodos (el servicio NodePort asigna un puerto en el rango de 30000-32767 en cada nodo del cl\u00faster). Las reglas establecidas por kube-proxy redirigen el tr\u00e1fico del nodo al pod. As\u00ed es como se ve para diez pods en dos nodos:<\/p>\n

\"Nodos
\nVentaja n\u00ba 2. Menores costos por nodo<\/b>
\nUna m\u00e1quina potente es m\u00e1s cara, pero el aumento de precio no necesariamente es lineal. En otras palabras, un servidor de diez n\u00facleos con 10 GB de RAM suele ser m\u00e1s barato que diez servidores de un n\u00facleo con la misma cantidad de RAM.<\/p>\n

Sin embargo, tenga en cuenta que esta regla generalmente no se aplica a los servicios en la nube. En los esquemas actuales de precios, los precios de todos los principales proveedores de servicios en la nube aumentan linealmente con la capacidad.<\/p><\/blockquote>\n

\nPor lo tanto, en la nube normalmente no se puede ahorrar en servidores m\u00e1s potentes.<\/p>\n

Ventaja n\u00ba 3. Se pueden ejecutar aplicaciones que consumen muchos recursos<\/b>
\nAlgunas aplicaciones requieren servidores potentes en el cl\u00faster. Por ejemplo, si un sistema de aprendizaje autom\u00e1tico requiere 8 GB de RAM, no podr\u00e1 ejecutarlo en nodos de 1 GB, solo con al menos un nodo de trabajo grande.<\/p>\n

Desventajas <\/h3>\n

\nDesventaja N\u00ba 1. Muchos pods por nodo<\/b>
\nSi la misma tarea se realiza en un menor n\u00famero de nodos, cada uno de ellos, por supuesto, tendr\u00e1 m\u00e1s pods.<\/p>\n

Esto puede convertirse en un problema.<\/p>\n

La raz\u00f3n es que cada m\u00f3dulo introduce ciertos costes en el entorno de ejecuci\u00f3n del contenedor (por ejemplo, Docker), as\u00ed como kubelet y cAdvisor.<\/p>\n

Por ejemplo, kubelet sondea regularmente la disponibilidad de todos los contenedores en el nodo; cuanto m\u00e1s contenedores haya, m\u00e1s trabajo tiene kubelet.<\/p>\n

CAdvisor recopila estad\u00edsticas del uso de recursos de todos los contenedores en el nodo, y kubelet consulta esta informaci\u00f3n regularmente y la proporciona a trav\u00e9s de la API. De nuevo, cu\u00e1ntos m\u00e1s contenedores, m\u00e1s trabajo hay tanto para cAdvisor como para kubelet.<\/p>\n

Si el n\u00famero de m\u00f3dulos aumenta, esto puede ralentizar el sistema e incluso comprometer su confiabilidad.<\/p>\n

\"Nodos
\nEn el repositorio de Kubernetes, algunos se quejaron<\/a><\/noindex>, que los nodos saltan entre los estados Ready\/NotReady, ya que las verificaciones regulares de kubelet de todos los contenedores en el nodo toman demasiado tiempo.
\nPor esta raz\u00f3n, Kubernetes se recomienda no colocar m\u00e1s de 110 pods por nodo<\/a><\/noindex>. Dependiendo del rendimiento del nodo, puede ejecutar m\u00e1s pods por nodo, pero es dif\u00edcil predecir si habr\u00e1 problemas o si todo funcionar\u00e1 bien. Vale la pena probar su funcionamiento con antelaci\u00f3n. <\/p>\n

Desventaja N\u00ba 2. Limitaci\u00f3n en la replicaci\u00f3n<\/b>
\nDemasiados pocos nodos limitan el grado efectivo de replicaci\u00f3n de las aplicaciones. Por ejemplo, si tiene una aplicaci\u00f3n de alta disponibilidad con cinco r\u00e9plicas, pero solo dos nodos, entonces el grado efectivo de replicaci\u00f3n de la aplicaci\u00f3n se reduce a dos.<\/p>\n

Las cinco r\u00e9plicas solo se pueden distribuir en dos nodos, y si uno de ellos falla, inmediatamente se desactivan varias r\u00e9plicas.<\/p>\n

Si tiene cinco nodos o m\u00e1s, cada r\u00e9plica se ejecutar\u00e1 en un nodo diferente, y la falla de un nodo eliminar\u00e1 como m\u00e1ximo una r\u00e9plica.<\/p>\n

Por lo tanto, los requisitos de alta disponibilidad pueden requerir un n\u00famero m\u00ednimo espec\u00edfico de nodos en el cl\u00faster.<\/p>\n

Desventaja N\u00ba 3. Peores consecuencias en caso de falla<\/b>
\nCon un n\u00famero reducido de nodos, cada falla tiene consecuencias m\u00e1s graves. Por ejemplo, si solo tiene dos nodos y uno de ellos falla, desaparece de inmediato la mitad de sus m\u00f3dulos.<\/p>\n

Por supuesto, Kubernetes trasladar\u00e1 la carga de trabajo del nodo fallido a otros. Pero si son pocos, puede que no haya suficiente capacidad disponible. Como resultado, parte de sus aplicaciones no estar\u00e1n disponibles hasta que restablezca el nodo fallido.<\/p>\n

Por lo tanto, cuanto m\u00e1s nodos haya, menor ser\u00e1 el impacto de los fallos de hardware.<\/p>\n

Desventaja N\u00ba 4. M\u00e1s pasos de autoescalado<\/b>
\nEn Kubernetes, funciona un sistema de escalado autom\u00e1tico del cl\u00faster para la infraestructura en la nube, lo que permite agregar o eliminar nodos autom\u00e1ticamente seg\u00fan las necesidades actuales. Con nodos m\u00e1s grandes, el escalado se vuelve m\u00e1s abrupto y torpe. Por ejemplo, al agregar un nodo adicional a dos nodos, la capacidad del cl\u00faster aumentar\u00e1 de inmediato en un 50%. Y tendr\u00e1s que pagar por esos recursos, incluso si no los necesitas.<\/p>\n

Por lo tanto, si planeas utilizar la escalabilidad autom\u00e1tica del cl\u00faster, cuanto m\u00e1s peque\u00f1os sean los nodos, m\u00e1s flexible y econ\u00f3mica ser\u00e1 la escalabilidad que obtendr\u00e1s.<\/p>\n

Ahora consideremos las ventajas y desventajas de tener una gran cantidad de nodos peque\u00f1os.<\/p>\n

Segunda opci\u00f3n: muchos nodos peque\u00f1os<\/h2>\n

\nLas ventajas de este enfoque surgen esencialmente de las desventajas de la opci\u00f3n opuesta de tener unos pocos nodos grandes.<\/p>\n

Ventajas<\/h3>\n

\nVentaja n\u00famero 1. Menor impacto de fallos<\/b>
\nCuantos m\u00e1s nodos haya, menos pods habr\u00e1 en cada nodo. Por ejemplo, si tienes cien m\u00f3dulos en diez nodos, en promedio habr\u00e1 diez m\u00f3dulos en cada nodo.<\/p>\n

Por lo tanto, si uno de los nodos falla, solo perder\u00e1s el 10% de la carga de trabajo. Existe la posibilidad de que solo un peque\u00f1o n\u00famero de r\u00e9plicas se vea afectado, mientras que las aplicaciones en general permanecen operativas.<\/p>\n

Adem\u00e1s, en los nodos restantes, es probable que haya suficientes recursos libres para la carga de trabajo del nodo que fall\u00f3, por lo que Kubernetes puede reprogramar los pods f\u00e1cilmente, y tus aplicaciones volver\u00e1n a funcionar relativamente r\u00e1pido.<\/p>\n

Ventaja n\u00famero 2. Buena replicaci\u00f3n<\/b>
\nSi hay suficientes nodos, el programador de Kubernetes puede asignar r\u00e9plicas diferentes a distintos nodos. As\u00ed, en caso de fallo de un nodo, solo se ver\u00e1 afectada una r\u00e9plica, y la aplicaci\u00f3n seguir\u00e1 estando disponible.<\/p>\n

Desventajas <\/h3>\n

\nDesventaja n\u00famero 1. Dificultad en la gesti\u00f3n<\/b>
\nEs m\u00e1s dif\u00edcil gestionar un gran n\u00famero de nodos. Por ejemplo, cada nodo de Kubernetes debe interactuar con todos los dem\u00e1s, lo que significa que el n\u00famero de conexiones crece de forma cuadr\u00e1tica, y todas estas conexiones deben mantenerse bajo control.<\/p>\n

El controlador de nodos en el administrador de controladores de Kubernetes revisa regularmente todos los nodos en el cl\u00faster para verificar su estado; cuanto m\u00e1s nodos haya, mayor ser\u00e1 la carga sobre el controlador.<\/p>\n

La carga tambi\u00e9n aumenta en la base de datos etcd; cada kubelet y kube-proxy invoca watcher<\/a><\/noindex> para etcd (a trav\u00e9s de API), al que etcd debe transmitir actualizaciones del objeto.<\/p>\n

En general, cada nodo de trabajo impone una carga adicional en los componentes del nodo maestro.<\/p>\n

\"Nodos
\nOficialmente, Kubernetes admite cl\u00fasteres con hasta 5000 nodos.<\/a><\/noindex>Sin embargo, en la pr\u00e1ctica, ya 500 nodos pueden causar problemas no triviales.<\/a><\/noindex>.<\/p>\n

Para gestionar un gran n\u00famero de nodos de trabajo, se deben seleccionar nodos maestros m\u00e1s potentes. Por ejemplo, kube-up instala autom\u00e1ticamente<\/a><\/noindex> el tama\u00f1o correcto de VM para el nodo maestro en funci\u00f3n del n\u00famero de nodos de trabajo. Es decir, cuanto m\u00e1s nodos de trabajo haya, m\u00e1s potentes deben ser los nodos maestros. <\/p>\n

Para abordar estos problemas espec\u00edficos, existe un desarrollo especial como el Virtual Kubelet.<\/a><\/noindex>Este sistema permite sortear las limitaciones y construir cl\u00fasteres con un n\u00famero enorme de nodos de trabajo.<\/p>\n

Desventaja n\u00ba 2. M\u00e1s sobrecarga.<\/b>
\nEn cada nodo de trabajo, Kubernetes ejecuta un conjunto de demonios del sistema: estos incluyen el entorno de ejecuci\u00f3n de contenedores (como Docker), kube-proxy y kubelet, incluido cAdvisor. Todos juntos consumen una cantidad fija de recursos.<\/p>\n

Si tienes muchos nodos peque\u00f1os, la parte de esta sobrecarga en cada nodo es mayor. Por ejemplo, imagina que todos los demonios del sistema de un nodo usan juntos 0,1 n\u00facleos de CPU y 0,1 GB de memoria. Si tienes un nodo de diez n\u00facleos con 10 GB de memoria, los demonios consumen el 1% de la capacidad del cl\u00faster. Por otro lado, en diez nodos de un n\u00facleo con 1 GB de memoria, los demonios se llevar\u00e1n el 10% de la capacidad del cl\u00faster.<\/p>\n

Por lo tanto, cuanto menos nodos haya, m\u00e1s eficiente se utiliza la infraestructura.<\/p>\n

Desventaja n\u00ba 3. Uso ineficiente de recursos.<\/b>
\nEn nodos peque\u00f1os puede ocurrir que los fragmentos restantes de recursos sean demasiado peque\u00f1os para asignarles alguna carga de trabajo, por lo que permanecen sin usar.<\/p>\n

Por ejemplo, cada pod requiere 0,75 GB de memoria. Si tienes diez nodos, y en cada uno 1 GB de memoria, puedes ejecutar diez pods; al final, quedar\u00e1 0,25 GB de memoria no utilizada en cada nodo.<\/p>\n

Esto significa que el 25% de la memoria de todo el cl\u00faster se desperdicia.<\/p>\n

En un nodo grande con 10 GB de memoria, puedes ejecutar 13 de estos m\u00f3dulos, y solo quedar\u00e1 un fragmento no utilizado de 0,25 GB.<\/p>\n

En este caso, solo se desperdicia el 2,5% de la memoria.<\/p>\n

De este modo, los recursos se utilizan de manera m\u00e1s eficiente en los nodos grandes.<\/p>\n

\u00bfVarios nodos grandes o muchos peque\u00f1os?<\/h2>\n

\nEntonces, \u00bfcu\u00e1l es mejor: varios nodos grandes en un cl\u00faster o muchos peque\u00f1os? Como siempre, no hay una respuesta clara. Mucho depende del tipo de aplicaci\u00f3n.<\/p>\n

Por ejemplo, si una aplicaci\u00f3n requiere 10 GB de memoria, la elecci\u00f3n obvia son los nodos grandes. Pero si la aplicaci\u00f3n requiere replicaci\u00f3n diez veces para alta disponibilidad, probablemente no valga la pena arriesgarse a colocar r\u00e9plicas en solo dos nodos: debe haber al menos diez nodos en el cl\u00faster.<\/p>\n

En situaciones intermedias, elija seg\u00fan las ventajas y desventajas de cada opci\u00f3n. Tal vez algunos argumentos sean m\u00e1s relevantes para su situaci\u00f3n que otros.<\/p>\n

Y no es necesario que todos los nodos sean del mismo tama\u00f1o. No hay nada que impida experimentar primero con nodos de un tama\u00f1o, y luego a\u00f1adir nodos de otro tama\u00f1o, combin\u00e1ndolos en el cl\u00faster. Los nodos de trabajo de un cl\u00faster de Kubernetes pueden ser completamente heterog\u00e9neos. As\u00ed que puede intentar combinar las ventajas de ambos enfoques.<\/p>\n

No existe una receta \u00fanica, y cada situaci\u00f3n tiene sus matices, y solo el entorno de producci\u00f3n mostrar\u00e1 la verdad.<\/p>\n

La traducci\u00f3n fue preparada por el equipo de la plataforma en la nube. Soluciones en la Nube de Mail.ru<\/a><\/noindex>.<\/i><\/p>\n

M\u00e1s sobre Kubernetes: 25 herramientas \u00fatiles para gestionar y desplegar cl\u00fasteres.<\/a><\/noindex>.<\/p>\n

Fuente: 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\udd47 Nodos de trabajo de Kubernetes: \u00bfmuchos peque\u00f1os o varios grandes? | ProHoster","description":"Al crear un cl\u00faster.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}