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. Opcionalmente, pode também 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. Manipula a sincronização entre os repositórios Git, repositórios Helm, Buckets e armazenamento de Blob do Azure. Gere a autorização com a fonte para repositórios privados Git, Helm e contas de armazenamento de blobs do 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: Responsável por observar o Azure em busca de recursos novos ou atualizados fluxConfigurations e por iniciar a configuração do Flux associada no cluster. Também é responsável por enviar de volta para o Azure as alterações de estado do Flux no cluster para cada recurso fluxConfigurations.

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

Você cria recursos de configuração do Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) para habilitar o gerenciamento do GitOps do cluster a partir dos seus repositórios Git, fontes de bucket ou armazenamento de Blob do Azure. 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, os dados do recurso fluxConfigurations são guardados encriptados quando em repouso numa base de dados do Azure Cosmos DB pelo serviço de configuração do cluster.

Os fluxconfig-agent e fluxconfig-controller agentes, instalados com microsoft.flux extensão, 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. Ao criar um fluxConfigurations recurso, você especifica a URL para a origem (repositório Git, Bucket ou armazenamento de Blob do Azure) e o destino de sincronização na origem 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. Geralmente, recomendamos que você 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 adicionar suporte para link privado a um cluster Kubernetes habilitado para Azure Arc, a microsoft.flux extensão funciona imediatamente com comunicação de volta para o Azure. Para conexões com o seu repositório Git, repositório Helm ou quaisquer outros endpoints necessários para implantar os manifestos do Kubernetes, deve provisionar esses endpoints atrás do firewall ou listá-los no firewall, para que o controlador Flux Source possa aceder-lhes com sucesso.

Residência de dados

O serviço GitOps do Azure (Gerenciamento de Configuração do Kubernetes do Azure) armazena/processa dados do cliente. 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 gerencia suas configurações, você pode automatizar a criação da mesma configuração em todos os recursos do Serviço Kubernetes do Azure e do Kubernetes habilitado para Azure Arc usando a Política do Azure, dentro do escopo de uma assinatura 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

Digamos que tu implementes um fluxConfiguration num dos nossos clusters Kubernetes no namespace cluster-config com escopo 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 acima, quando a multilocação está habilitada, o HelmRelease seria bloqueado. Isso ocorre porque o HelmRelease está no namespace nginx, mas faz referência a um HelmRepository no namespace flux-system. Além disso, o Flux helm-controller não pode aplicar o HelmRelease, porque não há nenhuma flux-applier conta de serviço no nginx namespace.

Para trabalhar com multi-tenancy, a abordagem correta é implantar 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 do GitOps criada no cluster-config namespace, esses manifestos de exemplo mudariam da seguinte maneira:

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

Quando a extensão microsoft.flux é instalada, a multilocação é ativada por padrão. Se precisar desativar a multilocação, você pode desativar criando ou atualizando a microsoft.flux extensão em seus clusters com --configuration-settings multiTenancy.enforce=false, conforme mostrado nestes comandos de exemplo:

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.