Materias de CI/CD y GitOps con Kubernetes habilitado para Azure Arc

  • Artículo

Kubernetes, como construcción nativa de la nube, exige un enfoque nativo de nube para la implementación y las operaciones. Con GitOps, se declara el estado deseado de las implementaciones basadas en aplicaciones en archivos que se almacenan en repositorios de GIT. Las aplicaciones tienen objetos de Kubernetes que tienen que ejecutar, lo que puede incluir Deployments, Horizontal-Pod-Autoscalers, Services y ConfigMaps. Los operadores de Kubernetes se ejecutan en los clústeres y concilian continuamente el estado de cada clúster con el estado deseado declarado en el repositorio de GIT. Estos operadores extraen los archivos de los repositorios de GIT y aplican el estado deseado a los clústeres. Además, los operadores también garantizan continuamente que el clúster permanezca en el estado deseado.

La implementación de GitOps le permite:

  • Mejorar la visibilidad general del estado y la configuración de los clústeres de Kubernetes.
  • Tener una auditoría sencilla y un historial de versiones de los cambios en el clúster a través del historial de cambios de GIT, que muestra quién hizo cambios, cuándo y por qué.
  • Corregir automáticamente el desfase que se puede producir en el clúster.
  • Revertir la configuración de Kubernetes a una versión anterior mediante comandos Git revert o Git rollback. La nueva creación de la implementación de clústeres para escenarios de recuperación ante desastres también se convierte en un proceso rápido y sencillo, ya que la configuración de clúster deseada de Kubernetes se almacena en GIT.
  • Mejorar la seguridad al reducir el número de cuentas de servicio necesarias para tener permisos de implementación en el clúster.
  • Implementar una canalización de CI/CD para implementar aplicaciones en el clúster.

GitOps en Kubernetes habilitado para Azure Arc usa una extensión que implementa Flux, un popular conjunto de herramientas de código abierto. Flux es un operador que automatiza las implementaciones de configuración de GitOps en el clúster. Flux proporciona compatibilidad con orígenes de archivos comunes (repositorios Git, repositorios Helm, Cubos) y tipos de plantillas (YAML, Helm y Kustomize). Flux también admite la administración de dependencias multiinquilino y de implementación, entre otras características.

Architecture

En los diagramas siguientes se muestra una arquitectura de referencia conceptual que destaca el aprovisionamiento de la instalación de la extensión para clústeres de Flux en un clúster, el proceso de configuración de GitOps para un clúster de Kubernetes habilitado para Azure Arc y el flujo de GitOps.

Proceso de aprovisionamiento de extensiones de clúster de Flux v2:

Diagram that shows Flux extension installation.

Proceso de configuración de GitOps:

Diagram that shows how to configure GitOps.

Flujo de GitOps que muestra la actualización de una aplicación:

Diagram that shows a typical GitOps workflow.

Consideraciones de diseño

Revise las consideraciones de diseño a continuación al planear la implementación de GitOps para Kubernetes habilitado para Azure Arc.

Configuración

Tenga en cuenta las distintas capas de configuración en el clúster de Kubernetes y las responsabilidades que involucra el aprovisionamiento.

Capas de configuración

  • La configuración de aplicación necesaria para implementar una aplicación y sus objetos de Kubernetes relacionados en el clúster, como los recursos Deployment, Service, HPA y ConfigMap. Las configuraciones de aplicación se suelen aplicar a una configuración de GitOps a nivel de espacio de nombres, lo que requiere que los componentes de la aplicación solo se configuren dentro de un único espacio de nombres.
  • La configuración de todo el clúster para la creación de objetos de Kubernetes, como Namespaces, ServiceAccounts, Roles y RoleBindings, y otras directivas para todo el clúster.
  • Los componentes de todo el clúster, como un controlador de entrada, una pila de supervisión y seguridad, y varios agentes que operan en el clúster.

Responsabilidades

  • Los desarrolladores de aplicaciones son responsables de insertar el código fuente, desencadenar compilaciones y crear imágenes de contenedor.
  • Los operadores de aplicación son responsables de mantener los repositorios de las aplicaciones, las configuraciones, las variables de entorno, los gráficos de Helm específicos de la aplicación, personalizaciones Kustomize, etc.
  • Los operadores de clúster son responsables de configurar la línea de base del clúster. Normalmente se encargan de la configuración de las directivas y componentes de todo el clúster. Mantienen uno o varios directorios de repositorios de GIT que contienen herramientas de infraestructura comunes, como Namespaces, Service Accounts, RoleBindings, CRD, directivas para todo el clúster, componentes de entrada, etc.

Estructura del repositorio

Tenga en cuenta las contrapartidas de elegir una estructura de repositorios de GIT. La estructura que elija definirá el estado del clúster de Kubernetes, lo que incluye aplicaciones y componentes de todo el clúster. En función de las responsabilidades y los roles que identifique, es importante tener en cuenta toda colaboración o independencia deseada del equipo necesarias para las distintas opciones de estructura de repositorios.

Puede usar cualquier estrategia de ramificación que crea conveniente para los repositorios de código, ya que solo se usa en el proceso de integración continua (CI).

Para los repositorios de configuración de GitOps, tenga en cuenta las estrategias siguientes en función de las necesidades empresariales, el tamaño y las herramientas de la organización:

  • Repositorio único (rama por entorno):
    • Permite la mayor flexibilidad para controlar las directivas y permisos de Git para cada rama que representa un entorno.
    • El inconveniente es que no hay un uso compartido de la configuración común entre entornos, ya que las herramientas como Kustomize no funcionan con ramas de GIT.
  • Repositorio único (directorio por entorno):
    • Puede implementar este enfoque mediante herramientas como Kustomize, que le permite definir una configuración base para objetos de Kubernetes y un conjunto de artefactos (es decir, revisiones) para el entorno que invalida las configuraciones en la base.
    • Este enfoque puede reducir los archivos YAML duplicados para cada entorno, pero también reduce la separación de configuración entre entornos. Hacer un único cambio en el repositorio tiene el potencial de afectar a todos los entornos a la vez, por lo que se debe comprender por completo el efecto de los cambios en los directorios base y hacerse con cuidado.
  • Varios repositorios (donde cada uno tiene un propósito específico):
    • Se podría usar para separar los repositorios de configuración para cada aplicación, equipo, capa o inquilino.
    • Esto permite a los equipos tener un control más independiente, pero se aleja del principio de definir el estado del sistema en un único repositorio para mejorar la configuración, la visibilidad y el control centrales de las implementaciones en un clúster.
    • La configuración de varios repositorios debe analizarse para las necesidades multiinquilino. Hay un control de acceso basado en roles (RBAC) y seguridad integrados para limitar la configuración que un equipo o inquilino asignados a un repositorio específico pueden aplicar; por ejemplo, solo permitir la implementación en determinados espacios de nombres.

Consulte otras formas de estructurar el repositorio en la Guía de Flux.

Configuración de aplicaciones y plataformas

Los operadores de plataforma y los operadores de aplicación tienen varias opciones para administrar la configuración de Kubernetes:

  • Los archivos YAML de Kubernetes sin procesar que representan las especificaciones de YAML para cada objeto de API de Kubernetes que va a implementar pueden funcionar bien para entornos únicos. El inconveniente de usar archivos YAML sin procesar es que la personalización se vuelve difícil cuando se empiezan a incorporar varios entornos, ya que tiene que duplicar archivos YAML y no hay un buen método de reutilización.
  • Helm es una herramienta de administración de paquetes para objetos de Kubernetes. Es una opción válida que los operadores de clúster pueden usar para instalar aplicaciones comerciales de terceros. Asegúrese de no usar plantillas con excesiva frecuencia como herramienta de administración de configuración para las aplicaciones internas, ya que la administración se puede volver compleja a medida que crecen las plantillas.
    • Si usa Helm, Flux incluye un controlador de Helm que le permite administrar declarativamente las versiones de gráficos de Helm con manifiestos de Kubernetes. Puede crear un objeto HelmRelease para administrar ese proceso.
  • Kustomize es una herramienta de administración de configuración nativa de Kubernetes que presenta una manera sin plantillas de personalizar la configuración de la aplicación.
    • Si usa Kustomize, Flux incluye un controlador de Kustomize que se especializa en la ejecución de canalizaciones de entrega continua para infraestructuras y cargas de trabajo definidas con manifiestos de Kubernetes y ensambladas con Kustomize. Puede crear un objeto Kustomization para administrar ese proceso.
  • Con Kubernetes habilitado para Azure Arc, en lugar de tener que administrar el ciclo de vida y la compatibilidad de los componentes usted mismo, puede usar una lista de extensiones disponibles que Microsoft administra y a las que presta soporte. Estas extensiones se administran a través de Azure Resource Manager. Algunas de estas extensiones, como el proveedor de secretos de Azure Key Vault, tienen alternativas de código abierto. La administración de componentes fuera del proceso de extensión le da más control sobre los componentes, pero también requiere más sobrecarga para la administración del ciclo de vida y el soporte técnico.

Flujo de integración continua y entrega continua (CI/CD)

En las secciones siguientes encontrará consideraciones para la canalización de aplicaciones y el proceso de actualización de componentes.

Canalización de aplicaciones

  • Tenga en cuenta la compilación, las pruebas y las validaciones de la aplicación que debe incluir en el proceso de CI. Estas pueden incluir linting y pruebas relacionadas con la seguridad, la integración y el rendimiento, que necesita para crear una versión candidata para lanzamiento (RC) para las implementaciones de entorno.
  • Puede usar un método de implementación de inserción tradicional para superar la brecha entre una imagen de contenedor de compilación en la canalización de CI y su implementación en un clúster mediante una llamada a la API de Kubernetes directamente desde la canalización de implementación.

Para evitar modificaciones de configuración manuales en el repositorio de GitOps, puede ejecutar la canalización de CD como cuenta de servicio, que tiene permiso para abrir solicitudes de incorporación de cambios (RP) o confirmar un nuevo cambio de imagen de contenedor directamente en un repositorio de configuración. Estos cambios también pueden aprovisionar todos los objetos YAML necesarios para la aplicación.

En el diagrama de proceso siguiente se muestra el proceso de CI de aplicación tradicional incorporado con los cambios que admiten GitOps.

Diagram that shows the standard GitOps process.

Proceso de actualización de componentes en todo el clúster

  • Los operadores de clúster tienen que administrar componentes de todo el clúster, por lo que es probable que no se originen en la canalización de CD que se usa para implementar las aplicaciones y servicios. Considere la posibilidad de definir un proceso de promoción específico de los operadores de clúster para asegurar que los cambios puedan hacer una transición sin problemas de un entorno a otro.
  • Si tiene que aplicar una configuración de GitOps idéntica a gran escala en los clústeres de Kubernetes habilitado para Azure Arc, considere la posibilidad de aplicar una instancia de Azure Policy que pueda instalar automáticamente la extensión Flux y aplicar la configuración de GitOps en los clústeres de Kubernetes habilitado para Azure Arc existentes o en nuevos clústeres a medida que se incorporan en Azure Arc.

Al actualizar la configuración, es probable que quiera comprobar que los cambios se hayan aplicado correctamente en el entorno deseado. Puede definir notificaciones en Flux para que se integren en las herramientas de CI/CD, correo electrónico o herramientas de ChatOps, y envíen automáticamente alertas con respecto a los cambios correctos y errores de implementación. También puede encontrar información sobre el estado de implementación en Azure Portal y a través de la CLI k8s-configuration y la API de ARM.

Consideraciones sobre la seguridad

Revise las consideraciones de seguridad a continuación al planear la implementación de GitOps para Kubernetes habilitado para Azure Arc.

Autenticación de repositorios

  • Puede usar un repositorio de GIT público o privado con GitOps, pero, debido a la naturaleza confidencial de las configuraciones de Kubernetes, se recomienda usar un repositorio privado que requiera autenticación mediante una clave SSH o clave de API. GitOps también funciona con repositorios de Git que solo son accesibles dentro de una red privada, siempre que el clúster de Kubernetes pueda acceder a él, pero esta configuración limita la capacidad de usar proveedores de GIT basados en la nube, como Azure Repos o GitHub.
  • Los protocolos HTTPS y SSH ofrecen una conexión confiable y segura que puede usar para conectarse a la herramienta de control de código fuente. Sin embargo, HTTPS suele ser más fácil de configurar y usa un puerto que pocas veces requiere que abra más puertos en los firewalls.

Seguridad de repositorios y ramas

  • Establezca directivas y permisos de rama en el repositorio de configuración. A medida que el repositorio de GIT se convierte en la parte central de las implementaciones de Kubernetes, es fundamental configurar permisos para controlar quién puede leer y actualizar el código en una rama, e implementar directivas que exijan la administración de cambios y la calidad del código para el equipo. De lo contrario, el flujo de trabajo de GitOps puede enviar código que no alcance los estándares de su organización.
  • La canalización de solicitud de incorporación de cambios (PR) puede funcionar con las directivas de rama para validar la configuración de YAML o implementar entornos de prueba según sea necesario. Las puertas ayudan a eliminar los errores de configuración y a aumentar la seguridad y la confianza de la implementación.
  • Al asignar permisos de acceso, tenga en cuenta qué usuarios de la organización tienen que tener acceso de lectura al repositorio, acceso de creación de PR y acceso de aprobación de PR.

Administración de secretos

  • Evite almacenar secretos codificados en base64 o texto sin formato en el repositorio de GIT. En su lugar, considere la posibilidad de usar un proveedor de secretos externo, como Azure Key Vault. El proveedor de Azure Key Vault para el controlador CSI de Secrets Store le permite integrar una instancia de Azure Key Vault como almacén de secretos con un clúster de Azure Kubernetes Service (AKS) mediante un volumen CSI. Este servicio está disponible a través de la extensión de Kubernetes habilitado para Azure Arc. HashiCorp Vault es una alternativa de proveedor externo de secretos administrados.
  • Otra manera alternativa de administrar secretos es usar Sealed Secrets de Bitnami, que funcionan a partir del concepto de claves públicas y privadas. Esto permite a los operadores almacenar un secreto cifrado unidireccional mediante una clave pública en GIT, que solo se puede descifrar mediante la clave privada, que se usa en un controlador SealedSecrets que se ejecuta en el clúster.

Recomendaciones de diseño

Revise las recomendaciones de diseño a continuación al planear la implementación de GitOps para Kubernetes habilitado para Azure Arc.

En el diagrama siguiente se ve una arquitectura de referencia que ilustra las responsabilidades, repositorios y canalizaciones necesarios para implementar un proceso de GitOps mediante la extensión Flux de Kubernetes habilitado para Azure Arc.

Diagram that shows a GitOps Reference flow.

Repositorios

En el diseño se incluyen tres repositorios de GIT:

  • Repositorio de código de la aplicación
    • Este repositorio almacena el código de aplicación y los scripts de configuración y definición de canalizaciones.
    • Use una estrategia de ramificación del desarrollo que sea fácil de entender y que limite el número de ramas de larga ejecución no deseadas.
  • Repositorio de configuración de la aplicación
    • Este repositorio almacena configuraciones de aplicación, incluidos objetos de Kubernetes, como objetos ConfigMaps, Deployments, Services y HPA. Estructure este repositorio con diferentes directorios para cada aplicación. Flux sincronizará los cambios de este repositorio y la rama de destino con el clúster.
    • Incorpore herramientas que facilitan a los desarrolladores y operadores de aplicaciones compilar configuraciones iniciales por entorno. Los operadores de aplicaciones tendrían que definir una configuración de aplicación específica de Kubernetes que use administradores de paquetes, como Helm, o herramientas de configuración, como Kustomize, para simplificar la configuración.
    • Cree una rama para representar cada tipo de entorno. Esto permite un control específico de los cambios en cada entorno específico, como entornos de producción y de no producción.
    • Cuando una aplicación se implementa en un espacio de nombres determinado, use la característica de ámbito del espacio de nombres dentro de la configuración de GitOps para aplicar la configuración solo para un espacio de nombres determinado.
  • Repositorio de configuración para todo el clúster
    • Defina componentes para todo el clúster, como controlador de entrada, espacios de nombres, RBAC, supervisión y pila de seguridad, para la administración de operadores de clúster. Flux sincroniza los cambios de este repositorio y la rama de destino con el clúster.
    • Estructure este repositorio con diferentes directorios que representen distintos componentes.
    • Cree una rama para representar cada tipo de entorno. Esto permite un control específico de los cambios en cada entorno específico, como entornos de producción y de no producción.
    • Los operadores de clúster deben usar administradores de paquetes, como Helm, o herramientas de configuración, como overlays de Kustomize, para simplificar la configuración.

Proceso de actualización de CI/CD y configuración

Actualizaciones de imágenes de contenedor y CI/CD

  • Canalización de CI
    • Los equipos de desarrollo tendrían que definir una canalización de CI a través del proceso que incluya la compilación, linting, pruebas e inserción de una aplicación en el registro de contenedor.
  • Canalización de CD
    • Cree una canalización de CD que ejecute un script que tenga como destino los cambios en el repositorio de configuración de la aplicación. Este script crea una rama temporal cuyo origen se encuentra en el entorno de destino, hace un cambio en la versión de la etiqueta de imagen, confirma el cambio y abre una solicitud de incorporación de cambios en la rama de entorno de destino. Esta canalización de CD puede tener fases de entorno con las variables de entorno adecuadas para tener como destino la rama y el repositorio de configuración de GitOps correctos.
    • Defina los pasos de aprobación manual para las fases del entorno para limitar las solicitudes de incorporación de cambios no deseadas para todos los entornos.
  • Habilite las directivas de rama en el repositorio de configuración de la aplicación para aplicar la revisión por homólogos o aprobaciones para los entornos. Esto puede involucrar un número mínimo de revisiones necesarias o una aprobación automática para entornos inferiores. Además, considere las integraciones y aprobaciones de terceros según sea necesario para cumplir los estándares de su organización.

Actualizaciones de configuración de aplicaciones y para todo el clúster

  • Cada uno de los operadores de clúster y operadores de aplicación define la configuración en sus respectivos repositorios de configuración. Estos usuarios no necesitan herramientas de canalización para insertar configuraciones. En su lugar, usan procesos de confirmación y PR nativos de GIT para definir una configuración e insertar cambios en una rama que representa un entorno.
  • Para las nuevas definiciones de configuración, empiece por definir la configuración en entornos inferiores, como el de desarrollo, y luego promueva a entornos superiores mediante combinaciones y solicitudes de incorporación de cambios. Seleccione de manera exclusiva las actualizaciones de configuración específicas de determinados entornos según sea necesario.

Comentarios y alertas

  • Configure las notificaciones de Flux para alertar cuando las configuraciones de GitOps no se puedan sincronizar o produzcan errores. Los operadores de aplicación tendrían que configurar alertas para determinar cuándo una implementación de la aplicación se ha completado adecuadamente y es correcta. Los operadores de clúster tendrían que configurar alertas para determinar cuándo se ha producido un error en la conciliación de componentes de todo el clúster, y cuándo hay problemas de sincronización con el repositorio de GIT.
  • Implemente GitOps Connector para integrar los comentarios del agente de Flux en las herramientas de CI/CD.

Recomendaciones de seguridad

  • Revise las recomendaciones de gobernanza y seguridad para los clústeres de Kubernetes habilitado para Azure Arc.
  • Evite el acceso no deseado a cualquier configuración de clúster mediante un repositorio de GIT privado con autenticación y autorización que pueda usar para definir cualquier repositorio de configuración.
  • Acceda al repositorio de GIT a través del protocolo SSH y una clave SSH si el proveedor de GIT lo admite. Si no se puede usar SSH debido a restricciones de conectividad de salida, o si el proveedor de GIT no admite las bibliotecas SSH necesarias, use una cuenta de servicio dedicada y asocie una clave de API a esa cuenta para que Flux la use. Si necesita una alternativa a SSH al usar GitHub, puede crear un token de acceso personal para la autenticación.
  • Configure directivas y permisos de rama que coincidan con las responsabilidades del clúster. Establezca un número mínimo de revisores para aprobar los cambios.
  • Configure una canalización de PR para validar las configuraciones y la sintaxis de YAML y, de manera opcional, implementar un clúster de Kubernetes de prueba. Configure una directiva de rama que requiera que esta canalización se ejecute correctamente antes de que se pueda aceptar cualquier combinación.
  • Implemente secretos mediante el proveedor de Azure Key Vault para el controlador CSI de Secrets Store, que permitirá la integración de una instancia de Azure Key Vault como almacén de secretos con un clúster de Kubernetes habilitado para Azure Arc mediante un volumen CSI.
  • La extensión Flux admite configuraciones con ámbito de clúster y espacio de nombres. Elija el ámbito de espacio de nombres cuando la configuración no deba tener acceso más allá de un único espacio de nombres.

Pasos siguientes

Para obtener más información sobre el recorrido de nube híbrida y multinube, consulte los siguientes artículos.