Múltiples entornos (Staging, QA, producción, etc.) con Kubernetes

¿Qué se considera una buena práctica con K8S para administrar múltiples entornos (QA, Staging, Production, Dev, etc.)?

Como ejemplo, digamos que un equipo está trabajando en un producto que requiere implementar algunas API, junto con una aplicación de front-end. Por lo general, esto requerirá al menos 2 entornos:

• Puesta en escena: para iteraciones / pruebas y validación antes de entregar al cliente
• Producción: Este es el entorno al que tiene acceso el cliente. Debe contener características estables y bien probadas.

Entonces, asumiendo que el equipo está usando Kubernetes, ¿cuál sería una buena práctica para alojar estos entornos? Hasta ahora hemos considerado dos opciones:

1. Utilice un clúster de K8 para cada entorno
2. Use solo un clúster de K8 y manténgalos en diferentes espacios de nombres.

(1) Parece la opción más segura ya que minimiza los riesgos de posibles errores humanos y fallas de la máquina, que podrían poner en peligro el entorno de producción. Sin embargo, esto conlleva el costo de más máquinas maestras y también el costo de una mayor gestión de la infraestructura.

(2) Parece que simplifica la gestión de la infraestructura y la implementación porque hay un solo clúster, pero plantea algunas preguntas como:

• ¿Cómo se puede asegurar que un error humano pueda afectar el entorno de producción?
• ¿Cómo se puede asegurar que una carga alta en el entorno de ensayo no cause una pérdida de rendimiento en el entorno de producción?

Puede haber otras preocupaciones, por lo que me estoy comunicando con la comunidad de K8 en StackOverflow para comprender mejor cómo las personas enfrentan este tipo de desafíos.

Consideraciones sobre varios clústeres

Eche un vistazo a esta publicación de blog de Vadim Eisenberg ( IBM / Istio ): Lista de verificación: pros y contras de usar varios clústeres de Kubernetes y cómo distribuir las cargas de trabajo entre ellos .

Me gustaría destacar algunos de los pros / contras:

Razones para tener varios clústeres

• Separación de producción / desarrollo / prueba: especialmente para probar una nueva versión de Kubernetes, de una malla de servicios, de otro software de clúster
• Cumplimiento: de acuerdo con algunas regulaciones, algunas aplicaciones deben ejecutarse en clústeres separados / VPN separadas
• Mejor aislamiento por seguridad
• Nube / local: para dividir la carga entre servicios locales

Razones para tener un solo clúster

• Reduzca los gastos generales de instalación, mantenimiento y administración
• Mejorar la utilización
• Reducción de costo

Teniendo en cuenta un entorno no demasiado caro, con un mantenimiento medio y, sin embargo, garantizando el aislamiento de seguridad para las aplicaciones de producción, recomendaría:

• 1 clúster para DEV y STAGING (separados por espacios de nombres, tal vez incluso aislados, usando políticas de red, como en Calico )
• 1 grupo para PROD

Paridad ambiental

Es una buena práctica mantener el desarrollo, la puesta en escena y la producción lo más similar posible:

Las diferencias entre los servicios de respaldo significan que surgen pequeñas incompatibilidades, lo que hace que el código que funcionó y pasó las pruebas en desarrollo o puesta en escena falle en producción. Este tipo de errores crean fricciones que desincentivan el despliegue continuo.

Combine una poderosa herramienta CI / CD con Helm . Puede utilizar la flexibilidad de los valores de helm para establecer configuraciones predeterminadas, simplemente anulando las configuraciones que difieren de un entorno a otro.

GitLab CI / CD con AutoDevops tiene una poderosa integración con Kubernetes, que le permite administrar múltiples clústeres de Kubernetes que ya cuentan con soporte de helm.

Gestión de múltiples clústeres ( kubectlinteracciones)

Cuando trabaja con varios clústeres de Kubernetes, es fácil kubectlequivocarse con los contextos y ejecutar en el clúster incorrecto. Más allá de eso, Kubernetes tiene restricciones para la discrepancia de versiones entre el cliente ( kubectl) y el servidor (maestro de kubernetes), por lo que ejecutar comandos en el contexto correcto no significa ejecutar la versión de cliente correcta.

Para superar esto:

• Úselo asdfpara administrar múltiples kubectlversiones
• Establecer laKUBECONFIG var env para cambiar entre varios kubeconfigarchivos
• Úselo kube-ps1para realizar un seguimiento de su contexto / espacio de nombres actual
• Use kubectxykubens para cambiar rápidamente entre clústeres / espacios de nombres
• Usa alias para combinarlos todos juntos

Tengo un artículo que ejemplifica cómo lograr esto: usando diferentes versiones de kubectl con múltiples clústeres de Kubernetes

También recomiendo las siguientes lecturas:

• Dominar el archivo KUBECONFIG por Ahmet Alp Balkan ( ingeniero de Google )
• Cómo gestiona Zalando más de 140 clústeres de Kubernetes por Henning Jacobs ( Zalando Tech )

Definitivamente, use un clúster separado para el desarrollo y la creación de imágenes de la ventana acoplable para que sus clústeres de preparación / producción se puedan bloquear en términos de seguridad. Si usa clústeres separados para, staging + productiondepende de usted decidir en función del riesgo / costo; sin duda, mantenerlos separados ayudará a evitar que stagingafecten production.

También recomiendo encarecidamente usar GitOps para promover versiones de sus aplicaciones entre sus entornos.

Para minimizar el error humano, también le recomiendo que busque automatizar tanto como pueda para su CI / CD y su promoción.

Aquí hay una demostración de cómo automatizar CI / CD con múltiples entornos en Kubernetes usando GitOps para la promoción entre entornos y entornos de vista previa en solicitudes de extracción que se realizó en vivo en GKE, aunque Jenkins X admite la mayoría de los clústeres de kubernetes.

Depende de lo que quieras probar en cada uno de los escenarios. En general, trataría de evitar ejecutar escenarios de prueba en el clúster de producción para evitar efectos secundarios innecesarios (impacto en el rendimiento, etc.).

Si su intención es realizar pruebas con un sistema de prueba que imita exactamente el sistema de producción , recomendaría activar una réplica exacta del clúster completo y apagarlo una vez que haya terminado de probar y mover las implementaciones a producción.

Si su propósito es probar un sistema de prueba que permite probar la aplicación para implementar, ejecutaría un clúster de prueba más pequeño de forma permanente y actualizaría las implementaciones (con también una versión reducida de las implementaciones) según sea necesario para las pruebas continuas.

Para controlar los diferentes clústeres, prefiero tener una máquina ci / cd separada que no sea parte del clúster, pero que se use para encender y apagar clústeres, así como para realizar trabajos de implementación, iniciar pruebas, etc. Esto permite configurar y apagar clústeres como parte de escenarios de prueba automatizados.

Está claro que al mantener el clúster de producción separado del de preparación, se reduce el riesgo de errores potenciales que afecten a los servicios de producción. Sin embargo, esto tiene un costo de más administración de infraestructura / configuración, ya que requiere al menos:

• al menos 3 maestros para el clúster de producción y al menos un maestro para el de ensayo
• 2 archivos de configuración de Kubectl que se agregarán al sistema CI / CD

Tampoco olvidemos que podría haber más de un entorno. Por ejemplo, he trabajado en empresas donde hay al menos 3 entornos:

• QA: aquí donde realizamos despliegues diarios y donde realizamos nuestro control de calidad interno antes de entregar al cliente)
• Control de calidad del cliente: aquí lo implementamos antes de implementarlo en producción para que el cliente pudiera validar el entorno antes de lanzarlo a producción)
• Producción: aquí es donde se implementan los servicios de producción.

Creo que los clústeres efímeros / bajo demanda tienen sentido, pero solo para ciertos casos de uso (pruebas de carga / rendimiento o pruebas de integración / de extremo a extremo muy «grandes»), pero para entornos más persistentes / pegajosos veo una sobrecarga que podría reducirse ejecutándolos dentro de un solo clúster.

Supongo que quería acercarme a la comunidad de k8s para ver qué patrones se utilizan para escenarios como los que he descrito.

A menos que el cumplimiento u otros requisitos dicten lo contrario, prefiero un solo clúster para todos los entornos. Con este enfoque, los puntos de atención son:

• Asegúrese de agrupar también los nodos por entorno mediante etiquetas. A continuación, puede utilizar elnodeSelector recursos on para asegurarse de que se estén ejecutando en nodos específicos. Esto reducirá las posibilidades de que el consumo (excesivo) de recursos se propague entre entornos.

• Trate sus espacios de nombres como subredes y prohíba todo el tráfico de entrada / salida de forma predeterminada. Ver https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

• Tenga una estrategia para administrar cuentas de servicio. ClusterRoleBindingsimplican algo diferente si un clúster aloja más de un entorno.

• Utilice el escrutinio cuando utilice herramientas como Helm. Algunos gráficos instalan descaradamente cuentas de servicio con permisos para todo el clúster, pero los permisos para las cuentas de servicio deben limitarse al entorno en el que se encuentran.

El uso de múltiples clústeres es la norma, en la misma lista, para hacer cumplir una fuerte separación entre producción y "no producción".

En ese espíritu, tenga en cuenta que GitLab 13.2 (julio de 2020) ahora incluye:

Implementación de varios clústeres de Kubernetes en Core

El uso de GitLab para implementar múltiples clústeres de Kubernetes con GitLab anteriormente requería una licencia Premium.
Nuestra comunidad habló y nosotros escuchamos: la implementación en múltiples clústeres es útil incluso para contribuyentes individuales.
Según sus comentarios, a partir de GitLab 13.2, puede implementar en varios grupos y clústeres de proyectos en Core.

Ver documentación y emisión /

Creo que ejecutar un solo clúster tiene sentido porque reduce los gastos generales y la supervisión. Pero, debe asegurarse de implementar políticas de red y control de acceso.

Política de red: para prohibir que la carga de trabajo del entorno dev / qa interactúe con las tiendas prod / staging.

Control de acceso: quién tiene acceso a diferentes recursos del entorno utilizando ClusterRoles, Roles, etc.