🌊 🛌🏿 🤮 Diseño de clústeres de Kubernetes: ¿cuántos debería haber? 🤥 🤸🏻 👲🏾

Nota perev. : Este material del proyecto educativo learnk8s es la respuesta a una pregunta popular al diseñar infraestructura basada en Kubernetes. Esperamos que las descripciones suficientemente detalladas de los pros y los contras de cada opción le ayuden a tomar la mejor decisión para su proyecto.

TL; DR : el mismo conjunto de cargas de trabajo se puede ejecutar en varios grupos grandes (cada grupo tendrá una gran cantidad de cargas de trabajo) o en muchos pequeños (con una pequeña cantidad de cargas en cada grupo).

La siguiente tabla resume los pros y los contras de cada enfoque:

Cuando se usa Kubernetes como plataforma para operar aplicaciones, a menudo surgen varias preguntas fundamentales sobre las complejidades de la configuración del clúster:

¿Cuántos grupos usar?
¿Qué tan grandes hacen?
¿Qué debe incluir cada grupo?

En este artículo, trataré de responder todas estas preguntas analizando los pros y los contras de cada enfoque.

Declaración de una pregunta

Como creador de software, es probable que desarrolle y opere muchas aplicaciones en paralelo.

Además, es probable que muchas instancias de estas aplicaciones se ejecuten en varios entornos; por ejemplo, puede ser dev , test y prod .

El resultado es una matriz completa de aplicaciones y entornos:

aplicaciones y entornos

En el ejemplo anterior, se presentan 3 aplicaciones y 3 entornos, lo que finalmente ofrece 9 opciones posibles.

Cada instancia de aplicación es una unidad de implementación autónoma que se puede operar independientemente de otras.

Tenga en cuenta que una instancia de aplicación puede constar de muchos componentes.como frontend, backend, base de datos, etc. En el caso de una aplicación de microservicio, la instancia incluirá todos los microservicios.

Como resultado, los usuarios de Kubernetes tienen varias preguntas:

¿Debo colocar todas las instancias de la aplicación en un clúster?
¿Debo crear un clúster separado para cada instancia de la aplicación?
¿O tal vez debería usar una combinación de los enfoques anteriores?

Todas estas opciones son bastante viables, porque Kubernetes es un sistema flexible que no limita las posibilidades del usuario.

Estas son algunas de las formas posibles:

un gran grupo común;
muchos pequeños grupos altamente especializados;
un clúster para cada aplicación;
Un grupo para cada entorno.

Como se muestra a continuación, los dos primeros enfoques están en los extremos opuestos de la escala de opciones:

desde varios grupos grandes (a la izquierda) a muchos pequeños (a la derecha).

En general, un grupo se considera "más grande" que el otro si tiene una suma mayor de nodos y vainas. Por ejemplo, un clúster con 10 nodos y 100 pods es más grande que un clúster con 1 nodo y 10 pods.

Bueno, empecemos!

1. Un gran grupo común

La primera opción es colocar todas las cargas de trabajo en un clúster:

un clúster grande

Como parte de este enfoque, el clúster se utiliza como una plataforma de infraestructura universal : simplemente despliega todo lo que necesita en un clúster Kubernetes existente.

Namespace'y Kubernetes permite separar lógicamente parte del clúster entre sí, de modo que su espacio de nombre se puede utilizar para cada instancia de la aplicación.

Veamos los pros y los contras de este enfoque.

+ Uso eficiente de los recursos.

En el caso de un solo clúster, solo se necesita una copia de todos los recursos necesarios para iniciar y administrar el clúster de Kubernetes.

Por ejemplo, esto es cierto para los nodos maestros. Por lo general, hay 3 nodos maestros para cada grupo de Kubernetes, por lo que para un solo grupo su número seguirá siendo así (en comparación, 10 grupos necesitarán 30 nodos maestros).

La sutileza anterior se aplica a otros servicios que operan en todo el clúster, como los equilibradores de carga, los controladores de ingreso, los sistemas de autenticación, registro y monitoreo.

En un solo clúster, todos estos servicios se pueden usar inmediatamente para todas las cargas de trabajo (no es necesario crear copias de ellos, como en el caso de varios clústeres).

+ Barato

Como consecuencia de lo anterior, un número menor de grupos suele ser más barato porque no hay costos por el exceso de recursos.

Esto es especialmente cierto para los nodos maestros, que pueden costar mucho dinero independientemente del método de ubicación (local o en la nube).

Algunos servicios gestionados de Kubernetes, como Google Kubernetes Engine (GKE) o Azure Kubernetes Service (AKS) , proporcionan una capa de control de forma gratuita. En este caso, el problema del costo es menos agudo.

También hay servicios administrados que cobran una tarifa fija por cada clúster de Kubernetes (por ejemplo, Amazon Elastic Kubernetes Service, EKS ).

+ Administración efectiva

Administrar un solo clúster es más fácil que varios.

La administración puede incluir las siguientes tareas:

versión actualizada de Kubernetes;
Configuración de canalización de CI / CD
Instalación del complemento CNI;
configurar un sistema de autenticación de usuario;
ajuste del controlador de acceso;

y muchos otros ...

En el caso de un clúster, todo esto tendrá que hacerse solo una vez.

Para muchos grupos, las operaciones deberán repetirse muchas veces, lo que probablemente requerirá cierta automatización de procesos y herramientas para garantizar un proceso sistemático y uniforme.

Y ahora algunas palabras sobre los contras.

- Punto único de fallo

En el caso de un solo fallo de clúster, ¡ todas las cargas de trabajo dejarán de funcionar inmediatamente !

Hay toneladas de opciones cuando algo puede salir mal:

actualizar Kubernetes conduce a efectos secundarios inesperados;
el componente de todo el clúster (por ejemplo, el complemento CNI) no funciona como se esperaba;
Uno de los componentes del clúster no está configurado correctamente.
una falla en la infraestructura subyacente.

Uno de estos incidentes puede causar daños graves a todas las cargas de trabajo ubicadas en un clúster común.

- Falta de aislamiento duro

Trabajar en un clúster compartido significa que las aplicaciones comparten hardware, capacidades de red y el sistema operativo en los nodos del clúster.

En cierto sentido, dos contenedores con dos aplicaciones diferentes que se ejecutan en el mismo nodo son similares a dos procesos que se ejecutan en la misma máquina que ejecuta el mismo núcleo del sistema operativo.

Los contenedores de Linux proporcionan algún tipo de aislamiento, pero está lejos de ser tan fuerte como el que proporcionan, por ejemplo, las máquinas virtuales. En esencia, un proceso en un contenedor es el mismo proceso que se ejecuta en el sistema operativo host.

Esto puede ser un problema de seguridad: dicha organización teóricamente permite que aplicaciones no relacionadas interactúen entre sí (de manera intencional o accidental).

Además, todas las cargas de trabajo en el clúster de Kubernetes comparten algunos servicios de todo el clúster, como DNS , lo que permite que las aplicaciones encuentren los servicios de otras aplicaciones en el clúster.

Todos los elementos anteriores pueden tener significados diferentes según los requisitos de seguridad de la aplicación.

Kubernetes proporciona varias herramientas para evitar problemas de seguridad, como PodSecurityPolicies y NetworkPolicies . Sin embargo, para que su configuración adecuada requiera algo de experiencia, además, no pueden cerrar absolutamente todos los agujeros de seguridad.

Es importante recordar siempre que Kubernetes fue diseñado originalmente para compartir.y no por aislamiento y seguridad .

- Falta de multicliente apretado

Dada la abundancia de recursos compartidos en el clúster de Kubernetes, hay muchas maneras en que las diferentes aplicaciones pueden pisar sus talones.

Por ejemplo, una aplicación puede monopolizar un recurso compartido (como un procesador o memoria) y privar a otras aplicaciones que se ejecutan en el mismo nodo de acceso a él.

Kubernetes proporciona varios mecanismos para controlar este comportamiento, como solicitudes y límites de recursos (consulte también el artículo " Límites de CPU y aceleración agresiva en Kubernetes " - aprox. Transl.) , ResourceQuotas y LimitRanges . Sin embargo, como en el caso de la seguridad, su configuración es bastante trivial y no pueden evitar absolutamente todos los efectos secundarios imprevistos.

- Una gran cantidad de usuarios

En el caso de un solo clúster, muchas personas tienen que abrir el acceso a él. Y cuanto mayor sea su número, mayor es el riesgo de que "rompan algo".

Dentro del clúster, puede controlar quién y qué se puede hacer utilizando el control de acceso basado en roles (RBAC) (consulte el artículo " Autorización de usuarios y RBAC en Kubernetes " - transferencia aprox.) . Sin embargo, no evitará que los usuarios "rompan" algo dentro de los límites de su área de responsabilidad.

- Los grupos no pueden crecer indefinidamente

El clúster que se usa para todas las cargas de trabajo probablemente será bastante grande (en términos de la cantidad de nodos y pods).

Pero aquí surge otro problema: los grupos en Kubernetes no pueden crecer indefinidamente.

Hay un límite teórico sobre el tamaño del grupo. En Kubernetes, son aproximadamente 5,000 nodos, 150 mil vainas y 300 mil contenedores .

Sin embargo, en la vida real, los problemas pueden comenzar mucho antes, por ejemplo, en solo 500 nodos .

El hecho es que los grandes grupos ejercen una gran carga en la capa de control de Kubernetes. En otras palabras, para mantener el clúster operacional y usar los recursos de manera eficiente, se requiere un ajuste cuidadoso.

Este problema se explora en un artículo relacionado en el blog original titulado " Arquitectura de clústeres de Kubernetes: elección del tamaño de un nodo de trabajo ".

Pero veamos el enfoque opuesto: muchos grupos pequeños.

2. Muchos grupos pequeños y especializados

Con este enfoque, utiliza un clúster separado para cada elemento desplegable:

muchos clústeres pequeños

Para los fines de este artículo, un elemento desplegable se refiere a una instancia de una aplicación, por ejemplo, la versión de desarrollo de una aplicación separada.

Esta estrategia utiliza Kubernetes como un tiempo de ejecución especializado para instancias de aplicaciones individuales.

Veamos los pros y los contras de este enfoque.

+ "Radio de explosión" limitado

Cuando un clúster se descompone, las consecuencias negativas se limitan solo a las cargas de trabajo que se implementaron en este clúster. Todas las demás cargas de trabajo permanecen intactas.

+ Aislamiento

Las cargas de trabajo alojadas en clústeres individuales no comparten recursos como procesador, memoria, sistema operativo, red u otros servicios.

Como resultado, obtenemos un aislamiento estrecho entre aplicaciones no relacionadas, lo que puede afectar favorablemente su seguridad.

+ Pequeño número de usuarios

Dado que cada clúster contiene solo un conjunto limitado de cargas de trabajo, se reduce el número de usuarios con acceso a él.

Mientras menos personas tengan acceso al clúster, menor será el riesgo de que algo se "rompa".

Veamos los contras.

- Uso ineficiente de los recursos.

Como se mencionó anteriormente, cada clúster de Kubernetes requiere un cierto conjunto de recursos de control: nodos maestros, componentes de la capa de control y soluciones para monitoreo y registro.

En el caso de una gran cantidad de pequeños grupos, es necesario asignar una mayor parte de los recursos para la gestión.

- Alto costo

El uso ineficiente de los recursos conlleva automáticamente altos costos.

Por ejemplo, el mantenimiento de 30 nodos maestros en lugar de tres con la misma potencia informática necesariamente afectará los costos.

- dificultades de administración

Administrar varios clústeres de Kubernetes es mucho más difícil que administrar uno.

Por ejemplo, deberá configurar la autenticación y la autorización para cada clúster. La actualización de la versión de Kubernetes también tendrá que hacerse varias veces.

Lo más probable es que tenga que aplicar la automatización para aumentar la efectividad de todas estas tareas.

Ahora considere escenarios menos extremos.

3. Un clúster por aplicación

Como parte de este enfoque, crea un clúster separado para todas las instancias de una aplicación en particular:

Clúster por aplicación De

esta manera puede considerarse como una generalización del principio de " clúster separado por equipo ", ya que generalmente un equipo de ingenieros se dedica al desarrollo de una o más aplicaciones.

Veamos los pros y los contras de este enfoque.

+ Cluster se puede personalizar para la aplicación

Si la aplicación tiene necesidades especiales, se pueden implementar en un clúster sin afectar a otros clústeres.

Dichas necesidades pueden incluir trabajadores de GPU, complementos CNI específicos, mallas de servicio o algún otro servicio.

Cada clúster se puede adaptar a la aplicación que se ejecuta en él para que contenga solo lo que se necesita.

- Diferentes entornos en un clúster

La desventaja de este enfoque es que las instancias de aplicación de diferentes entornos coexisten en el mismo clúster.

Por ejemplo, la versión prod de la aplicación se ejecuta en el mismo clúster que la versión dev. También significa que los desarrolladores realizan sus actividades en el mismo clúster en el que se opera la versión de producción de la aplicación.

Si, debido a las acciones de los desarrolladores o problemas técnicos de la versión de desarrollo en el clúster, se produce un error, entonces la versión prod puede sufrir potencialmente, un gran inconveniente de este enfoque.

Y finalmente, el último guión de nuestra lista.

4. Un clúster para cada entorno.

Este escenario prevé la asignación de un clúster individual para cada ambiente:

Un grupo para el medio ambiente

, por ejemplo, puede tener dev , prueba y prod racimos en el que ejecutará todas las instancias de aplicaciones diseñadas para un entorno específico.

Aquí están los pros y los contras de este enfoque.

+ Aislamiento del entorno de producción

En este enfoque, todos los entornos están aislados unos de otros. Sin embargo, en la práctica, esto es especialmente importante para el entorno de producción.

Las versiones de producción de la aplicación ahora son independientes de lo que sucede en otros clústeres y entornos.

Por lo tanto, si surge un problema repentinamente en el clúster de desarrollo, las versiones prod de las aplicaciones continuarán funcionando como si nada hubiera pasado.

+ Cluster se puede ajustar al entorno

Cada clúster se puede adaptar a su entorno. Por ejemplo, puedes:

instalar herramientas de desarrollo y depuración en el clúster de desarrollo;
instalar marcos y herramientas de prueba en el clúster de prueba ;
Use equipos y canales de red más potentes en el clúster de productos .

Esto le permite aumentar la eficiencia tanto del desarrollo como del funcionamiento de las aplicaciones.

+ Restrinja el acceso al clúster de producción

La necesidad de trabajar con un clúster de productos surge con poca frecuencia, por lo que puede limitar significativamente el círculo de personas que tienen acceso a él.

Puede ir aún más lejos y, en general, privar a las personas del acceso a este clúster y realizar todas las implementaciones utilizando la herramienta automatizada CI / CD. Tal enfoque minimizará el riesgo de error humano exactamente donde es más relevante.

Y ahora algunas palabras sobre los contras.

- Falta de aislamiento entre aplicaciones

El principal inconveniente del enfoque es la falta de aislamiento de hardware y recursos entre aplicaciones.

Las aplicaciones no relacionadas comparten recursos del clúster: el núcleo del sistema, el procesador, la memoria y algunos otros servicios.

Como ya se mencionó, esto puede ser potencialmente peligroso.

- Incapacidad para localizar dependencias de aplicaciones

Si la aplicación tiene requisitos especiales, deben cumplirse en todos los clústeres.

Por ejemplo, si una aplicación necesita una GPU, cada clúster debe contener al menos un trabajador con una GPU (incluso si solo la usa esa aplicación).

Como resultado, corremos el riesgo de mayores costos y uso ineficiente de los recursos.

Conclusión

Si tiene un conjunto específico de aplicaciones, puede colocarlas en varios grupos grandes o en muchos pequeños.

El artículo analiza los pros y los contras de varios enfoques, que van desde un grupo global hasta varios pequeños y altamente especializados:

un gran grupo común;
muchos pequeños grupos altamente especializados;
un clúster para cada aplicación;
Un grupo para cada entorno.

Entonces, ¿qué enfoque elegir?

Como de costumbre, la respuesta depende del caso de uso: debe sopesar los pros y los contras de los diferentes enfoques y elegir la opción más óptima.

Sin embargo, la elección no se limita a los ejemplos anteriores: ¡puede usar cualquier combinación de ellos!

Por ejemplo, se puede organizar un par de racimos por equipo: un grupo para el desarrollo (que tendrá dev y prueba ambientes ) y un grupo de producción (donde se ubicará el entorno de producción).

Según la información de este artículo, puede optimizar los pros y los contras en consecuencia para un escenario específico. Buena suerte

PD

Lea también en nuestro blog:

Diseño de clústeres de Kubernetes: ¿cuántos debería haber?