Editar

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.

Architecture

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 nativa para AKS. Las extensiones de clúster proporcionan 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 obtener 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, gráficos 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 flujo de datos de este escenario es:

  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, la API de Flux Bucket define un origen para generar un artefacto para objetos de soluciones de almacenamiento como Amazon S3 y cubos de Google Cloud Storage. También puede usar una solución que tenga una API compatible con S3. Dos ejemplos son Minio y Alibaba Cloud OSS, pero hay otros.
  • 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.

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

Diagrama de implementación de 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. Los datos fluyen por el escenario de la siguiente manera:

  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 Azure Container Registry.
  4. Acciones de GitHub actualiza un archivo de implementación de manifiesto de Kubernetes con la versión de imagen actual en función del número de versión de la imagen de contenedor en Azure Container Registry.
  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

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 flujo de datos de este escenario es:

  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, al tiempo que proporciona funciones 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 hacer estas cosas. 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 de implementación de 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. Los datos fluyen por el escenario de la siguiente manera:

  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 Azure Container Registry.
  4. Acciones de GitHub actualiza un archivo de implementación de manifiesto de Kubernetes con la versión de imagen actual en función del número de versión de la imagen de contenedor en Azure 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 el control de versiones, la colaboración, el cumplimiento y la 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. En este artículo se describen algunas opciones comunes para usar GitOps junto con un clúster de AKS.

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

  1. Declarativo: un sistema administrado por GitOps debe tener su estado deseado expresado mediante declaración. La declaración se almacena normalmente en un repositorio de Git.
  2. Con control de versiones e inmutable: el estado deseado se almacena de forma que se garantice la inmutabilidad y el control de versiones, y se conserve un historial de versiones completo.
  3. Extraído automáticamente: los agentes de software extraen automáticamente las declaraciones de estado deseadas del origen.
  4. Conciliado continuamente: los agentes de software observan continuamente el estado real del sistema e intentan aplicar el estado deseado.

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

En Kubernetes se describe todo de manera declarativa con manifiestos, desde el estado del clúster hasta las implementaciones de aplicaciones. 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 siguiendo el principio de privilegios mínimos.

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. Los controladores de admisión, por ejemplo, aplican directivas a 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 varios equipos les proporcionen el estado de GitOps actualizado. 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 primarios y de recuperación ante desastres (DR) o en una granja de clústeres.

Si quiere exigir que solo GitOps pueda cambiar el estado del clúster, puede restringir el acceso directo. Hay varias maneras de hacerlo, como el control de acceso basado en rol (RBAC) de Azure, los controladores de admisión y otras herramientas.

Uso de GitOps para arrancar la configuración inicial

Es posible que sea necesario implementar clústeres de AKS como parte de la configuración de línea de base. Un ejemplo es que tenga que implementar un conjunto de servicios compartidos o una configuración antes de implementar cargas de trabajo. Estos servicios compartidos pueden configurar complementos de AKS, como:

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 base para un clúster de AKS sugiere el uso de GitOps para el arranque. Si usa la extensión Flux, puede arrancar los clústeres muy 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 cualquier organización que quiera las ventajas de implementar las aplicaciones y la infraestructura como código, con una pista de auditoría de cada cambio.

GitOps protege al desarrollador de las complejidades de la administración de un entorno de contenedor. Los desarrolladores pueden seguir trabajando con herramientas conocidas, como Git, para administrar actualizaciones y nuevas características. De esta manera, GitOps mejora la productividad del desarrollador.

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 más información, consulte Marco de buena arquitectura de Microsoft Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Uno de los pilares clave de la fiabilidad es la resistencia. El objetivo de la resistencia es devolver la aplicación a un estado plenamente operativo después de un error. Si un clúster deja de estar disponible, GitOps puede crear uno nuevo rápidamente. 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 una unidad de escalado y puede establecer el patrón de sello de implementación.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de 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 (Flux o Argo CD) los lee 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 la tarea de configuración de permisos del repositorio, considere la posibilidad de implementar las siguientes medidas de seguridad en los 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 las PR para realizar cambios y haga que al menos otra persona las revise. Utilice también las PR para realizar comprobaciones automáticas.
  • Revisión de PR: requiera que las PR 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. Además, permita solo confirmaciones firmadas para evitar cambios.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

  • En el nivel gratuito, AKS ofrece administración de clústeres gratuita. Los costos se limitan a los recursos de proceso, almacenamiento y redes que utiliza AKS para hospedar nodos.
  • GitHub ofrece un servicio gratuito, pero para usar características avanzadas relacionadas con la seguridad, como los propietarios de código o los revisores necesarios, necesita el plan de Equipo. Para más información, consulte la página de precios de GitHub.
  • Azure DevOps ofrece 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 más información, consulte Introducción al pilar de 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 de forma inesperada, solo mediante la realización de operaciones de Git. El grafo de confirmaciones todavía contiene todas las confirmaciones, por lo que puede ayudar con el análisis post-mortem.

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

En la siguiente lista se proporcionan referencias para obtener información sobre la implementación de los cinco escenarios:

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

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

Pasos siguientes