Implementaciones de aplicaciones con GitOps (Flux v2) en AKS y Azure Arc habilitado para Kubernetes

Azure proporciona una funcionalidad de implementaciones de aplicaciones automatizadas mediante GitOps que funciona con Azure Kubernetes Service (AKS) y clústeres de Kubernetes habilitados para Azure Arc. Entre las principales ventajas que proporciona la adopción de GitOps para implementar aplicaciones en clústeres de Kubernetes se incluyen:

• Visibilidad continua del estado de las aplicaciones que se ejecutan en clústeres.
• Separación de preocupaciones entre los equipos de desarrollo de aplicaciones y los equipos de infraestructura. Los equipos de aplicaciones no necesitan tener experiencia con las implementaciones de Kubernetes. Normalmente, los equipos de ingeniería de plataforma crean un modelo de autoservicio para los equipos de aplicaciones, lo que les permite ejecutar implementaciones con mayor confianza.
• Capacidad de volver a crear clústeres con el mismo estado deseado en caso de bloqueo o de escalado horizontal.
• Capacidad de implementar aplicaciones a gran escala a través de Azure Policy.

Con GitOps, se declara el estado deseado de los clústeres de Kubernetes en archivos en repositorios de Git. Los repositorios de Git pueden contener los siguientes archivos:

• Manifiestos en formato YAML que describen recursos de Kubernetes (como espacios de nombres, secretos, implementaciones, etc.)
• Gráficos de Helm para implementar aplicaciones
• Archivos de Kustomize para describir cambios específicos del entorno

Dado que estos archivos se almacenan en un repositorio de Git, se les realiza un control de versiones y se realiza un seguimiento sencillo de los cambios entre versiones. Los controladores de Kubernetes se ejecutan en los clústeres y concilian continuamente el estado del 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. Los operadores también garantizan continuamente que el clúster permanece en el estado deseado.

GitOps en Kubernetes habilitado para Azure Arc o en Azure Kubernetes Service utiliza Flux, un popular conjunto de herramientas de código abierto. Flux proporciona compatibilidad con orígenes de archivos comunes (repositorios de Git y Helm, cubos, Azure Blob Storage) y tipos de plantilla (YAML, Helm y Kustomize). Flux también admite multiinquilino y la administración de dependencias de implementación, entre otras características.

Flux se implementa directamente en el clúster y el plano de control de cada clúster está separado lógicamente. Esto hace que se escale bien a cientos y miles de clústeres. Flux permite implementaciones de aplicaciones de GitOps basadas en extracción puras. El repositorio de origen no necesita acceso a los clústeres ni a ningún otro clúster.

Extensión de clúster de Flux

GitOps está habilitado en un clúster de Kubernetes habilitado para Azure Arc o de AKS como un Microsoft.KubernetesConfiguration/extensions/microsoft.fluxrecurso de extensión de clúster. La extensión microsoft.flux debe instalarse en el clúster antes de que uno o más fluxConfigurations puedan crearse. La extensión se instala automáticamente al crear la primera Microsoft.KubernetesConfiguration/fluxConfigurations en un clúster, o bien puede instalarla manualmente mediante el portal, la CLI de Azure (az k8s-extension create --extensionType=microsoft.flux), la plantilla de ARM o la API REST.

Controladores

De forma predeterminada, la extensión microsoft.flux instala los controladores de Flux (Origen, Kustomize, Helm, Notification) y la definición de recursos personalizados (CRD) FluxConfig, fluxconfig-agent y fluxconfig-controller. Opcionalmente, también puede instalar los controladores de Flux image-automation y image-reflector, que proporcionan funcionalidad para actualizar y recuperar imágenes de Docker.

• controlador de origen de Flux: inspecciona los recursos personalizados de source.toolkit.fluxcd.io. Controla la sincronización entre los repositorios de Git, los repositorios de Helm, Buckets y Azure Blob Storage. Controla la autorización con el origen de Git privado, repositorios de Helm y cuentas de Azure Blob Storage. Saca a la superficie los cambios más recientes en el origen a través de un archivo de nivel de archivo tar.

• Controlador Kustomize de Flux: vigila los recursos personalizados kustomization.toolkit.fluxcd.io. Aplica archivos YAML sin procesar o Kustomize desde el origen al clúster.

• Controlador Helm de Flux: vigila los recursos personalizadoshelm.toolkit.fluxcd.io. Recupera el gráfico asociado del origen del repositorio de Helm, que es sacado a la superficie por el controlador Source. Crea el recurso personalizado HelmChart y aplica el HelmRelease al clúster con dicha versión, nombre y valores definidos por el cliente.

• Controlador de Notificación de Flux: supervisa los recursos personalizados notification.toolkit.fluxcd.io. Recibe notificaciones de todos los controladores de Flux. Inserta notificaciones en puntos de conexión de webhook definidos por el usuario.

• Definiciones de recursos personalizados de Flux:

  • kustomizations.kustomize.toolkit.fluxcd.io
  • imagepolicies.image.toolkit.fluxcd.io
  • imagerepositories.image.toolkit.fluxcd.io
  • imageupdateautomations.image.toolkit.fluxcd.io
  • alerts.notification.toolkit.fluxcd.io
  • providers.notification.toolkit.fluxcd.io
  • receivers.notification.toolkit.fluxcd.io
  • buckets.source.toolkit.fluxcd.io
  • gitrepositories.source.toolkit.fluxcd.io
  • helmcharts.source.toolkit.fluxcd.io
  • helmrepositories.source.toolkit.fluxcd.io
  • helmreleases.helm.toolkit.fluxcd.io
  • fluxconfigs.clusterconfig.azure.com

• FLUXConfig CRD: Definición de recursos personalizados para fluxconfigs.clusterconfig.azure.com recursos personalizados que definen FluxConfig objetos de Kubernetes.

• fluxconfig-agent: Responsable de la vigilancia en Azure de los recursos fluxConfigurations nuevos o actualizados y de iniciar la configuración asociada de Flux en el clúster. También es responsable de insertar los cambios de estado de Flux en el clúster en Azure para cada recurso de fluxConfigurations.

• fluxconfig-controller: supervisa los recursos personalizados fluxconfigs.clusterconfig.azure.com y responde a los cambios con la configuración nueva o actualizada de la maquinaria de GitOps en el clúster.

Configuraciones de Flux

Para descargar diagramas de arquitectura en alta resolución, visite Jumpstart Gems.

Puede crear recursos de configuración de Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) para habilitar la administración de GitOps del clúster desde los repositorios de Git, orígenes de cubos o Azure Blob Storage. Al crear un recurso de fluxConfigurations, los valores proporcionados para los parámetros, como el repositorio de Git de destino, se usan para crear y configurar los objetos de Kubernetes que habilitan el proceso de GitOps en ese clúster. El servicio de configuración del clúster almacena los datos del recurso fluxConfigurations cifrados y en reposo en una base de datos de Azure Cosmos DB, para garantizar su confidencialidad.

Los agentes fluxconfig-agent y fluxconfig-controller, instalados con la extensión microsoft.flux, administran el proceso de configuración de GitOps.

fluxconfig-agent es responsable de las siguientes tareas:

• Sondear el servicio del plano de datos de configuración de Kubernetes para obtener recursos fluxConfigurations nuevos o actualizados.
• Crear o actualizar recursos personalizados FluxConfig en el clúster con la información de configuración.
• Vigila los recursos personalizados FluxConfig y devuelve los cambios de estado a los recursos de Azure fluxConfiguration asociados.

fluxconfig-controller es responsable de las siguientes tareas:

• Monitoriza las actualizaciones de estado de los recursos personalizados de Flux creados por el administrado fluxConfigurations.
• Crear un par de claves pública y privada que existen durante la vigencia de fluxConfigurations. Esta clave se usa para la autenticación si la dirección URL está basada en SSH y si el usuario no proporciona su propia clave privada durante la creación de la configuración.
• Crea un secreto de autenticación personalizado basado en los datos private-key/http basic-auth/known-hosts/no-auth proporcionados por el usuario.
• Configura el control de acceso basado en roles (cuenta de servicio aprovisionada, vinculación de roles creada/asignada, rol creado/asignado).
• Crea un recurso personalizado GitRepository o Bucket y recursos personalizados Kustomization a partir de la información del recurso personalizado FluxConfig.

Cada recurso fluxConfigurations de Azure está asociado a un recurso personalizado de Flux GitRepository o Bucket uno o varios recursos personalizados Kustomization en un clúster de Kubernetes. Al crear un recurso de fluxConfigurations, especifique la dirección URL para el origen (repositorio de Git, Bucket o Azure Blob Storage) y el destino de sincronización en el origen de cada Kustomization. Puede configurar dependencias entre recursos personalizados Kustomization para controlar la secuenciación de la implementación. También puede crear varios recursos de ámbito de espacio de nombres fluxConfigurations en el mismo clúster para diferentes aplicaciones y equipos de aplicaciones.

Puede supervisar el estado y el cumplimiento de la configuración de Flux en Azure Portal o usar paneles para supervisar el estado, el cumplimiento, el consumo de recursos y la actividad de conciliación. Para obtener más información, consulte Supervisar el estado y la actividad de GitOps (Flux v2).

Compatibilidad con versiones

Se admite la versión más reciente de la extensión Flux v2 (microsoft.flux) y las dos versiones anteriores (N-2). Por lo general, se recomienda usar la versión más reciente de la extensión. A partir de microsoft.flux versión 1.7.0, se admiten clústeres basados en ARM64.

GitOps con vínculo privado

Si ha agregado compatibilidad con el vínculo privado a un clúster de Kubernetes habilitado para Azure Arc, la extensión microsoft.flux funciona de serie con la comunicación a Azure. Para las conexiones con el repositorio de Git, el repositorio de Helm o cualquier otro punto de conexión necesario para implementar los manifiestos de Kubernetes, debe aprovisionar estos puntos de conexión detrás del firewall o enumerarlos en el firewall para que el controlador de origen de Flux pueda acceder a ellos correctamente.

Residencia de datos

El servicio Azure GitOps (Azure Kubernetes Configuration Management) almacena o procesa los datos de los clientes. De manera predeterminada, los datos del cliente se replican en la región emparejada. Para las regiones de Singapur, Este de Asia y Sur de Brasil, todos los datos de los clientes se almacenan y procesan en la región.

Aplicación de configuraciones de Flux a gran escala

Puesto que Azure Resource Manager administra las configuraciones, puede automatizar la creación de la misma configuración en todos los recursos de Azure Kubernetes Service y de Kubernetes habilitado para Azure Arc mediante Azure Policy, en el ámbito de una suscripción o de un grupo de recursos. Esta aplicación a escala garantiza que las configuraciones específicas se apliquen de forma coherente en todos los grupos de clústeres.

Para obtener más información, consulte Implementación de aplicaciones de forma coherente a escala mediante configuraciones de Flux v2 y Azure Policy.

Parámetros

Para ver todos los parámetros admitidos por Flux v2 en Azure, consulte laaz k8s-configuration documentación. La implementación de Azure no admite actualmente todos los parámetros que admite Flux.

Para obtener información sobre los parámetros disponibles y cómo usarlos, vea parámetros compatibles con GitOps (Flux v2).

Servicios multiinquilino

Flux v2 admite multiinquilino a partir de la versión 0.26. Esta funcionalidad se integra en Flux v2 en Azure.

Actualización de manifiestos para el uso de varios inquilinos

Supongamos que implementa un fluxConfiguration en uno de nuestros clústeres de Kubernetes en el espacio de nombres cluster-config con ámbito de clúster. Se configura el origen para que se sincronice con el repositorio https://github.com/fluxcd/flux2-kustomize-helm-example. Este es el mismo repositorio de Git de ejemplo que se usa en el tutorial Implementación de aplicaciones mediante GitOps con Flux v2.

Una vez que Flux sincroniza el repositorio, implementa los recursos descritos en los manifiestos (archivos YAML). Dos de los manifiestos describen objetos HelmRelease y HelmRepository.

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: nginx
spec:
  releaseName: nginx-ingress-controller
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

De forma predeterminada, la extensión Flux implementa el fluxConfigurations suplantando la cuenta de servicio de flux-applier que se implementa solo en el espacio de nombres cluster-config. Con los manifiestos anteriores, cuando está habilitado el multiinquilino, el HelmRelease se bloquearía. Esto se debe a que el HelmRelease está en el espacio de nombres nginx, pero hace referencia a un HelmRepository en el espacio de nombres flux-system. Además, el Flux helm-controller no puede aplicar el HelmRelease, porque no hay ninguna cuenta de servicio flux-applier en el espacio de nombres nginx.

Para trabajar con el uso de varios inquilinos, el enfoque correcto es implementar todos los objetos de Flux en el mismo espacio de nombres que fluxConfigurations. Este enfoque evita el problema de referencia entre espacios de nombres y permite que los controladores de Flux obtengan los permisos para aplicar los objetos. Por lo tanto, para una configuración de GitOps creada en el espacio de nombres cluster-config, estos manifiestos de ejemplo cambiarían de la siguiente manera:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: cluster-config 
spec:
  releaseName: nginx-ingress-controller
  targetNamespace: nginx
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: cluster-config
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: cluster-config
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

Rechazo del uso de varios inquilinos

Cuando se instala la extensión microsoft.flux, el multiinquilino está habilitado de forma predeterminada. Si necesita deshabilitar los servicios multiinquilino, puede optar por crear o actualizar la extensión de microsoft.flux en los clústeres con --configuration-settings multiTenancy.enforce=false, como se muestra en estos comandos de ejemplo:

az k8s-extension create --extension-type microsoft.flux --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

az k8s-extension update --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

Pasos siguientes

• Utiliza nuestro tutorial para aprender a habilitar GitOps en clústeres AKS o de Kubernetes habilitados con Azure Arc.
• Obtenga información sobre flujo de trabajo de CI/CD mediante GitOps.