Implantações de aplicativos com GitOps (Flux v2) para AKS e Kubernetes habilitado para o Azure Arc

O Azure fornece um recurso de implantações automatizadas de aplicativos usando o GitOps que funciona com o Serviço Kubernetes do Azure (AKS) e clusters Kubernetes habilitados para Azure Arc. Os principais benefícios fornecidos pela adoção do GitOps para implantar aplicativos em clusters Kubernetes incluem:

• Visibilidade contínua do status de aplicativos em execução em clusters.
• Separação de preocupações entre equipes de desenvolvimento de aplicativos e equipes de infraestrutura. As equipes de aplicativos não precisam ter experiência com implantações do Kubernetes. As equipes de engenharia de plataforma normalmente criam um modelo de autoatendimento para equipes de aplicativos, capacitando-as a executar implantações com maior confiança.
• Capacidade de recriar clusters com o mesmo estado desejado em caso de falha ou para aumentar a escala.
• Capacidade de implantar aplicativos em escala por meio da Política do Azure.

Com o GitOps, você declara o estado desejado de seus clusters Kubernetes em arquivos nos repositórios Git. Os repositórios Git podem conter os seguintes arquivos:

• Manifestos formatados em YAML que descrevem recursos do Kubernetes (como namespaces, segredos, implantações e outros)
• Helm charts para implantação de aplicações
• Kustomize arquivos para descrever alterações específicas do ambiente

Como esses arquivos são armazenados em um repositório Git, eles são versionados e as alterações entre as versões são facilmente rastreadas. Os controladores Kubernetes são executados nos clusters e reconciliam continuamente o estado do cluster com o estado desejado declarado no repositório Git. Esses operadores extraem os arquivos dos repositórios Git e aplicam o estado desejado aos clusters. Os operadores também garantem continuamente que o cluster permanece no estado desejado.

O GitOps no Kubernetes habilitado para Azure Arc ou no Serviço Kubernetes do Azure usa Flux, um conjunto de ferramentas de código aberto popular. O Flux fornece suporte para fontes de arquivos comuns (repositórios Git e Helm, Buckets, Armazenamento de Blobs do Azure) e tipos de modelo (YAML, Helm e Kustomize). O Flux também suporta gerenciamento de dependência de multilocação e implantação, entre outros recursos.

Flux é implantado diretamente no cluster, e o plano de controle de cada cluster é logicamente separado. Permite que ele seja escalável para centenas e milhares de clusters. O Flux permite implantações puras de aplicativos GitOps baseados em pull. Não precisa de acesso a clusters pelo repositório de origem nem por qualquer outro cluster.

Extensão do cluster de fluxo

O GitOps é habilitado em um cluster Kubernetes ou AKS habilitado para Azure Arc como um Microsoft.KubernetesConfiguration/extensions/microsoft.flux recurso de extensão de cluster. A microsoft.flux extensão deve ser instalada no cluster antes que um ou mais fluxConfigurations possam ser criados. A extensão é instalada automaticamente quando você cria a primeira Microsoft.KubernetesConfiguration/fluxConfigurations em um cluster ou pode instalá-la manualmente usando o portal, a CLI do Azure (az k8s-extension create --extensionType=microsoft.flux), o modelo ARM ou a API REST.

Controladores

Por padrão, a microsoft.flux extensão instala os controladores Flux (Source, Kustomize, Helm, Notification) e o FluxConfig Custom Resource Definition (CRD), fluxconfig-agente fluxconfig-controller. Também pode instalar os controladores Flux image-automation e image-reflector, que fornecem funcionalidade para atualizar e obter imagens do Docker.

• Flux Source controller: Observa os source.toolkit.fluxcd.io recursos personalizados. Trata da sincronização entre os repositórios Git, repositórios Helm, Buckets e armazenamento Azure Blob. Trata da autorização com a origem para repositórios privados de Git, repositórios Helm e contas de armazenamento de blob Azure. Apresenta as alterações mais recentes na origem através de um arquivo tar archive.

• Controlador Flux Kustomize: Monitoriza os kustomization.toolkit.fluxcd.io recursos personalizados. Aplica Kustomize ou arquivos YAML brutos da origem no cluster.

• Controlador Flux Helm: Observa os helm.toolkit.fluxcd.io recursos personalizados. Recupera o gráfico associado da fonte do repositório Helm exibida pelo controlador Source. Cria o recurso personalizado HelmChart e aplica o HelmRelease com a versão, o nome e os valores definidos pelo cliente ao cluster.

• Controlador de notificação de fluxo: observa os notification.toolkit.fluxcd.io recursos personalizados. Recebe notificações de todos os controladores Flux. Envia push notifications para endpoints de webhook definidos pelo utilizador.

• Definições de recursos personalizados do 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: Definição de recursos personalizada para fluxconfigs.clusterconfig.azure.com recursos personalizados que definem FluxConfig objetos do Kubernetes.

• fluxconfig-agent: Observa o Azure para recursos novos ou atualizados fluxConfigurations e inicia a configuração Flux associada no cluster. Também empurra as alterações de estado do Flux no cluster de volta para o Azure para cada fluxConfigurations recurso.

• fluxconfig-controller: Observa os fluxconfigs.clusterconfig.azure.com recursos personalizados e, ao detetar alterações, responde com uma nova ou atualizada configuração do mecanismo GitOps no cluster.

Configurações de fluxo

Para baixar diagramas de arquitetura em alta resolução, visite Jumpstart Gems.

Crie recursos de configuração Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) para permitir a gestão GitOps do cluster a partir dos seus repositórios Git, fontes Bucket ou armazenamento Azure Blob. Quando você cria um fluxConfigurations recurso, os valores fornecidos para os parâmetros, como o repositório Git de destino, são usados para criar e configurar os objetos Kubernetes que habilitam o processo GitOps nesse cluster. Para garantir a segurança dos dados, o serviço de Configuração de Cluster armazena fluxConfigurations os dados de recursos encriptados em repouso numa base de dados Azure Cosmos DB.

Os agentes fluxconfig-agent e fluxconfig-controller, instalados através da extensão microsoft.flux, gerem o processo de configuração do GitOps.

fluxconfig-agent é responsável pelas seguintes tarefas:

• Sonda o serviço de plano de dados de Configuração do Kubernetes em busca de recursos novos ou atualizados fluxConfigurations .
• Cria ou atualiza FluxConfig recursos personalizados no cluster com as informações de configuração.
• Monitora FluxConfig recursos personalizados e envia as alterações de status de volta para os recursos associados do Azure fluxConfiguration.

fluxconfig-controller é responsável pelas seguintes tarefas:

• Monitoriza as atualizações de estado dos recursos personalizados do Flux criados pela gerida fluxConfigurations.
• Cria um par de chaves privado/público que existe durante o tempo de vida do fluxConfigurations. Essa chave é usada para autenticação se a URL for baseada em SSH e se o usuário não fornecer sua própria chave privada durante a criação da configuração.
• Cria segredo de autenticação personalizado com base em dados de chave privada/http basic-auth/known-hosts/no-auth fornecidos pelo usuário.
• Configura o controle de acesso baseado em função (conta de serviço provisionada, vinculação de função criada/atribuída, função criada/atribuída).
• Cria GitRepository ou Bucket recurso personalizado e Kustomization recursos personalizados a partir das informações no FluxConfig recurso personalizado.

Cada fluxConfigurations recurso no Azure está associado a um Flux GitRepository ou Bucket recurso personalizado e a um ou mais Kustomization recursos personalizados em um cluster Kubernetes. Quando crias um fluxConfigurations recurso, especificas o URL da fonte (repositório Git, Bucket ou armazenamento Azure Blob) e o destino de sincronização na fonte para cada Kustomization. Você pode configurar dependências entre Kustomization recursos personalizados para controlar o sequenciamento de implantação. Você também pode criar vários recursos com fluxConfigurations escopo de namespace no mesmo cluster para diferentes aplicativos e equipes de aplicativos.

Você pode monitorar o status de configuração e a conformidade do Flux no portal do Azure ou usar painéis para monitorar o status, a conformidade, o consumo de recursos e a atividade de reconciliação. Para obter mais informações, consulte Monitorar o status e a atividade do GitOps (Flux v2).

Suporte de versões

A versão mais recente da extensão Flux v2 (microsoft.flux) e as duas versões anteriores (N-2) são suportadas. Use a versão mais recente da extensão. A partir da versão 1.7.0, há suporte para microsoft.flux clusters baseados em ARM64.

GitOps com link privado

Se adicionares suporte para ligação privada a um cluster Kubernetes habilitado com Azure Arc, a microsoft.flux extensão funciona de imediato com comunicação de volta para Azure. Para ligações ao seu repositório Git, repositório Helm ou quaisquer outros endpoints necessários para implementar os seus manifestos Kubernetes, deve ou provisionar estes endpoints atrás do firewall ou listá-los no firewall, para que o controlador Flux Source possa aceder com sucesso.

Residência de dados

O serviço Azure GitOps (Azure Kubernetes Configuration Management) armazena e processa dados dos clientes. Por padrão, os dados do cliente são replicados para a região emparelhada. Para as regiões Cingapura, Leste Asiático e Sul do Brasil, todos os dados do cliente são armazenados e processados na região.

Aplicar configurações de fluxo em escala

Como o Azure Resource Manager gere as suas configurações, pode automatizar a criação da mesma configuração em todos os recursos Azure Kubernetes Service e Kubernetes habilitados com Azure Arc, usando o Azure Policy, dentro do âmbito de uma subscrição ou de um grupo de recursos. Essa imposição em escala garante que configurações específicas sejam aplicadas de forma consistente em grupos inteiros de clusters.

Para obter mais informações, consulte Implantar aplicativos consistentemente em escala usando as configurações do Flux v2 e a Política do Azure.

Parâmetros

Para ver todos os parâmetros suportados pelo Flux v2 no Azure, consulte a az k8s-configuration documentação. Atualmente, a implementação do Azure não suporta todos os parâmetros suportados pelo Flux.

Para obter informações sobre os parâmetros disponíveis e como usá-los, consulte Parâmetros suportados pelo GitOps (Flux v2).

Multitenancy

O Flux v2 suporta multilocação a partir da versão 0.26. Esse recurso é integrado ao Flux v2 no Azure.

Atualizar manifestos para multilocação

Suponha que você implanta um fluxConfiguration num dos seus clusters Kubernetes no espaço de nome cluster-config com âmbito de cluster. Você configura a fonte para sincronizar o https://github.com/fluxcd/flux2-kustomize-helm-example repositório. Este é o mesmo exemplo de repositório Git usado no tutorial Implantar aplicativos usando GitOps com Flux v2.

Depois que o Flux sincroniza o repo, ele implanta os recursos descritos nos manifestos (arquivos YAML). Dois dos manifestos descrevem HelmRelease e HelmRepository objetos.

apiVersion: helm.toolkit.fluxcd.io/v2
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

Por padrão, a extensão Flux implanta o fluxConfigurations personificando a conta de serviço flux-applier que é implantada apenas no namespace cluster-config. Usando os manifestos anteriores, quando o multi-arrendamento está ativado, o HelmRelease é bloqueado. Este bloco acontece porque o HelmRelease está no espaço de nomes nginx, mas faz referência a um HelmRepository no espaço de nomes flux-system. Além disso, o Flux helm-controller não pode aplicar o HelmRelease, porque não há conta de serviço flux-applier no namespace nginx.

Para trabalhar com multi-tenancy, desloque todos os objetos Flux no mesmo namespace que o fluxConfigurations. Essa abordagem evita o problema de referência entre namespaces e permite que os controladores Flux obtenham as permissões para aplicar os objetos. Assim, para uma configuração GitOps criada no cluster-config namespace, estes manifestos de exemplo mudam da seguinte forma:

apiVersion: helm.toolkit.fluxcd.io/v2
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

Optar por não participar no multiarrendamento

Ao instalar a extensão microsoft.flux, o multi-inquilino é ativado por defeito. Para desativar a funcionalidade de multi-inquilino, saia criando ou atualizando a extensão microsoft.flux nos clusters com --configuration-settings multiTenancy.enforce=false, conforme mostrado nos exemplos de comandos a seguir:

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>

Próximos passos

• Use nosso tutorial para saber como habilitar o GitOps em seus clusters Kubernetes habilitados para AKS ou Azure Arc.
• Saiba mais sobre o fluxo de trabalho de CI/CD usando o GitOps.