Compartilhar via

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

  • Artigo

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

  • Visibilidade contínua do status dos 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 expansão.

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

Como esses arquivos são armazenados em um repositório Git, eles têm controle de versão e as alterações entre as versões são controladas com facilidade. Os controladores de Kubernetes são executados nos clusters e reconciliam continuamente o estado do cluster com o estado desejado declarado no repositório Git. Esses operadores efetuam pull dos arquivos dos repositórios Git e aplicam o estado desejado aos clusters. Os operadores também garantem continuamente que o cluster permaneça no estado desejado.

O GitOps no Kubernetes habilitado para Azure Arc ou no Serviço de Kubernetes do Azure usa o Flux, um popular conjunto de ferramentas de código aberto. O Flux dá suporte a fontes de arquivo comuns (repositórios do Git e do Helm, buckets, Armazenamento de Blobs do Azure) e tipos de modelo (YAML, Helm e Kustomize). O Flux também dá suporte ao gerenciamento de dependências de implantação e multilocatário, entre outros recursos.

O Flux é implantado diretamente no cluster e o plano de controle de cada cluster é separado logicamente. Isso faz com que ele seja dimensionado bem para centenas e milhares de clusters. O Flux habilita implantações de aplicativos GitOps baseadas em pull puro. Nenhum acesso aos clusters é necessário para o repositório de origem ou por qualquer outro cluster.

Extensão de cluster do Flux

GitOps está habilitado em um cluster do Kubernetes habilitado para Azure Arc ou AKS como um recurso Microsoft.KubernetesConfiguration/extensions/microsoft.flux de extensão do cluster. A extensão microsoft.flux precisa ser instalada no cluster antes que uma ou mais fluxConfigurations possam ser criadas. 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 do ARM ou a API REST.

Controladores

Por padrão, a extensão microsoft.flux instala os Controladores do Flux (Fonte, Kustomize, Helm, Notificação) e o CRD (Definição de Recurso Personalizado) do FluxConfig, fluxconfig-agent e fluxconfig-controller. Opcionalmente, você também pode instalar os controladores image-automation e image-reflector do Flux, que fornecem funcionalidade para atualizar e recuperar imagens do Docker.

  • Controlador de origem Flux: observa os recursos personalizados source.toolkit.fluxcd.io. Manipula a sincronização entre os repositórios Git, repositórios Kelm, Buckets e armazenamento de Blobs do Azure. Lida com a autorização na fonte para repositórios privados do Git e do Helm e contas de Armazenamento de Blobs do Azure. Exibe as alterações mais recentes na origem por meio de um arquivo morto TAR.

  • Controlador do Flux Kustomize: inspeciona os recursos personalizados de kustomization.toolkit.fluxcd.io. Aplica arquivos YAML brutos ou do Kustomize da origem ao cluster.

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

  • Controlador de notificação do Flux: inspeciona os recursos personalizados notification.toolkit.fluxcd.io. Recebe notificações de todos os controladores do Flux. Envia notificações por push para os pontos de extremidade de webhook definidos pelo usuário.

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

  • fluxconfig-agent: responsável por observar o Azure para obter recursos fluxConfigurations novos ou atualizados e para iniciar a configuração do Flux associada no cluster. Também responsável por enviar por push as alterações de status do Flux no cluster de volta para o Azure para cada recurso de fluxConfigurations.

  • fluxconfig-controller: observa o recursos personalizados fluxconfigs.clusterconfig.azure.com e responde às alterações com a configuração nova ou atualizada do computador GitOps no cluster.

Observação

A extensão microsoft.flux é instalada no namespace flux-system e tem escopo em todo o cluster. Não é possível instalar essa extensão no escopo do namespace.

Configurações do Flux

Diagrama que mostra a instalação de uma configuração do Flux em um Kubernetes ou cluster do AKS habilitado para Azure Arc.

Você cria recursos de configuração do Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) para habilitar o gerenciamento do GitOps do cluster nos repositórios Git, nas fontes de Bucket ou no Armazenamento de Blobs do Azure. Quando você cria um recurso fluxConfigurations, os valores que você fornece para os parâmetros, como o repositório Git de destino, são usados para criar e configurar os objetos de Kubernetes que habilitam o processo do GitOps nesse cluster. Para garantir a segurança dos dados, os dados do recurso fluxConfigurations são armazenados criptografados em repouso em um banco de dados do Azure Cosmos DB pelo Serviço de Configuração de Cluster.

Os agentes fluxconfig-agent e fluxconfig-controller, instalados com a extensão microsoft.flux, gerenciam o processo de configuração do GitOps.

fluxconfig-agent é responsável pelas seguintes tarefas:

  • Pesquisar o serviço de plano de dados da Configuração de Kubernetes para recursos fluxConfigurations novos ou atualizados.
  • Criar ou atualizar os recursos personalizados FluxConfig no cluster com as informações de configuração.
  • Inspecionar os recursos personalizados FluxConfig e enviar por push as alterações de status novamente para os recursos de fluxConfiguration associados do Azure.

fluxconfig-controller é responsável pelas seguintes tarefas:

  • Inspecionar as atualizações de status dos recursos personalizados do Flux criados pelo fluxConfigurations gerenciado.
  • Criar um par de chaves pública/privada que existe durante o tempo de vida da fluxConfigurations. Essa chave será usada para autenticação se a URL for baseada em SSH e se o usuário não fornecer uma chave privada própria durante a criação da configuração.
  • Criar o segredo de autenticação personalizado com base nos dados de private-key/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, associação de função criada/atribuída, função criada/atribuída).
  • Criar o GitRepository ou o recurso personalizado Bucket e os recursos personalizados Kustomization com base nas informações contidas no recurso personalizado FluxConfig.

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

Observação

O fluxconfig-agent monitora recursos fluxConfiguration novos ou atualizados no Azure. O agente exige conectividade com o Azure para que o estado desejado da fluxConfiguration seja aplicado ao cluster. Se o agente não puder se conectar ao Azure, as alterações no cluster aguardarão até que o agente possa se conectar. Se o cluster estiver desconectado do Azure por mais de 48 horas, a solicitação para o cluster atingirá um tempo limite e as alterações precisarão ser reaplicadas no Azure.

Entradas confidenciais do cliente, como chave privada e token/senha, não são armazenadas por mais de 48 horas no serviço de Configuração de Kubernetes. Se você atualizar um desses valores no Azure, verifique se os clusters conectem o Azure dentro de 48 horas.

Você pode monitorar o status de configuração do Flux e a conformidade 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 à versão

Há suporte para a versão mais recente da extensão Flux v2 (microsoft.flux) e as duas versões anteriores (N-2). Geralmente, recomendamos que você use a versão mais recente da extensão. A partir da versão 1.7.0 microsoft.flux, há suporte para clusters baseados em ARM64.

Observação

Se você estiver usando o Flux v1, recomendamos migrar para o Flux v2 o mais rápido possível.

O suporte para os recursos de configuração de cluster baseados em Flux v1 criados antes de 1º de janeiro de 2024 terminará em 24 de maio de 2025. A partir de 1º de janeiro de 2024, você não poderá criar novos recursos de configuração de cluster baseados no Flux v1.

Se você adicionou suporte para link privado a um cluster Kubernetes habilitado para Azure Arc, a extensão microsoft.flux funcionará imediatamente com a comunicação de volta para o Azure. Para conexões com o repositório Git, o repositório Helm ou quaisquer outros pontos de extremidade necessários para implantar seus manifestos do Kubernetes, você deve provisionar esses pontos de extremidade por trás do firewall ou listá-los em seu firewall, para que o controlador do Flux Source possa alcançá-los com êxito.

Residência de dados

O serviço Azure GitOps (Gerenciamento de Configuração do Kubernetes do Azure) armazena/processa os dados do cliente. Por padrão, os dados do cliente são replicados para região pareada. Para as regiões de Singapura, Leste da Ásia 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 as configurações, você poderá automatizar a criação da mesma configuração em todos os recursos do Serviço de Kubernetes do Azure e Kubernetes habilitados para Azure Arc usando o Azure Policy, no escopo de uma assinatura ou grupo de recursos. Essa imposição em escala garante que configurações específicas sejam aplicadas consistentemente em grupos inteiros de clusters.

Para obter mais informações, consulte Implantar aplicativos consistentemente em escala usando configurações do Flux v2 e Azure Policy.

Parâmetros

Para ver todos os parâmetros compatíveis com o Flux v2 no Azure, confira a documentação az k8s-configuration. Atualmente, a implementação do Azure não dá suporte a todos os parâmetros compatíveis com o Flux.

Para obter informações sobre parâmetros disponíveis e como usá-los, consulte parâmetros com suporte do GitOps (Flux v2).

Multilocação

O Flux v2 dá suporte a vários locatários começando na versão 0.26. Essa funcionalidade é integrada ao Flux v2 no Azure.

Observação

Para o recurso de multilocação você precisa saber se os seus manifestos contêm algum sourceRef entre namespaces para HelmRelease, Kustomization, ImagePolicy ou outros objetos ou se usar uma versão do Kubernetes inferior à 1.20.6. Para preparar:

  • Atualize para o Kubernetes versão 1.20.6 ou superior.
  • Nos manifestos do Kubernetes, verifique se todos os sourceRef destinam-se a objetos no mesmo namespace da configuração do GitOps.
    • Se precisar de tempo para atualizar os manifestos, recuse a multilocação. No entanto, você ainda precisará atualizar sua versão do Kubernetes.

Atualizar manifestos para multilocação

Digamos que você implante um fluxConfiguration em um dos clusters do Kubernetes no namespace cluster-config com escopo de cluster. Você configura a origem para sincronizar o repositório https://github.com/fluxcd/flux2-kustomize-helm-example. Este é o mesmo repositório Git de exemplo usado o Implantar aplicativos usando o GitOps com o tutorial do Flux v2.

Depois que o Flux sincroniza o repositório, ele implanta os recursos descritos nos manifestos (arquivos YAML). Dois dos manifestos descrevem os objetos HelmRelease e 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

Por padrão, a extensão do Flux implanta o fluxConfigurations representando a conta de serviço flux-applier implantada apenas no namespace cluster-config. Usando os manifestos acima, quando a multilocação estiver habilitada, o HelmRelease será 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 helm-controller do Flux não pode aplicar o HelmRelease, pois não há nenhuma conta de serviço flux-applier no namespace nginx.

Para trabalhar com multilocação, a abordagem correta é implantar todos os objetos do Flux no mesmo namespace que 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. Portanto, para uma configuração do GitOps criada no namespace cluster-config, esses manifestos de exemplo seriam alterados da seguinte maneira:

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

Recusar a multilocação

Quando a extensão microsoft.flux é instalada, a multilocação é habilitada por padrão. Se você precisar desabilitar a multilocação, poderá recusar criando ou atualizando a extensão microsoft.flux 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>

Migração do Flux v1

Se você ainda estiver usando o Flux v1, recomendamos migrar para o Flux v2 assim que possível.

Para migrar para o uso do Flux v2 nos mesmos clusters em que você tem usado o Flux v1, primeiro exclua todos os Flux v1 sourceControlConfigurations dos clusters. Como o Flux v2 tem uma arquitetura fundamentalmente diferente, a extensão de cluster microsoft.flux não será instalada se houver recursos do Flux v1 sourceControlConfigurations em um cluster. O processo de remoção das configurações do Flux v1 e da implantação das configurações do Flux v2 não deve levar mais de 30 minutos.

Remover o Flux v1 sourceControlConfigurations não interrompe nenhum aplicativo em execução nos clusters. No entanto, durante o período em que a configuração do Flux v1 é removida e a extensão Flux v2 ainda não está totalmente implantada:

  • Se houver novas alterações nos manifestos do aplicativo armazenados em um repositório Git, essas alterações não serão retiradas durante a migração e a versão do aplicativo implantada no cluster ficará obsoleta.
  • Se houver alterações não intencionais no estado do cluster e ele se desviar do estado desejado especificado no repositório Git de origem, o cluster não poderá se recuperar automaticamente.

Recomendamos testar seu cenário de migração em um ambiente de desenvolvimento antes de migrar seu ambiente de produção.

Exibir e excluir configurações do Flux v1

Use estes comandos da CLI do Azure para encontrar e excluir um sourceControlConfigurations existente em um cluster:

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>

Você também pode encontrar e excluir as configurações existentes do GitOps de um cluster no portal do Azure. Para fazer isso, navegue até o cluster onde a configuração foi criada e selecione GitOps no painel esquerdo. Selecione a configuração e, em seguida, selecione Excluir.

Implantar configurações do Flux v2

Use o portal do Azure ou a CLI do Azure para aplicar as configurações do Flux v2 aos clusters.

Informações sobre a aposentadoria do Flux v1

O projeto de software livre do Flux v1 foi arquivado e desenvolvimento de recursos foi interrompido indefinidamente.

O Flux v2 foi lançado como o projeto de software livre atualizado do Flux. Ele tem uma nova arquitetura e dá suporte a mais casos de uso do GitOps. A Microsoft lançou uma versão de uma extensão usando o Flux v2 em maio de 2022. Desde então, os clientes foram aconselhados a se mudar para o Flux v2 dentro de três anos, já que o suporte para usar o Flux v1 está programado para terminar em maio de 2025.

Principais novos recursos introduzidos na extensão GitOps para Flux v2:

  • Flux v1 é um operador monolítico do-it-all. O Flux v2 separa as funcionalidades em controladores especializados (controlador de origem, controlador Kustomize, controlador Helm e controlador de notificação).
  • Dá suporte à sincronização com vários repositórios de origem.
  • Dá suporte a vários locatários, como aplicar cada repositório de origem com seu próprio conjunto de permissões.
  • Fornece insights operacionais por meio de verificações de integridade, eventos e alertas.
  • Dá suporte a branches do Git, fixação em confirmações e marcas e seguindo intervalos de marcas SemVer.
  • Configuração de credenciais por recurso gitRepository: chave privada SSH, nome de usuário HTTP/S/senha/token e chaves públicas OpenPGP.

Próximas etapas