Al crear un clúster de Kubernetes, pueden surgir preguntas: ¿cuántos nodos trabajadores configurar y de qué tipo? ¿Qué es mejor para un clúster local: comprar varios servidores potentes o utilizar una docena de máquinas antiguas en su centro de datos? ¿Es mejor tener ocho instancias de un solo núcleo o dos de cuatro núcleos en la nube?
Las respuestas a estas preguntas están en el artículo. en la traducción del comando .
Capacidad del clúster
En general, se puede considerar un clúster de Kubernetes como un gran "supernodo". Su potencia informática total es la suma de las potencias de todos sus nodos constituyentes.
Hay varias formas de lograr el objetivo de capacidad de clúster deseado. Por ejemplo, necesitamos un clúster con una capacidad total de 8 núcleos de procesador y 32 GB de RAM porque un conjunto de aplicaciones requiere muchos recursos. Luego podrás instalar dos nodos con 16 GB de memoria o cuatro nodos con 8 GB de memoria, dos procesadores de cuatro núcleos o cuatro de doble núcleo.
Estas son solo dos formas posibles de crear un clúster:
Ambas opciones producen un clúster con la misma capacidad, pero la configuración inferior tiene cuatro nodos más pequeños y la configuración superior tiene dos nodos más grandes.
¿Qué opción es mejor?
Para responder a esta pregunta, veamos las ventajas de ambas opciones. Los hemos resumido en una tabla.
Varios nodos grandes
Muchos nodos pequeños
Gestión de clústeres más sencilla (si es local)
Escalado automático fluido
Más barato (si es local)
El precio es un poco diferente (en la nube)
Puede ejecutar aplicaciones que consumen muchos recursos
Replicación completa
Los recursos se utilizan de manera más eficiente (menos gastos generales en los demonios del sistema).
Mayor tolerancia a fallos del clúster
Tenga en cuenta que solo estamos hablando de nodos trabajadores. Elegir el número y tamaño de los nodos principales es un tema completamente diferente.
Entonces, analicemos cada punto de la tabla con más detalle.
Primera opción: varios nodos grandes.
La opción más extrema es un nodo trabajador para toda la capacidad del clúster. En el ejemplo anterior, este sería un nodo trabajador único con 16 núcleos de CPU y 16 GB de RAM.
Pros
Plus No. 1. Gestión más sencilla
Es más fácil gestionar unas pocas máquinas que una flota completa. Es más rápido implementar actualizaciones y correcciones, y es más fácil de sincronizar. El número de fracasos en números absolutos también es menor.
Tenga en cuenta que todo lo anterior se aplica a su hardware, sus servidores y no a las instancias en la nube.
La situación es diferente en la nube. Allí, la gestión la realiza el proveedor de servicios en la nube. Por tanto, gestionar diez nodos en la nube no es muy diferente de gestionar un nodo.
Enrutamiento del tráfico y distribución de carga entre pods en la nube : el tráfico proveniente de Internet se envía al balanceador de carga principal, que reenvía el tráfico al puerto de uno de los nodos (el servicio NodePort establece el puerto en el rango 30000-32767 en cada nodo del clúster). Las reglas establecidas por kube-proxy redirigen el tráfico desde el nodo al pod. Así es como se ve para diez pods en dos nodos:
Pro #2: Menos costo por nodo
Un coche potente es más caro, pero el aumento de precio no es necesariamente lineal. En otras palabras, un servidor de diez núcleos con 10 GB de memoria suele ser más barato que diez servidores de un solo núcleo con la misma cantidad de memoria.
Pero tenga en cuenta que esta regla no suele funcionar en los servicios en la nube. En los esquemas de precios actuales de los principales proveedores de nube, los precios aumentan linealmente con la capacidad.
Por tanto, en la nube normalmente no se puede guardar en servidores más potentes.
Ventaja n.° 3: puede ejecutar aplicaciones que consumen muchos recursos
Algunas aplicaciones requieren servidores potentes en un clúster. Por ejemplo, si un sistema de aprendizaje automático requiere 8 GB de memoria, no podrá ejecutarlo en nodos de 1 GB, sino solo con al menos un nodo trabajador grande.
Contras
Desventaja número 1. Muchos pods por nodo
Si la misma tarea se realiza en menos nodos, entonces, naturalmente, cada uno de ellos tendrá más pods.
Esto podría ser un problema.
La razón es que cada módulo introduce cierta sobrecarga en el tiempo de ejecución del contenedor (por ejemplo, Docker), así como en kubelet y cAdvisor.
Por ejemplo, un kubelet comprueba periódicamente la capacidad de supervivencia de todos los contenedores de un nodo: cuantos más contenedores, más trabajo tiene que hacer el kubelet.
CAdvisor recopila estadísticas de uso de recursos para todos los contenedores de un nodo y kubelet consulta periódicamente esta información y la proporciona a través de una API. Nuevamente, más contenedores significan más trabajo tanto para cAdvisor como para kubelet.
Si aumenta el número de módulos, puede ralentizar el sistema e incluso socavar su fiabilidad.
En el repositorio de Kubernetes algunos que los nodos saltan entre estados Listo/No listo porque las comprobaciones regulares de kubelet de todos los contenedores en un nodo toman demasiado tiempo.
Por esta razón Kubernetes . Dependiendo del rendimiento del nodo, puede ejecutar más pods por nodo, pero es difícil predecir si habrá problemas o si todo funcionará bien. Vale la pena probar el trabajo con antelación.
Desventaja número 2. Limitación de la replicación
Muy pocos nodos limitan el alcance efectivo de la replicación de aplicaciones. Por ejemplo, si tiene una aplicación de alta disponibilidad con cinco réplicas pero solo dos nodos, el grado efectivo de replicación de la aplicación se reduce a dos.
Solo se pueden distribuir cinco réplicas en dos nodos y, si uno de ellos falla, desactiva varias réplicas a la vez.
Si tiene cinco nodos o más, cada réplica se ejecutará en un nodo independiente y la falla de un nodo eliminará como máximo una réplica.
Por lo tanto, los requisitos de alta disponibilidad pueden requerir una cierta cantidad mínima de nodos en el clúster.
Desventaja número 3. Peores consecuencias del fracaso
Con un número reducido de nodos, cada fallo tiene consecuencias más graves. Por ejemplo, si sólo tienes dos nodos y uno de ellos falla, la mitad de tus módulos desaparecen inmediatamente.
Por supuesto, Kubernetes migrará la carga de trabajo del nodo fallido a otros. Pero si hay pocos, es posible que no haya suficiente capacidad libre. Como resultado, algunas de sus aplicaciones no estarán disponibles hasta que abra el nodo fallido.
Por tanto, cuantos más nodos, menor será el impacto de los fallos de hardware.
Desventaja n.º 4: más pasos de escalado automático
Kubernetes tiene un sistema de escalamiento automático de clústeres para infraestructura en la nube, que le permite agregar o eliminar nodos automáticamente según sus necesidades actuales. Con nodos más grandes, el ajuste de escala automático se vuelve más abrupto y torpe. Por ejemplo, en dos nodos, agregar un nodo adicional aumentará inmediatamente la capacidad del clúster en un 50 %. Y tendrás que pagar por esos recursos, incluso si no los necesitas.
Por lo tanto, si planea utilizar el escalado automático de clústeres, cuanto más pequeños sean los nodos, más flexible y rentable obtendrá el escalado.
Ahora veamos las ventajas y desventajas de una gran cantidad de nodos pequeños.
Segunda opción: muchos nodos pequeños
Las ventajas de este enfoque se derivan esencialmente de las desventajas de la opción opuesta con varios nodos grandes.
Pros
Pro #1: Menos impacto del fracaso
Cuantos más nodos, menos pods habrá en cada nodo. Por ejemplo, si tiene cien módulos por cada diez nodos, cada nodo tendrá un promedio de diez módulos.
De esta forma, si uno de los nodos falla, solo se pierde el 10% de la carga de trabajo. Lo más probable es que solo una pequeña cantidad de réplicas se vean afectadas y la aplicación general siga operativa.
Además, es probable que los nodos restantes tengan suficientes recursos libres para manejar la carga de trabajo del nodo fallido, por lo que Kubernetes puede reprogramar libremente los pods y sus aplicaciones volverán a un estado funcional con relativa rapidez.
Pro #2: Buena replicación
Si hay suficientes nodos, el programador de Kubernetes puede asignar diferentes nodos a todas las réplicas. De esta forma, si un nodo falla, solo una réplica se verá afectada y la aplicación seguirá disponible.
Contras
Desventaja número 1. Difícil de controlar
Un gran número de nodos es más difícil de gestionar. Por ejemplo, cada nodo de Kubernetes debe comunicarse con todos los demás, es decir, el número de conexiones crece cuadráticamente y es necesario realizar un seguimiento de todas estas conexiones.
El controlador de nodos en Kubernetes Controller Manager recorre periódicamente todos los nodos del clúster para comprobar su estado: cuantos más nodos, más carga tendrá el controlador.
La carga en la base de datos etcd también está creciendo: cada llamada de kubelet y kube-proxy para etcd (a través de la API), al cual etcd debería transmitir actualizaciones de objetos.
En general, cada nodo trabajador impone una carga adicional a los componentes del sistema de los nodos maestros.
Kubernetes admite oficialmente clústeres con . Sin embargo, en la práctica ya existen 500 nodos. .
Para gestionar una gran cantidad de nodos trabajadores, debe elegir nodos maestros más potentes. Por ejemplo, kube-up el tamaño correcto de VM para el nodo maestro dependiendo de la cantidad de nodos trabajadores. Es decir, cuantos más nodos trabajadores, más productivos deberían ser los nodos maestros.
Para solucionar estos problemas específicos existen desarrollos especiales, como por ejemplo . Este sistema le permite eludir las restricciones y crear clústeres con una gran cantidad de nodos trabajadores.
Desventaja #2: Más costos generales.
En cada nodo trabajador, Kubernetes ejecuta un conjunto de demonios del sistema: estos incluyen el tiempo de ejecución del contenedor (como Docker), kube-proxy y kubelet, incluido cAdvisor. Juntos consumen una determinada cantidad fija de recursos.
Si tiene muchos nodos pequeños, la proporción de esta sobrecarga en cada nodo es mayor. Por ejemplo, imagine que todos los demonios del sistema en un solo nodo usan juntos 0,1 núcleos de CPU y 0,1 GB de memoria. Si tiene un nodo de diez núcleos con 10 GB de memoria, los demonios consumen el 1% de la capacidad del clúster. Por otro lado, en diez nodos de un solo núcleo con 1 GB de memoria, los demonios ocuparán el 10% de la capacidad del clúster.
Por tanto, cuantos menos nodos, más eficientemente se utiliza la infraestructura.
Desventaja No. 3. Uso ineficiente de los recursos.
En nodos pequeños, puede ser que los fragmentos de recursos restantes sean demasiado pequeños para asignarles cualquier carga de trabajo, por lo que no se utilizan.
Por ejemplo, cada módulo requiere 0,75 GB de memoria. Si tiene diez nodos, cada uno con 1 GB de memoria, puede ejecutar diez pods, dejando a cada nodo con 0,25 GB de memoria sin utilizar.
Esto significa que se desperdicia el 25% de la memoria total del clúster.
En un nodo grande con 10 GB de memoria, puede ejecutar 13 de estos módulos, y solo quedará un fragmento no utilizado de 0,25 GB.
En este caso, sólo se desperdicia el 2,5% de la memoria.
Por tanto, los recursos se utilizan de forma más óptima en nodos más grandes.
¿Varios nodos grandes o muchos pequeños?
Entonces, ¿qué es mejor: unos pocos nodos grandes en un clúster o muchos pequeños? Como siempre, no hay una respuesta clara. Mucho depende del tipo de aplicación.
Por ejemplo, si una aplicación requiere 10 GB de memoria, los nodos más grandes son una opción obvia. Y si la aplicación requiere una replicación diez veces mayor para lograr alta disponibilidad, no vale la pena correr el riesgo de colocar réplicas en solo dos nodos: debe haber un mínimo de diez nodos en el clúster.
En situaciones intermedias, elija basándose en las ventajas y desventajas de cada opción. Quizás algunos argumentos sean más relevantes para su situación que otros.
Y no es necesario que todos los nodos sean del mismo tamaño. Nada le impide experimentar primero con nodos del mismo tamaño y luego agregarles nodos de diferente tamaño y combinarlos en un grupo. Los nodos trabajadores en un clúster de Kubernetes pueden ser completamente heterogéneos. Así que puedes intentar combinar las ventajas de ambos enfoques.
No existe una receta única, cada situación tiene sus propios matices y sólo la producción mostrará la verdad.
Traducción preparada por el equipo de la plataforma en la nube. .
Más sobre Kubernetes: .
Fuente: habr.com