Partilhar via

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

  • Artigo

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

Com o GitOps, declara o estado desejado dos clusters do Kubernetes em ficheiros nos repositórios Git. Os repositórios Git podem conter os seguintes arquivos:

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 o Serviço Kubernetes do Azure usa o 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.

O fluxo é implantado diretamente no cluster e o plano de controle de cada cluster é logicamente separado. Isso faz com que ele seja bem dimensionado para centenas e milhares de clusters. O Flux permite implantações puras de aplicativos GitOps baseados em pull. Nenhum acesso a clusters é necessário pelo repositório de origem ou 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.

Controllers

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, você também pode instalar o Flux image-automation e image-reflector os controladores, que fornecem funcionalidade para atualizar e recuperar 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. Lida com a autorização com a origem para contas privadas de armazenamento Git, Helm repos e blob do Azure. Apresenta as alterações mais recentes na origem através de um arquivo tar archive.

  • Controlador Flux Kustomize: Observa 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 HelmChart recurso personalizado e aplica os valores com determinada versão, nome e definidos pelo HelmRelease 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 notificações por push para pontos de extremidade de webhook definidos pelo usuário.

  • 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 as alterações de status do Flux no cluster de volta para o Azure para cada fluxConfigurations recurso.

  • fluxconfig-controller: Observa os fluxconfigs.clusterconfig.azure.com recursos personalizados e responde a alterações com a configuração nova ou atualizada do maquinário GitOps no cluster.

Nota

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

Configurações de fluxo

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

Você cria recursos de configuração do Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) para habilitar o gerenciamento do GitOps do cluster a partir de 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 fluxConfigurations recurso são armazenados criptografados em repouso em um banco de dados do Azure Cosmos DB pelo serviço de Configuração de Cluster.

Os fluxconfig-agent agentes e fluxconfig-controller , instalados com a microsoft.flux extensão, gerenciam 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:

  • Observa atualizações de status para os recursos personalizados do Flux criados pelo gerenciado 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 personaliza recurso 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.

Nota

Os fluxconfig-agent monitores para recursos novos ou atualizados fluxConfiguration no Azure. O agente requer conectividade com o fluxConfiguration Azure para que o estado desejado do 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 for desconectado do Azure por mais de 48 horas, a solicitação para o cluster expirará e as alterações precisarão ser reaplicadas no Azure.

Entradas confidenciais do cliente, como chave privada e token/senha, são armazenadas por menos de 48 horas no serviço de Configuração do Kubernetes. Se você atualizar qualquer um desses valores no Azure, certifique-se de que seus clusters se conectem ao Azure dentro de 48 horas.

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 da versão

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.

Nota

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

O suporte para recursos de configuração de cluster baseados no 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 Arco do Azure, a microsoft.flux extensão funciona pronta para uso com comunicação de volta ao Azure. Para conexões com seu repositório Git, repositório Helm ou quaisquer outros endpoints necessários para implantar seus manifestos do Kubernetes, você deve provisionar esses pontos de extremidade atrás do firewall ou listá-los no firewall, para que o controlador Flux Source possa alcançá-los com êxito.

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

Arquitetura multi-inquilino

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

Nota

Para o recurso de multilocação, você precisa saber se seus manifestos contêm algum sourceRef de namespace cruzado para HelmRelease, Kustomization, ImagePolicy ou outros objetos, ou se você usa uma versão do Kubernetes menor que 1.20.6. Para se preparar:

  • Atualize para o Kubernetes versão 1.20.6 ou superior.
  • Em seus manifestos do Kubernetes, assegure-se de que todos sourceRef estejam para objetos dentro do mesmo namespace que a configuração do GitOps.

Atualizar manifestos para multilocação

Digamos que você implante um fluxConfiguration em um de nossos clusters Kubernetes no cluster-config namespace 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/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 Flux implanta o fluxConfigurations representando a conta de serviço que é implantada flux-applier cluster-config somente no namespace. Usando os manifestos acima, quando a multilocação está habilitada, o HelmRelease seria bloqueado. Isso ocorre porque o HelmRelease está no namespace, mas faz referência a nginx flux-system um HelmRepository no namespace. 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 multilocação, 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/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

Optar por não participar no multiarrendamento

Quando a extensão é instalada, a microsoft.flux 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>

Migrar do Flux v1

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

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

A remoção do 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 do 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 extraídas 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 auto-recuperar.

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

Ver e eliminar configurações do Flux v1

Use estes comandos da CLI do Azure para localizar e excluir os existentes sourceControlConfigurations 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 localizar e excluir configurações existentes do GitOps para 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 seus clusters.

Informações sobre aposentadoria do Flux v1

O projeto de código aberto do Flux v1 foi arquivado e o desenvolvimento de recursos parou indefinidamente.

O Flux v2 foi lançado como o projeto de código aberto atualizado do Flux. Ele tem uma nova arquitetura e suporta mais casos de uso de 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 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 o Flux v2:

  • O Flux v1 é um operador monolítico "faça tudo". O Flux v2 separa as funcionalidades em controladores especializados (controlador Source, controlador Kustomize, controlador Helm e controlador de notificação).
  • Dá suporte à sincronização com vários repositórios de origem.
  • Suporta multilocação, como a aplicação de cada repositório de origem com seu próprio conjunto de permissões.
  • Fornece informações operacionais através de verificações de integridade, eventos e alertas.
  • Suporta ramificações Git, fixando confirmações e tags e seguindo intervalos de tags SemVer.
  • Configuração de credenciais por recurso GitRepository: chave privada SSH, nome de usuário/senha/token HTTP/S e chaves públicas OpenPGP.

Próximos passos