Al crear un clúster de Kubernetes pueden surgir preguntas: ¿cuántos nodos de trabajo configurar y de qué tipo? ¿Qué es mejor para un clúster on-premise: comprar varios servidores potentes o utilizar una docena de máquinas antiguas en su centro de datos? ¿Y en la nube, es mejor elegir ocho instancias de un solo núcleo o dos de cuatro núcleos?
Las respuestas a estas preguntas están en el artículo en la traducción del equipo .
Capacidad del clúster
En general, un clúster de Kubernetes puede verse como un gran 'supernodo'. Su potencia computacional total es la suma de las potencias de todos los nodos componentes.
Existen varias formas de alcanzar la capacidad objetivo deseada del clúster. Por ejemplo, necesitamos un clúster con una capacidad total de 8 núcleos 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úcleos o cuatro de dos núcleos.
Aquí hay solo dos formas posibles de crear un clúster:
Ambas opciones dan como resultado un clúster con la misma capacidad, pero en la configuración inferior se establecen cuatro nodos más pequeños, mientras que en la configuración superior hay dos nodos más grandes.
¿Cuál opción es mejor?
Para responder a esta pregunta, consideremos las ventajas de ambas opciones. Las hemos resumido en una tabla.
Varios nodos grandes
Muchos nodos pequeños
Más fácil administrar el clúster (si es on-premise)
Escalado automático fluido
Más económico (si es on-premise)
El precio es poco diferente (en la nube)
Se pueden ejecutar aplicaciones que consumen muchos recursos
Replicación completa
Los recursos se utilizan de manera más eficiente (menos sobrecarga por demonios del sistema)
Mayor resistencia a fallos del clúster
Tenga en cuenta que solo estamos hablando de nodos de trabajo. La elección de la cantidad y tamaño de los nodos maestros es un tema completamente diferente.
Así que analicemos en detalle cada punto de la tabla.
Primera opción: varios nodos grandes
La opción más extrema sería tener un solo nodo de trabajo para toda la capacidad del clúster. En el ejemplo anterior, esto sería un solo nodo de trabajo con 16 núcleos de CPU y 16 GB de RAM.
Ventajas
Ventaja #1. Más fácil de administrar
Es más fácil gestionar varias máquinas que todo un parque. Las actualizaciones y correcciones se aplican más rápidamente y es más sencillo sincronizar. La cantidad de fallos en cifras absolutas también es menor.
Tenga en cuenta que todo lo anterior se refiere a su propio hardware, a sus propios servidores, no a instancias en la nube.
En la nube la situación es diferente. Allí, la gestión está a cargo del proveedor de servicios en la nube. Así, gestionar diez nodos en la nube no es significativamente diferente de gestionar un solo nodo.
La ruta del tráfico y la distribución de la carga entre los pods en la nube : el tráfico entrante de Internet se dirige al equilibrador de carga principal, que a su vez envía el tráfico al puerto de uno de los nodos (el servicio NodePort asigna un puerto en el rango de 30000-32767 en cada nodo del clúster). Las reglas establecidas por kube-proxy redirigen el tráfico del nodo al pod. Así es como se ve para diez pods en dos nodos:
Ventaja nº 2. Menores costos por nodo
Una máquina potente es más cara, pero el aumento de precio no necesariamente es lineal. En otras palabras, un servidor de diez núcleos con 10 GB de RAM suele ser más barato que diez servidores de un núcleo con la misma cantidad de RAM.
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.
Por lo tanto, en la nube normalmente no se puede ahorrar en servidores más potentes.
Ventaja nº 3. Se pueden ejecutar aplicaciones que consumen muchos recursos
Algunas aplicaciones requieren servidores potentes en el clúster. Por ejemplo, si un sistema de aprendizaje automático requiere 8 GB de RAM, no podrá ejecutarlo en nodos de 1 GB, solo con al menos un nodo de trabajo grande.
Desventajas
Desventaja nº 1. Muchos pods por nodo
Si la misma tarea se ejecuta en un menor número de nodos, naturalmente habrá más pods en cada uno de ellos.
Esto puede convertirse en un problema.
La razón es que cada módulo introduce ciertos costes en el entorno de ejecución del contenedor (por ejemplo, Docker), así como kubelet y cAdvisor.
Por ejemplo, kubelet sondea regularmente la disponibilidad de todos los contenedores en el nodo; cuanto más contenedores haya, más trabajo tiene kubelet.
CAdvisor recopila estadísticas del uso de recursos de todos los contenedores en el nodo, y kubelet consulta esta información regularmente y la proporciona a través de la API. De nuevo, cuántos más contenedores, más trabajo hay tanto para cAdvisor como para kubelet.
Si el número de módulos aumenta, esto puede ralentizar el sistema e incluso comprometer su confiabilidad.
En el repositorio de Kubernetes, algunos , 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.
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 su funcionamiento con antelación.
Desventaja Nº 2. Limitación en la replicación
Demasiados pocos nodos limitan el grado efectivo de replicación de las aplicaciones. Por ejemplo, si tiene una aplicación de alta disponibilidad con cinco réplicas, pero solo dos nodos, entonces el grado efectivo de replicación de la aplicación se reduce a dos.
Las cinco réplicas solo se pueden distribuir en dos nodos, y si uno de ellos falla, inmediatamente se desactivan varias réplicas.
Si tiene cinco nodos o más, cada réplica se ejecutará en un nodo diferente, y la falla de un nodo eliminará como máximo una réplica.
Por lo tanto, los requisitos de alta disponibilidad pueden requerir un número mínimo específico de nodos en el clúster.
Desventaja Nº 3. Peores consecuencias en caso de falla
Con un número reducido de nodos, cada falla tiene consecuencias más graves. Por ejemplo, si solo tiene dos nodos y uno de ellos falla, desaparece de inmediato la mitad de sus módulos.
Por supuesto, Kubernetes trasladará 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án disponibles hasta que restablezca el nodo fallido.
Por lo tanto, cuanto más nodos haya, menor será el impacto de los fallos de hardware.
Desventaja Nº 4. Más pasos de autoescalado
En Kubernetes, funciona un sistema de escalado automático del clúster para la infraestructura en la nube, lo que permite agregar o eliminar nodos automáticamente según las necesidades actuales. Con nodos más grandes, el escalado se vuelve más abrupto y torpe. Por ejemplo, al agregar un nodo adicional a dos nodos, la capacidad del clúster aumentará de inmediato en un 50%. Y tendrás que pagar por esos recursos, incluso si no los necesitas.
Por lo tanto, si planeas utilizar la escalabilidad automática del clúster, cuanto más pequeños sean los nodos, más flexible y económica será la escalabilidad que obtendrás.
Ahora consideremos las ventajas y desventajas de tener una gran cantidad de nodos pequeños.
Segunda opción: muchos nodos pequeños
Las ventajas de este enfoque surgen esencialmente de las desventajas de la opción opuesta de tener unos pocos nodos grandes.
Ventajas
Ventaja número 1. Menor impacto de fallos
Cuantos más nodos haya, menos pods habrá en cada nodo. Por ejemplo, si tienes cien módulos en diez nodos, habrá un promedio de diez módulos en cada nodo.
Por lo tanto, si uno de los nodos falla, solo perderás el 10% de la carga de trabajo. Existe la posibilidad de que solo un pequeño número de réplicas se vea afectado, mientras que las aplicaciones en general permanecen operativas.
Además, es probable que en los nodos restantes haya suficientes recursos libres para la carga de trabajo del nodo fallido, por lo que Kubernetes puede reprogramar los pods libremente, y tus aplicaciones volverán a funcionar relativamente rápido.
Ventaja número 2. Buena replicación
Si hay suficientes nodos, el programador de Kubernetes puede asignar réplicas diferentes a distintos nodos. Así, en caso de fallo de un nodo, solo se verá afectada una réplica, y la aplicación seguirá estando disponible.
Desventajas
Desventaja número 1. Dificultad en la gestión
Es más difícil gestionar un gran número de nodos. Por ejemplo, cada nodo de Kubernetes debe interactuar con todos los demás, lo que significa que el número de conexiones crece de forma cuadrática, y todas estas conexiones deben mantenerse bajo control.
El controlador de nodos en el administrador de controladores de Kubernetes revisa regularmente todos los nodos en el clúster para verificar su estado; cuanto más nodos haya, mayor será la carga sobre el controlador.
La carga también aumenta en la base de datos etcd; cada kubelet y kube-proxy invoca para etcd (a través de API), al que etcd debe transmitir actualizaciones del objeto.
En general, cada nodo de trabajo impone una carga adicional en los componentes del nodo maestro.
Oficialmente, Kubernetes admite clústeres con Sin embargo, en la práctica, ya 500 nodos .
Para gestionar un gran número de nodos de trabajo, se deben seleccionar nodos maestros más potentes. Por ejemplo, kube-up el tamaño correcto de VM para el nodo maestro en función del número de nodos de trabajo. Es decir, cuanto más nodos de trabajo haya, más potentes deben ser los nodos maestros.
Para abordar estos problemas específicos, existe un desarrollo especial como el Este sistema permite sortear las limitaciones y construir clústeres con un número enorme de nodos de trabajo.
Desventaja nº 2. Más sobrecarga.
En cada nodo de trabajo, Kubernetes ejecuta un conjunto de demonios del sistema: estos incluyen el entorno de ejecución de contenedores (como Docker), kube-proxy y kubelet, incluido cAdvisor. Todos juntos consumen una cantidad fija de recursos.
Si tienes muchos nodos pequeños, 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úcleos de CPU y 0,1 GB de memoria. Si tienes 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 núcleo con 1 GB de memoria, los demonios se llevarán el 10% de la capacidad del clúster.
Por lo tanto, cuanto menos nodos haya, más eficiente se utiliza la infraestructura.
Desventaja nº 3. Uso ineficiente de recursos.
En nodos pequeños puede ocurrir que los fragmentos restantes de recursos sean demasiado pequeños para asignarles alguna carga de trabajo, por lo que permanecen sin usar.
Por ejemplo, cada pod requiere 0,75 GB de memoria. Si tienes diez nodos, y en cada uno hay 1 GB de memoria, puedes ejecutar diez pods; al final, cada nodo tendrá 0,25 GB de memoria no utilizada.
Esto significa que el 25% de la memoria de todo el clúster se desperdicia.
En un nodo grande con 10 GB de memoria, puedes ejecutar 13 de estos módulos, y solo quedará un fragmento no utilizado de 0,25 GB.
En este caso, solo se desperdicia el 2,5% de la memoria.
De este modo, los recursos se utilizan de manera más eficiente en los nodos grandes.
¿Varios nodos grandes o muchos pequeños?
Entonces, ¿cuál es mejor: varios 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, la elección obvia son los nodos grandes. Pero si la aplicación requiere replicación diez veces para alta disponibilidad, probablemente no valga la pena arriesgarse a colocar réplicas en solo dos nodos: debe haber al menos diez nodos en el clúster.
En situaciones intermedias, elija según las ventajas y desventajas de cada opción. Tal vez 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. No hay nada que impida experimentar primero con nodos de un tamaño, y luego añadir nodos de otro tamaño, combinándolos en el clúster. Los nodos de trabajo de un clúster de Kubernetes pueden ser completamente heterogéneos. Así que puede intentar combinar las ventajas de ambos enfoques.
No existe una receta única, y cada situación tiene sus matices, y solo el entorno de producción mostrará la verdad.
La traducción fue preparada por el equipo de la plataforma en la nube. .
Más sobre Kubernetes: .
Fuente: habr.com
