Compartir a través de

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

  • Artículo

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.

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:

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 la administración de dependencias multiinquilino e 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 recurso Microsoft.KubernetesConfiguration/extensions/microsoft.flux 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 Notification de Flux: vigila 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 observar Azure de los recursos nuevos o actualizados fluxConfigurations y de iniciar la configuración de Flux asociada 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.

Nota:

La extensión microsoft.flux se instala en el espacio de nombres flux-system y tiene ámbito de todo el clúster. Esta extensión no se puede instalar en el ámbito del espacio de nombres.

Configuraciones de Flux

Diagrama que muestra la instalación de una configuración de Flux en un clúster de Kubernetes o AKS habilitado para Azure Arc.

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.
  • Vigilar los recursos personalizados FluxConfig e insertar de nuevo los cambios de estado en los recursos de Azure fluxConfiguration asociados.

fluxconfig-controller es responsable de las siguientes tareas:

  • Vigilar 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 rol (cuenta de servicio aprovisionada, enlace de roles creado/asignado, rol creado o 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.

Nota:

fluxconfig-agent supervisa los recursos fluxConfiguration nuevos o actualizados en Azure. El agente requiere conectividad a Azure para el estado deseado de que fluxConfiguration se aplique al clúster. Si el agente no se puede conectar a Azure, los cambios en el clúster esperan hasta que el agente pueda conectarse. Si el clúster está desconectado de Azure durante más de 48 horas, la solicitud al clúster agotará el tiempo de espera y los cambios deberán volver a aplicarse en Azure.

Las entradas confidenciales del cliente, como la clave privada y el token/contraseña, se almacenan durante menos de 48 horas en el servicio de configuración de Kubernetes. Si actualiza cualquiera de estos valores en Azure, asegúrese de que los clústeres se conecten con Azure en un plazo de 48 horas.

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.

Nota:

Si ha estado usando Flux v1, se recomienda migrar a Flux v2 lo antes posible.

La compatibilidad con los recursos de configuración de clúster basados en Flux v1 creados antes del 1 de enero de 2024 finalizará el 24 de mayo de 2025. A partir del 1 de enero de 2024, no podrá crear nuevos recursos de configuración de clúster basados en Flux v1.

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.

Nota:

Para la característica multiinquilino, debe saber si los manifiestos contienen cualquier sourceRef de espacio de nombres cruzado para HelmRelease, Kustomization, ImagePolicy u otros objetos, o si usa una versión de Kubernetes inferior a la 1.20.6. Para preparar:

  • Actualice a la versión 1.20.6 o posterior de Kubernetes.
  • En los manifiestos de Kubernetes, asegúrese de que todas las instancias de sourceRef se encuentran en objetos dentro del mismo espacio de nombres que la configuración de GitOps.

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 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>

Migración desde Flux v1

Si sigue usando Flux v1, se recomienda migrar a Flux v2 lo antes posible.

Para migrar al uso de Flux v2 en los mismos clústeres en los que ha estado usando Flux v1, primero debe eliminar todas las sourceControlConfigurations de Flux v1 de los clústeres. Dado que Flux v2 tiene una arquitectura fundamentalmente diferente, la extensión de clúster de microsoft.flux no se instalará si hay Flux v1 sourceControlConfigurations recursos en un clúster. El proceso de quitar configuraciones de Flux v1 e implementar configuraciones de Flux v2 no debe tardar más de 30 minutos.

Al quitar Flux v1 sourceControlConfigurations no se detiene ninguna aplicación que se ejecute en los clústeres. Sin embargo, durante el período en el que se quita la configuración de Flux v1 y la extensión Flux v2 aún no está totalmente implementada:

  • Si hay nuevos cambios en los manifiestos de aplicación almacenados en un repositorio de Git, estos cambios no se extraen durante la migración y la versión de la aplicación implementada en el clúster estará obsoleta.
  • Si hay cambios no deseados en el estado del clúster y se desvía del estado deseado especificado en el repositorio Git de origen, el clúster no podrá realizar la recuperación automática.

Se recomienda probar el escenario de migración en un entorno de desarrollo antes de migrar el entorno de producción.

Visualización y eliminación de configuraciones de Flux v1

Use estos comandos de la CLI de Azure para buscar y eliminar los recursos sourceControlConfigurations que hay en un clúster:

az k8s-configuration list --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
az k8s-configuration delete --name <configuration name> --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>

También puede encontrar y eliminar configuraciones de GitOps existentes para un clúster en Azure Portal. Para ello, vaya al clúster donde se creó la configuración y seleccione GitOps en el panel izquierdo. Seleccione la configuración y, a continuación, seleccione Eliminar.

Implementación de configuraciones de Flux v2

Use Azure Portal o la CLI de Azure para aplicar configuraciones de Flux v2 a los clústeres.

Información de retirada de Flux v1

El proyecto de código abierto de Flux v1 se ha archivado y desarrollo de características se ha detenido indefinidamente.

Flux v2 se inició como el proyecto de código abierto actualizado de Flux. Tiene una nueva arquitectura y admite más casos de uso de GitOps. Microsoft lanzó una versión de una extensión con Flux v2 en mayo de 2022. Desde entonces, se recomienda a los clientes pasar a Flux v2 en un plazo de tres años, ya que el soporte para usar Flux v1 está programado para finalizar en mayo de 2025.

Características nuevas clave introducidas en la extensión de GitOps para Flux v2:

  • Flux v1 es un operador monolítico do-it-all. Flux v2 separa las funcionalidades en controladores especializados (controlador de origen, controlador Kustomize, controlador de Helm y controlador de notificación).
  • Admite la sincronización con varios repositorios de origen.
  • Admite multiinquilino, como aplicar cada repositorio de origen con su propio conjunto de permisos.
  • Proporciona información operativa a través de comprobaciones de estado, eventos y alertas.
  • Admite ramas de Git, anclaje en confirmaciones y etiquetas, y después de los intervalos de etiquetas SemVer.
  • Configuración de credenciales por recurso de GitRepository: clave privada SSH, nombre de usuario/contraseña/token HTTP/S y claves públicas OpenPGP.

Pasos siguientes