Nota. traducir: este material es de un proyecto educativo es la respuesta a una pregunta popular al diseñar infraestructura basada en Kubernetes. Esperamos que las descripciones bastante 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 clústeres grandes (cada clúster tendrá una gran cantidad de cargas de trabajo) o en muchos pequeños (con una pequeña cantidad de cargas en cada clúster).
A continuación se muestra una tabla que evalúa los pros y los contras de cada enfoque:
Cuando se utiliza Kubernetes como plataforma para ejecutar aplicaciones, a menudo surgen varias preguntas fundamentales sobre las complejidades de la configuración de clústeres:
- ¿Cuántos clusters debo usar?
- ¿Qué tan grandes debo hacerlos?
- ¿Qué debe incluir cada grupo?
En este artículo intentaré responder a todas estas preguntas analizando los pros y los contras de cada enfoque.
Declaración de una pregunta
Como desarrollador de software, es probable que desarrolle y opere muchas aplicaciones al mismo tiempo.
Además, es probable que muchas instancias de estas aplicaciones se ejecuten en diferentes entornos; por ejemplo, estas pueden ser dev, test и pinchar.
El resultado es toda una matriz de aplicaciones y entornos:
Aplicaciones y entornos
El ejemplo anterior representa 3 aplicaciones y 3 entornos, lo que da como resultado un total de 9 opciones posibles.
Cada instancia de aplicación es una unidad de implementación autónoma con la que se puede trabajar independientemente de las demás.
Tenga en cuenta que instancia de aplicación puede constar de muchos componentes, como frontend, backend, base de datos, etc. En el caso de una aplicación de microservicios, la instancia incluirá todos los microservicios.
Como resultado, los usuarios de Kubernetes tienen varias preguntas:
- ¿Deberían colocarse todas las instancias de la aplicación en un grupo?
- ¿Vale la pena tener un clúster independiente para cada instancia de aplicación?
- ¿O quizás debería utilizarse una combinación de los enfoques anteriores?
Todas estas opciones son bastante viables, ya que Kubernetes es un sistema flexible que no limita las capacidades del usuario.
Estas son algunas de las formas posibles:
- un gran grupo común;
- muchos pequeños grupos altamente especializados;
- un clúster por aplicación;
- un clúster por entorno.
Como se muestra a continuación, los dos primeros enfoques se encuentran en extremos opuestos de la escala de opciones:
Desde unos pocos grupos grandes (izquierda) hasta muchos pequeños (derecha)
En general, un clúster se considera "más grande" que otro si tiene una suma mayor de nodos y pods. 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, ¡comencemos!
1. Un gran grupo común
La primera opción es colocar todas las cargas de trabajo en un clúster:
Un gran grupo
Dentro de este enfoque, el cluster se utiliza como un sistema universal. plataforma de infraestructura — simplemente implemente todo lo que necesita en un clúster de Kubernetes existente.
Kubernetes permite que partes del clúster se separen lógicamente entre sí, de modo que cada instancia de aplicación pueda tener su propio espacio de nombres.
Veamos los pros y los contras de este enfoque.
+ Uso eficiente de los recursos
Con un solo clúster, solo necesita una copia de todos los recursos necesarios para ejecutar y administrar el clúster de Kubernetes.
Por ejemplo, esto es cierto para los nodos maestros. Normalmente, cada clúster de Kubernetes tiene 3 nodos maestros, por lo que para un solo clúster su número seguirá siendo el mismo (a modo de comparación, 10 clústeres necesitarán 30 nodos maestros).
La sutileza anterior también se aplica a otros servicios que operan en todo el clúster, como balanceadores de carga, controladores de ingreso, sistemas de autenticación, registro y monitoreo.
En un único clúster, todos estos servicios se pueden utilizar a la vez para todas las cargas de trabajo (no es necesario crear copias de ellos, como ocurre con varios clústeres).
+ Barato
Como consecuencia de lo anterior, un menor número de clústeres suele ser más barato porque no hay costes generales.
Esto es especialmente cierto para los nodos maestros, que pueden costar una cantidad significativa de dinero independientemente de cómo estén alojados (en las instalaciones o en la nube).
Algunos servicios administrados de Kubernetes, como o , proporciona la capa de control de forma gratuita. En este caso, la cuestión de los costes es menos grave.
También existen servicios gestionados que cobran una tarifa fija por el funcionamiento de cada clúster de Kubernetes (por ejemplo, ).
+ Administración eficiente
Administrar un clúster es más fácil que administrar varios.
La administración puede incluir las siguientes tareas:
- Actualización de la versión de Kubernetes;
- establecer un canal de CI/CD;
- instalar el complemento CNI;
- configurar un sistema de autenticación de usuarios;
- instalación de un controlador de acceso;
y muchos otros…
En el caso de un grupo, tendrás que hacer todo esto sólo una vez.
Para muchos clústeres, las operaciones deberán repetirse muchas veces, lo que probablemente requerirá cierta automatización de procesos y herramientas para garantizar la coherencia y la coherencia del proceso.
Y ahora unas palabras sobre las desventajas.
− Punto único de fallo
En caso de rechazo el unico el cluster dejará de funcionar inmediatamente todos cargas de trabajo!
Hay muchas maneras en que las cosas pueden salir mal:
- la actualización de Kubernetes provoca efectos secundarios inesperados;
- Un componente de todo el clúster (por ejemplo, un complemento CNI) comienza a no funcionar como se esperaba;
- uno de los componentes del clúster no está configurado correctamente;
- falla en la infraestructura subyacente.
Uno de esos incidentes puede causar daños graves a todas las cargas de trabajo alojadas en un clúster compartido.
− Sin aislamiento rígido
Ejecutarse en un clúster compartido significa que las aplicaciones comparten el hardware, las capacidades de red y el sistema operativo en los nodos del clúster.
En cierto sentido, dos contenedores con dos aplicaciones diferentes ejecutándose en el mismo nodo son como dos procesos ejecutándose en la misma máquina y ejecutando el mismo kernel del sistema operativo.
Los contenedores de Linux proporcionan alguna forma de aislamiento, pero no es 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: en teoría, esta disposición permite que aplicaciones no relacionadas se comuniquen entre sí (ya sea intencionalmente o accidentalmente).
Además, todas las cargas de trabajo en un clúster de Kubernetes comparten algunos servicios para todo el clúster, como - esto permite que las aplicaciones encuentren servicios de otras aplicaciones en el clúster.
Todos los puntos anteriores pueden tener diferentes significados según los requisitos de seguridad de la aplicación.
Kubernetes proporciona varias herramientas para evitar problemas de seguridad como и . Sin embargo, para configurarlos correctamente se requiere cierta experiencia y, además, no son capaces de cerrar absolutamente todos los agujeros de seguridad.
Es importante recordar siempre que Kubernetes fue diseñado originalmente para intercambio, no para aislamiento y seguridad.
− Falta de multiinquilino estricto
Dada la abundancia de recursos compartidos en un clúster de Kubernetes, hay muchas maneras en que diferentes aplicaciones pueden pisarse entre sí.
Por ejemplo, una aplicación podría monopolizar un recurso compartido (como CPU o memoria) y negarle acceso a otras aplicaciones que se ejecutan en el mismo nodo.
Kubernetes proporciona varios mecanismos para controlar este comportamiento, como (ver también el artículo “" - aprox. trad.), и . Sin embargo, como en el caso de la seguridad, su configuración no es trivial y no son capaces de evitar absolutamente todos los efectos secundarios imprevistos.
− Gran número de usuarios
En el caso de un solo clúster, debe abrir el acceso a él a muchas personas. Y cuanto mayor sea su número, mayor será el riesgo de que “rompan” algo.
Dentro del clúster puedes controlar quién puede hacer qué usando (ver artículo “" - aprox. trad.). Sin embargo, esto no impedirá que los usuarios “rompan” algo dentro de los límites de su área de responsabilidad.
− Los clusters no pueden crecer indefinidamente
El clúster que se utiliza para todas las cargas de trabajo probablemente será bastante grande (en términos de número de nodos y pods).
Pero aquí surge otro problema: los clusters en Kubernetes no pueden crecer indefinidamente.
Existe un límite teórico en el tamaño del clúster. En Kubernetes es aproximadamente .
Sin embargo, en la vida real, los problemas pueden empezar mucho antes, por ejemplo, simplemente con .
El hecho es que los clústeres grandes suponen una gran carga para la capa de control de Kubernetes. En otras palabras, mantener el clúster en funcionamiento de manera eficiente requiere un ajuste cuidadoso.
Este problema se explora en un artículo relacionado en el blog original llamado "".
Pero consideremos el enfoque opuesto: muchos grupos pequeños.
2. Muchos grupos pequeños y especializados
Con este enfoque, utiliza un clúster independiente para cada elemento que implementa:
Muchos grupos pequeños
Para los efectos de este artículo, en virtud de elemento desplegable se refiere a una instancia de una aplicación; por ejemplo, una versión de desarrollo de una aplicación independiente.
Esta estrategia utiliza Kubernetes como un especializado tiempo de ejecución para casos de aplicación individuales.
Veamos los pros y los contras de este enfoque.
+ “Radio de explosión” limitado
Cuando un clúster falla, las consecuencias negativas se limitan únicamente a las cargas de trabajo que se implementaron en ese 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.
El resultado es un estrecho aislamiento entre aplicaciones no relacionadas, lo que puede resultar beneficioso para su seguridad.
+ Pequeño número de usuarios
Dado que cada clúster contiene solo un conjunto limitado de cargas de trabajo, la cantidad de usuarios con acceso a él se reduce.
Cuantas menos personas tengan acceso al clúster, menor será el riesgo de que algo se “rompa”.
Veamos las desventajas.
− Uso ineficiente de los recursos.
Como se mencionó anteriormente, cada clúster de Kubernetes requiere un conjunto específico de recursos de administración: nodos maestros, componentes de la capa de control, soluciones de monitoreo y registro.
En el caso de un gran número de grupos pequeños, se debe asignar una mayor proporción de recursos a la gestión.
− Caro
El uso ineficiente de los recursos implica automáticamente altos costos.
Por ejemplo, mantener 30 nodos maestros en lugar de tres con la misma potencia informática necesariamente afectará los costos.
− Dificultades en la administración
Administrar varios clústeres de Kubernetes es mucho más difícil que administrar solo uno.
Por ejemplo, deberá configurar la autenticación y la autorización para cada clúster. La versión de Kubernetes también deberá actualizarse varias veces.
Es probable que necesite utilizar la automatización para que todas estas tareas sean más eficientes.
Ahora veamos escenarios menos extremos.
3. Un clúster por aplicación
En este enfoque, se crea un clúster separado para todas las instancias de una aplicación en particular:
Clúster por aplicación
Este camino puede considerarse como una generalización del principio “grupo separado por equipo”, ya que normalmente un equipo de ingenieros está desarrollando una o más aplicaciones.
Veamos los pros y los contras de este enfoque.
+ El cluster se puede ajustar a la aplicación
Si una 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, ciertos complementos de CNI, una malla de servicios o algún otro servicio.
Cada clúster se puede adaptar a la aplicación que se ejecuta en él para que contenga sólo lo que se necesita.
− Diferentes entornos en un clúster
La desventaja de este enfoque es que en el mismo clúster coexisten instancias de aplicaciones de diferentes entornos.
Por ejemplo, la versión de producción de la aplicación se ejecuta en el mismo clúster que la versión de desarrollo. Esto también significa que los desarrolladores operan 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 fallas en la versión dev, se produce una falla en el clúster, entonces la versión prod podría sufrir también, un gran inconveniente de este enfoque.
Y finalmente, el último escenario de nuestra lista.
4. Un clúster por entorno
Este escenario implica asignar un clúster independiente para cada entorno:
Un clúster por entorno
Por ejemplo, es posible que tenga grupos dev, test и pinchar, en el que ejecutará todas las instancias de la aplicación dedicadas a un entorno específico.
Éstos son los pros y los contras de este enfoque.
+ Aislamiento del entorno de producción.
Dentro de este enfoque, todos los entornos están aislados unos de otros. Sin embargo, en la práctica esto es especialmente importante en un 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.
De esta forma, si de repente surge un problema en el clúster de desarrollo, las versiones prod de las aplicaciones seguirán funcionando como si nada.
+ El cluster se puede adaptar al entorno.
Cada grupo se puede ajustar a su entorno. Por ejemplo, puedes:
- instalar herramientas para desarrollo y depuración en el clúster de desarrollo;
- instalar marcos de prueba y herramientas en el clúster test;
- Utilice hardware y canales de red más potentes en el clúster. pinchar.
Esto le permite aumentar la eficiencia tanto del desarrollo como de la operación de la aplicación.
+ Restringir el acceso al clúster de producción.
Rara vez surge la necesidad de trabajar directamente con un grupo de productos, por lo que puede limitar significativamente el círculo de personas que tienen acceso a él.
Puede ir aún más lejos y negar a las personas el acceso a este clúster por completo y realizar todas las implementaciones utilizando una herramienta CI/CD automatizada. Este enfoque minimizará el riesgo de errores humanos exactamente donde sea más relevante.
Y ahora unas palabras sobre las desventajas.
− Sin aislamiento entre aplicaciones
La principal desventaja de este enfoque es la falta de hardware y aislamiento de 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 se mencionó, esto puede ser potencialmente peligroso.
− Incapacidad para localizar las dependencias de la aplicación.
Si una aplicación tiene requisitos especiales, deben cumplirse en todos los clústeres.
Por ejemplo, si una aplicación requiere una GPU, entonces 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 un uso ineficiente de los recursos.
Conclusión
Si tiene un conjunto específico de aplicaciones, se pueden colocar en varios grupos grandes o en muchos pequeños.
El artículo analiza los pros y los contras de varios enfoques, desde un grupo global hasta varios pequeños y altamente especializados:
- un gran grupo general;
- muchos pequeños grupos altamente especializados;
- un clúster por aplicación;
- un clúster por entorno.
Entonces, ¿qué enfoque debería adoptar?
Como siempre, la respuesta depende del caso de uso: es necesario 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 utilizar cualquier combinación de ellos!
Por ejemplo, puedes organizar un par de clusters para cada equipo: un cluster de desarrollo (en el que habrá entornos dev и test) y agrupar para Production (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!
PS
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com