update rolling imagepullpolicy force kubernetes

imagepullpolicy - rolling updates in kubernetes



Múltiples entornos(puesta en escena, control de calidad, producción, etc.) con Kubernetes (6)

¿Qué se considera una buena práctica con K8S para administrar múltiples entornos (control de calidad, estadificación, producción, desarrollo, etc.)?

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

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

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

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

(1) Parece las opciones más seguras, 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 administración de la infraestructura.

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

  • ¿Cómo se asegura que un error humano pueda afectar el entorno de producción?
  • ¿Cómo puede uno asegurarse de 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 acercando a la comunidad de K8 en StackOverflow para tener una mejor comprensión de cómo las personas están lidiando con este tipo de desafíos.

Consideraciones de clústeres múltiples

Eche un vistazo a esta publicación de blog: Lista de verificación: pros y contras del uso de múltiples 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 múltiples grupos

  • 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 / VPN separados
  • Mejor aislamiento para la seguridad.
  • Cloud / on-prem: para dividir la carga entre servicios in situ

Razones para tener un solo clúster

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

Teniendo en cuenta un entorno no demasiado costoso, con un mantenimiento promedio y aún así asegurando el aislamiento de seguridad para las aplicaciones de producción, recomendaría:

  • 1 clúster para DEV y STAGING (separados por espacios de nombres, incluso aislados, utilizando 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 el desarrollo o la puesta en escena falle en la producción. Estos tipos de errores crean fricciones que desincentivan el despliegue continuo.

Combine una poderosa herramienta CI / CD con helm . Puede usar la flexibilidad de los valores de timón 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 timón.

Gestión de múltiples clústeres (interacciones kubectl )

Cuando trabajas con varios clústeres de Kubernetes, es fácil kubectl contextos y ejecutar kubectl en el clúster incorrecto. Más allá de eso, Kubernetes tiene restrictions para el desajuste 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 correcta del cliente.

Para superar esto:

  • Use asdf para administrar múltiples versiones de kubectl
  • Configure KUBECONFIG env var para cambiar entre múltiples archivos kubeconfig
  • Use kube-ps1 para realizar un seguimiento de su contexto / espacio de nombres actual
  • Use kubectx y kubens para cambiar rápidamente entre grupos / espacios de nombres
  • Usa alias para combinarlos todos juntos

Eche un vistazo a este artículo, explica cómo lograr esto: Uso de diferentes versiones de kubectl con múltiples grupos de Kubernetes

También recomiendo esta lectura: Dominar el archivo KUBECONFIG

A menos que el cumplimiento u otros requisitos indiquen lo contrario, estoy a favor de 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 utilizando etiquetas. A continuación, puede usar nodeSelector en los recursos para asegurarse de que se ejecutan en nodos específicos. Esto reducirá las posibilidades de que el consumo (excesivo) de recursos se extienda entre entornos.

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

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

  • Use el escrutinio cuando use 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.

Creo que ejecutar un solo clúster tiene sentido porque reduce la sobrecarga y la supervisión. Pero, debe asegurarse de colocar políticas de red, control de acceso en su lugar.

Política de red: prohibir la carga de trabajo del entorno dev / qa para interactuar con los almacenes de producción / preparación

Control de acceso: quienes tienen acceso a diferentes recursos del entorno utilizando ClusterRoles, Roles, etc.

Definitivamente use un clúster separado para el desarrollo y la creación de imágenes acoplables para que sus clústeres de puesta en escena / producción puedan bloquearse en términos de seguridad. Si usted usa grupos separados para la staging + production en staging + production depende de usted decidir en función del riesgo / costo; ciertamente, mantenerlos separados ayudará a evitar que la staging en staging afecte la production .

También recomiendo utilizar GitOps para promocionar versiones de sus aplicaciones entre sus entornos.

Para minimizar el error humano, también le recomiendo que busque la automatización tanto como pueda para su CI / CD y 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 Vista previa de entornos en solicitudes de extracción que se realizó en vivo en GKE aunque Jenkins X admite la mayoría de los grupos de kubernetes

Depende de lo que desee 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 probar con un sistema de preparación que imite exactamente el sistema de producción , recomendaría activar una réplica exacta del clúster completo y cerrarlo después de que haya terminado de probar y mover las implementaciones a producción.

Si su propósito es probar un sistema de etapas que permita probar la implementación de la aplicación , ejecutaría un clúster de etapas 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 escenario, se reduce el riesgo de posibles errores que afecten los servicios de producción. Sin embargo, esto conlleva 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 escenario
  • 2 archivos de configuración de Kubectl para agregar 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:

  • Control de calidad: aquí realizamos implementaciones diarias y realizamos nuestro control de calidad interno antes de enviarlo al cliente)
  • Control de calidad del cliente: aquí implementamos antes de implementar en producción para que el cliente pueda validar el entorno antes de lanzarlo a producción)
  • Producción: aquí 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 integración muy "grande" / pruebas de extremo a extremo), 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 llegar a la comunidad de k8s para ver qué patrones se utilizan para escenarios como los que he descrito.