Compartilhar via

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

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.
  • Capacidade de implantar aplicativos em escala pelo Azure Policy.

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.

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

Se você adicionou suporte ao Link Privado a um cluster habilitado pelo Kubernetes do Azure Arc, então a extensão microsoft.flux funcionará de imediato com a comunicação de volta ao 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>

Próximas etapas