Compartir a través de

GitOps para Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHub

GitOps es un conjunto de principios para operar y administrar un sistema de software. En este artículo se describen técnicas para usar los principios de GitOps para operar y administrar un clúster de Azure Kubernetes Services (AKS).

Los logotipos de Flux, Argo CD, OPA Gatekeeper, Kubernetes y Git son marcas comerciales de sus respectivas empresas. El uso de estas marcas no implica ninguna aprobación.

Arquitectura

Dos operadores de GitOps que puede usar con AKS son Flux y Argo CD. Son proyectos graduados de Cloud Native Computing Foundation (CNCF) y se usan ampliamente. En los siguientes escenarios se muestran formas de usarlos.

Escenario 1: GitOps con Flux y AKS

Diagrama de GitOps con Flux v2, GitHub y AKS.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos para el escenario 1

Flux es una extensión de clúster que se integra de forma nativa con AKS. Una extensión de clúster proporciona una plataforma para instalar y administrar soluciones en un clúster de AKS. Puede usar los scripts de Azure Portal, la CLI de Azure o la infraestructura como código (IaC), como scripts de Terraform o Bicep, para habilitar Flux como una extensión en AKS. También puede usar Azure Policy para aplicar configuraciones de Flux v2 a escala en clústeres de AKS. Para más información, consulte Implementación de aplicaciones de forma coherente a escala mediante configuraciones de Flux v2 y Azure Policy.

Flux puede implementar manifiestos de Kubernetes, charts de Helm y archivos de Kustomization en AKS. Flux es un proceso basado en sondeos, por lo que puede detectar, extraer y conciliar los cambios de configuración sin exponer los puntos de conexión del clúster a los agentes de compilación.

En este escenario, los administradores de Kubernetes pueden cambiar objetos de configuración de Kubernetes, como secretos y ConfigMaps, y confirmar los cambios directamente en un repositorio de GitHub.

El siguiente flujo de datos corresponde al diagrama anterior:

  1. El desarrollador confirma los cambios de configuración en el repositorio de GitHub.

  2. Flux detecta el desfase de configuración en el repositorio de Git y extrae los cambios de configuración.

  3. Flux concilia el estado en el clúster de Kubernetes.

Alternativas para el escenario 1

  • Puede usar Flux con otros repositorios de Git, como Azure DevOps, GitLab y Bitbucket.

  • En lugar de los repositorios de Git, flux Bucket API define un origen para generar un artefacto para objetos de soluciones de almacenamiento como los cubos de Amazon S3 y Google Cloud Storage. También puede usar una solución que tenga una API compatible con S3. Dos ejemplos son MinIO y Alibaba Cloud Object Storage Service (OSS), pero hay otras soluciones.

  • También puede configurar Flux en un contenedor de Azure Blob Storage como origen para generar artefactos. Para obtener más información, consulte Configuraciones de Flux v2 de GitOps con AKS y Kubernetes habilitados para Azure Arc.

  • Flux v2 admite la multitenencia al permitir que los equipos implementen cargas de trabajo en un único clúster compartido de Kubernetes. Se pueden sincronizar varios repositorios de Git que representan un inquilino diferente al clúster. Para garantizar el aislamiento de cargas de trabajo entre equipos, cada equipo puede tener su propio espacio de nombres o varios espacios de nombres dentro del clúster de AKS, al que el acceso está restringido a través de políticas de control de acceso basado en roles (RBAC, Role-Based Access Control) de Kubernetes.

  • Flux puede usar un clúster para administrar las aplicaciones en el mismo clúster u otros clústeres. Un clúster hub de AKS con el operador Flux administra la entrega continua de GitOps de aplicaciones y cargas de trabajo de infraestructura a varios clústeres spoke de AKS.

Escenario 2: Uso de GitOps con Flux, GitHub y AKS para implementar CI/CD

Diagrama que muestra cómo implementar CI/CD mediante GitOps con Flux, GitHub y AKS.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos para el escenario 2

Este escenario es una canalización de DevOps basada en extracción para una aplicación web típica. Esta canalización usa Acciones de GitHub para compilar. Para la implementación, usa Flux como operador de GitOps para extraer y sincronizar la aplicación.

El siguiente flujo de datos corresponde al diagrama anterior:

  1. El código de la aplicación se desarrolla mediante un entorno de desarrollo integrado (IDE), como Visual Studio Code.

  2. El código de la aplicación se confirma en un repositorio de GitHub.

  3. Acciones de GitHub compila una imagen de contenedor desde el código de la aplicación e inserta la imagen de contenedor en Azure Container Registry.

  4. Las Acciones de GitHub actualizan un archivo de manifiesto de implementación de Kubernetes con la versión actual de la imagen, que se basa en el número de versión de la imagen de contenedor en el Registro de Contenedores.

  5. El operador Flux detecta el desfase de configuración en el repositorio de Git y extrae los cambios de configuración.

  6. Flux usa archivos de manifiesto para implementar la aplicación en el clúster de AKS.

Escenario 3: GitOps con Argo CD, repositorio de GitHub y AKS

Diagrama de GitOps con Argo CD, GitHub y AKS.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos para el escenario 3

Puede habilitar Argo CD como una extensión de clúster en AKS. En este escenario, el administrador de Kubernetes puede cambiar objetos de configuración de Kubernetes, como secretos y ConfigMaps, y confirmar los cambios directamente en el repositorio de GitHub.

El siguiente flujo de datos corresponde al diagrama anterior:

  1. El administrador de Kubernetes realiza cambios de configuración en los archivos YAML y confirma los cambios en el repositorio de GitHub.

  2. Argo CD extrae los cambios del repositorio de Git.

  3. Argo CD reconcilia los cambios de configuración en el clúster de AKS.

Argo CD no tiene que sincronizar automáticamente el estado de destino deseado con el clúster de AKS. Se implementa como un controlador de Kubernetes que supervisa continuamente las aplicaciones en ejecución. Compara el estado activo actual del clúster de AKS con el estado de destino deseado especificado en el repositorio de Git. Argo CD informa y visualiza las diferencias y proporciona herramientas para sincronizar automáticamente o manualmente el estado activo con el estado de destino deseado.

Argo CD proporciona una interfaz de usuario basada en explorador. Puede usarlo para agregar configuraciones de aplicación, observar el estado de sincronización con respecto al clúster e iniciar la sincronización en el clúster. También puede usar la línea de comandos de Argo CD para realizar estas tareas. Tanto la interfaz de usuario como la interfaz de la línea de comandos proporcionan características para ver el historial de cambios de configuración y revertir a una versión anterior.

De forma predeterminada, la interfaz de usuario de Argo CD y el servidor de API no están expuestos. Para acceder a ellos, se recomienda crear un controlador de entrada que tenga una dirección IP interna. O bien, puede usar un equilibrador de carga interno para exponerlos.

Alternativas para el escenario 3

Cualquier repositorio compatible con Git, incluido Azure DevOps, puede servir como repositorio de origen de configuración.

Escenario 4: Uso de GitOps con Argo CD, Acciones de GitHub y AKS para implementar CI/CD

Diagrama que muestra cómo implementar CI/CD mediante GitOps con Argo CD, GitHub y AKS.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos para el escenario 4

Este escenario es una canalización de DevOps basada en extracción para una aplicación web típica. Esta canalización usa Acciones de GitHub para compilar. Para la implementación, usa Argo CD como operador de GitOps para extraer y sincronizar la aplicación.

El siguiente flujo de datos corresponde al diagrama anterior:

  1. El código de la aplicación se desarrolla mediante un IDE como Visual Studio Code.

  2. El código de la aplicación se confirma en un repositorio de GitHub.

  3. Acciones de GitHub compila una imagen de contenedor desde el código de la aplicación e inserta la imagen de contenedor en Container Registry.

  4. Acciones de GitHub actualiza un archivo de implementación de manifiesto de Kubernetes con la versión de imagen actual basada en el número de versión de la imagen de contenedor en Container Registry.

  5. Argo CD extrae del repositorio de Git.

  6. Argo CD implementa la aplicación en el clúster de AKS.

Alternativas para el escenario 4

Cualquier repositorio compatible con Git, incluido Azure DevOps, puede servir como repositorio de origen de configuración.

Detalles del escenario

GitOps es un conjunto de principios para operar y administrar un sistema de software.

  • Usa el control de código fuente como fuente única de certeza para el sistema.

  • Aplica prácticas de desarrollo como control de versiones, colaboración, cumplimiento e integración continua e implementación continua (CI/CD) a la automatización de la infraestructura.

  • Puede aplicarlo a cualquier sistema de software.

GitOps se utiliza a menudo para la administración de clústeres de Kubernetes y la entrega de aplicaciones.

Según los principios de GitOps, el estado deseado de un sistema administrado por GitOps debe cumplir los siguientes criterios:

  • Declarativo: Un sistema que Administra GitOps debe tener su estado deseado expresado declarativamente. La declaración se almacena normalmente en un repositorio de Git.

  • Versionado e inmutable: El estado deseado se almacena de una manera que aplica inmutabilidad y control de versiones, y conserva un historial de versiones completo.

  • Se extrajo automáticamente: Los agentes de software extraen automáticamente las declaraciones de estado deseadas del origen.

  • Reconciliado continuamente: Los agentes de software observan continuamente el estado real del sistema e intentan aplicar el estado deseado.

En GitOps, IaC usa código para declarar el estado deseado de los componentes de infraestructura, como máquinas virtuales, redes y firewalls. Este código tiene control de versiones y es auditable.

Kubernetes describe todo, desde el estado del clúster hasta las implementaciones de aplicaciones mediante declaración mediante manifiestos. GitOps para Kubernetes coloca el estado deseado de la infraestructura del clúster bajo el control de versiones. Un componente del clúster, normalmente denominado operador, sincroniza continuamente el estado declarativo. Este enfoque permite revisar y auditar los cambios de código que afectan al clúster. Mejora la seguridad al admitir el principio de privilegios mínimos (PoLP).

Los agentes de GitOps reconcilian continuamente el estado del sistema con el estado deseado que se almacena en el repositorio de código. Algunos agentes de GitOps pueden revertir las operaciones que se realizan fuera del clúster, como la creación manual de objetos de Kubernetes. Por ejemplo, los controladores de admisión aplican directivas en objetos durante las operaciones de creación, actualización y eliminación. Puede usarlos para asegurarse de que las implementaciones solo cambian si cambia el código de implementación en el repositorio de origen.

Puede combinar las herramientas de cumplimiento y administración de directivas con GitOps para aplicar directivas y proporcionar comentarios sobre los cambios de directiva propuestos. Puede configurar notificaciones para que los equipos individuales los mantengan informados sobre el estado actual de GitOps. Por ejemplo, puede enviar notificaciones de los éxitos de implementación y los errores de conciliación.

GitOps como origen único de certeza

GitOps proporciona coherencia y estandarización del estado del clúster y puede ayudar a mejorar la seguridad. También puede usar GitOps para garantizar un estado coherente entre varios clústeres. Por ejemplo, GitOps puede aplicar la misma configuración en clústeres principales y de recuperación ante desastres (DR) o en un conjunto de clústeres.

Para aplicar GitOps como el único método para cambiar el estado del clúster, restrinja el acceso directo al clúster. Para establecer esta configuración, use el control de acceso basado en rol de Azure (RBAC de Azure), los controladores de admisión u otras herramientas.

Uso de GitOps para arrancar la configuración inicial

A veces, se requiere la implementación del clúster de AKS como parte de la configuración de línea base. Por ejemplo, es posible que tenga que implementar servicios compartidos o configuraciones de nivel de sistema antes de implementar cargas de trabajo de aplicación. Estos servicios compartidos pueden configurar los siguientes complementos y herramientas:

Puede habilitar Flux como una extensión que se aplica al crear un clúster de AKS. Después, Flux puede arrancar la configuración de línea base en el clúster. La arquitectura de línea de base de un clúster de AKS recomienda usar GitOps para el arranque. Si usa la extensión Flux, puede arrancar clústeres poco después de la implementación.

Otras herramientas y complementos de GitOps

Puede ampliar los escenarios descritos a otras herramientas de GitOps. Jenkins X es otra herramienta de GitOps que proporciona instrucciones para la integración en Azure. Puede usar herramientas de entrega progresiva, como Flagger, para el cambio gradual de las cargas de trabajo de producción que se implementan a través de GitOps.

Posibles casos de uso

Esta solución beneficia a las organizaciones que desean implementar aplicaciones e IaC y mantener una pista de auditoría de cada cambio.

GitOps simplifica la administración de contenedores para los desarrolladores, lo que mejora la productividad. Los desarrolladores pueden seguir trabajando con herramientas conocidas, como Git, para administrar actualizaciones y nuevas características.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Confiabilidad

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Si un clúster deja de estar disponible, Se debe usar GitOps como parte de la creación de un nuevo clúster. Usa el repositorio de Git como origen único de certeza para la configuración de Kubernetes y la lógica de la aplicación. Puede crear y aplicar la configuración del clúster y la implementación de aplicaciones como unidad de escalado, y también es capaz de establecer el patrón de sellos de implementación.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Con el enfoque de GitOps, los desarrolladores o administradores individuales no acceden directamente a los clústeres de Kubernetes para aplicar cambios o actualizaciones. En su lugar, los usuarios insertan cambios en un repositorio de Git y el operador de GitOps, como Flux o Argo CD, lee los cambios y los aplica al clúster. Este enfoque sigue el procedimiento recomendado de seguridad de privilegios mínimos al no conceder permisos de escritura a los equipos de DevOps a la API de Kubernetes. En escenarios de diagnóstico o solución de problemas, puede conceder permisos de clúster durante un tiempo limitado caso por caso.

Además de configurar permisos de repositorio, considere la posibilidad de implementar las siguientes medidas de seguridad en repositorios de Git que se sincronizan con clústeres de AKS:

  • Protección de ramas: proteja las ramas que representan el estado de los clústeres de Kubernetes frente a los cambios que se insertan directamente en ellas. Use solicitudes de incorporación de cambios (PR) para realizar cambios y haga que al menos otra persona revise cada solicitud de incorporación de cambios. Use también solicitudes de incorporación de cambios para realizar comprobaciones automáticas.

  • Revisión de pr: Requerir que las solicitudes de incorporación de cambios tengan al menos un revisor para aplicar el principio de cuatro ojos. También puede usar la característica de propietarios de código de GitHub para definir usuarios o equipos responsables de revisar archivos específicos de un repositorio.

  • Historial inmutable: permita solo nuevas confirmaciones a partir de los cambios existentes. El historial inmutable es especialmente importante para fines de auditoría.

  • Medidas de seguridad adicionales: Exija a los usuarios de GitHub que activen la autenticación en dos fases. Permitir solo confirmaciones firmadas para evitar cambios.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

  • El nivel gratis de AKS proporciona administración de clústeres gratuita. Los costos se limitan a los recursos de proceso, almacenamiento y redes que utiliza AKS para hospedar nodos. El nivel gratis de AKS no incluye un acuerdo de nivel de servicio (SLA) y no se recomienda para cargas de trabajo de producción.

  • GitHub proporciona un servicio gratuito, pero para usar características avanzadas relacionadas con la seguridad, como propietarios de código o revisores necesarios, necesita el plan de equipo. Para más información, consulte Precios de GitHub.

  • Azure DevOps proporciona un nivel gratuito que puede usar para algunos escenarios.

  • Puede usar la calculadora de precios de Azure para calcular los costos.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

GitOps puede aumentar la productividad de DevOps. Una de las características más útiles es la capacidad de revertir rápidamente los cambios que se comportan inesperadamente mediante la realización de operaciones de Git. El gráfico de confirmación sigue conteniendo todas las confirmaciones, por lo que puede ayudar con el análisis retrospectivo.

Los equipos de GitOps suelen administrar varios entornos para la misma aplicación. Es habitual tener varias fases de una aplicación que se implementan en distintos clústeres o espacios de nombres de Kubernetes. El repositorio de Git, que es el único origen de certeza, muestra qué versiones de las aplicaciones están implementadas actualmente en un clúster.

Implementación de un escenario

Para obtener más información sobre la implementación de los cinco escenarios, consulte los siguientes recursos:

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes