Disciplinas de CI/CD e GitOps com o Kubernetes habilitado para Azure Arc

  • Artigo

Como um constructo nativo de nuvem, o Kubernetes exige uma abordagem nativa de nuvem para implantação e operações. Com o GitOps, você declara o estado desejado das suas implantações baseadas em aplicativo em arquivos armazenados em repositórios Git. Os aplicativos têm objetos do Kubernetes que precisam ser executados, o que pode incluir Implantações, Horizontal-Pod-Autoscalers, Serviços e ConfigMaps. Os controladores do Kubernetes são executados nos clusters e reconciliam continuamente o estado de cada cluster com o estado desejado declarado no repositório Git. Esses operadores recebem os 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.

A implementação do GitOps permite que você:

  • Melhore a visibilidade geral do estado e da configuração do cluster do Kubernetes.
  • Tenha uma auditoria simples e um histórico de alterações de versões para o cluster por meio do histórico de alterações do Git, que mostra quem fez as alterações, quando essas alterações foram feitas e por quê.
  • Corrija automaticamente o descompasso que pode ocorrer no cluster.
  • Reverta a configuração do Kubernetes para uma versão anterior por meio de comandos de reversão do Git. A recriação da implantação do cluster para cenários de recuperação de desastre também se torna um processo rápido e direto, pois a configuração do cluster desejado do Kubernetes é armazenada no Git.
  • Melhore a segurança, reduzindo o número de contas de serviço necessárias para ter permissões de implantação para o cluster.
  • Implemente um pipeline de CI/CD para implantar aplicativos no cluster.

O GitOps no Kubernetes habilitado para Azure Arc usa uma extensão que implementa o Flux, um popular conjunto de ferramentas de código aberto. O Flux é um operador que automatiza as implantações de configuração do GitOps no cluster. O Flux dá suporte a fontes de arquivo comuns (repositórios Git, repositórios Helm, Buckets) 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.

Arquitetura

Os diagramas a seguir ilustram uma arquitetura de referência conceitual, que destaca o provisionamento da instalação de extensão do cluster do Flux em um cluster, o processo de configuração do GitOps para um cluster do Kubernetes habilitado para Azure Arc e o Fluxo do GitOps.

Processo de Provisionamento da Extensão do Cluster do Flux v2:

Diagram that shows Flux extension installation.

Processo de Configuração do GitOps:

Diagram that shows how to configure GitOps.

Fluxo do GitOps mostrando uma atualização do aplicativo:

Diagram that shows a typical GitOps workflow.

Considerações sobre o design

Examine as considerações de design a seguir, ao planejar a implementação do GitOps para o Kubernetes habilitado para Azure Arc.

Configuração

Considere as diferentes camadas de configuração no cluster do Kubernetes e as responsabilidades envolvidas no provisionamento.

Camadas de configuração

  • A configuração do aplicativo necessária para implantar um aplicativo e seus objetos do Kubernetes relacionados no cluster, como os recursos Implantação, Serviço, HPA e ConfigMap. Normalmente, as configurações do aplicativo são aplicadas a uma configuração de GitOps no nível do namespace, exigindo que os componentes do aplicativo sejam configurados apenas em um único namespace.
  • Configuração em todo o cluster para criação de objetos do Kubernetes, como Namespaces, ServiceAccounts, Funções e RoleBindings e outras políticas em todo o cluster.
  • Componentes em todo o cluster, como um Controlador de Entrada, pilha de monitoramento e segurança e vários agentes que operam em todo o cluster.

Responsabilidades

  • Os desenvolvedores de aplicativos são responsáveis por efetuar push no código-fonte, disparar builds e criar imagens de contêiner.
  • Os operadores de aplicativo são responsáveis por manter os repositórios de aplicativos, as configurações, as variáveis de ambiente, os gráficos de helm específicos do aplicativo, os Kustomizations etc.
  • Os Operadores de Cluster são responsáveis por configurar a linha de base do cluster. Normalmente, eles estão preocupados com a configuração de componentes e políticas em todo o cluster. Eles mantêm um diretório de repositório Git ou diretórios que contêm ferramentas de infraestrutura comuns, como Namespaces, Contas de Serviço, RoleBindings, CRDs, políticas em todo o cluster, componentes de Entrada etc.

Estrutura do Repositório

Considere as compensações ao escolher uma estrutura de repositório Git. A estrutura escolhida definirá o estado do cluster do Kubernetes, que inclui aplicativos e componentes em todo o cluster. Dependendo das responsabilidades e personas identificadas, é importante considerar qualquer colaboração necessária ou independência de equipe desejada necessária para diferentes opções de estrutura de repositório.

Você pode usar qualquer estratégia de ramificação que desejar para os repositórios de código, pois ela só é usada pelo processo de CI (Integração Contínua).

Para os repositórios de configuração do GitOps, considere as seguintes estratégias com base nas necessidades de negócios, tamanho e ferramentas da organização:

  • Repositório único (Branch por ambiente):
    • Permite a maior flexibilidade para controlar as políticas e permissões do Git para cada branch que representa um ambiente.
    • A desvantagem é que não há compartilhamento da configuração comum entre ambientes, pois as ferramentas, como o Kustomize, não funcionam com Git branches.
  • Repositório único (Diretório por ambiente):
    • Você pode implementar essa abordagem usando ferramentas como o Kustomize, que permite definir uma configuração base para objetos do Kubernetes e um conjunto de artefatos (ou seja, patches) para o ambiente que substitui as configurações na base.
    • Essa abordagem pode reduzir os arquivos YAML duplicados para cada ambiente, mas também reduz a separação de configuração entre ambientes. Fazer uma única alteração no repositório tem o potencial de afetar todos os ambientes de uma só vez, portanto, o efeito das alterações nos diretórios base deve ser totalmente compreendido e tratado com cuidado.
  • Vários repositórios (cada um atende a uma finalidade específica):
    • Essa estratégia pode ser usada para separar repositórios de configuração para cada aplicativo, equipe, camada ou locatário.
    • Isso permite que as equipes tenham um controle mais independente, mas se distancia do princípio de definir o estado do sistema em um único repositório para melhorar a configuração central, a visibilidade e o controle das implantações em um cluster.
    • A configuração de vários repositórios deve ser considerada para necessidades de vários locatários. Há RBAC (controle de acesso baseado em função) e segurança interna para limitar a configuração que uma equipe/locatário atribuído a um repositório específico pode aplicar, como permitir apenas a implantação em determinados namespaces.

Veja mais maneiras de estruturar o repositório no Guia do Flux.

Configuração de aplicativo e plataforma

Os operadores de plataforma e os operadores de aplicativo têm várias opções para gerenciar a configuração do Kubernetes:

  • Os arquivos YAML brutos do Kubernetes, que representam as especificações YAML para cada objeto de API do Kubernetes que você está implantando, podem funcionar corretamente para ambientes individuais. A desvantagem de usar arquivos YAML brutos é que a personalização se torna difícil quando você começa a incorporar vários ambientes, pois é necessário duplicar os arquivos YAML e não há um método de reutilização adequado.
  • O Helm é uma ferramenta de gerenciamento de pacotes para objetos do Kubernetes. É uma opção válida que os Operadores de Cluster podem usar para instalar aplicativos de terceiros disponíveis no mercado. Não use a modelagem muito acentuada como uma ferramenta de gerenciamento de configuração para aplicativos internos, pois pode se tornar complexa de gerenciar, à medida que os modelos aumentam.
    • Se estiver usando o Helm, o Flux inclui um Controlador do Helm, que permite gerenciar declarativamente as versões do Gráfico do Helm com manifestos do Kubernetes. Você pode criar um objeto HelmRelease para gerenciar esse processo.
  • O Kustomize é uma ferramenta de gerenciamento de configuração nativa do Kubernetes, que apresenta uma maneira sem modelos de personalizar a configuração do aplicativo.
    • Se estiver usando o Kustomize, o Flux inclui um controlador do Kustomize especializado em executar pipelines de entrega contínua para infraestrutura e cargas de trabalho definidas com manifestos do Kubernetes e montadas com o Kustomize. Você pode criar um objeto do Kustomization para gerenciar esse processo.
  • Com o Kubernetes habilitado para Azure Arc, em vez de precisar gerenciar o ciclo de vida e o suporte de componentes por conta própria, você pode usar uma lista de extensões disponíveis que a Microsoft gerencia e valida. Essas extensões são gerenciadas por meio do Azure Resource Manager. Algumas dessas extensões, como o Provedor de Segredos do Azure Key Vault, têm alternativas de código aberto. O gerenciamento de componentes fora do processo de extensão oferece mais controle sobre os componentes, mas também requer mais sobrecarga para o suporte e o gerenciamento do ciclo de vida.

Fluxo de CI/CD (Integração Contínua e Entrega Contínua)

As seções a seguir fornecem as considerações sobre o pipeline do aplicativo e o processo de atualização de componentes.

Pipeline do aplicativo

  • Considere a compilação, o teste e as validações do aplicativo que você precisa incluir no processo de CI. Isso pode incluir o lint e testes relacionados à segurança, à integração e ao desempenho, que são necessários para criar um RC (release candidate) para implantações de ambiente.
  • Você pode usar um método tradicional de implantação por push, para preencher a lacuna entre uma imagem de contêiner de compilação no pipeline de CI e a implantação em um cluster, chamando a API do Kubernetes diretamente do pipeline de implantação.

Para evitar modificações manuais de configuração no repositório GitOps, você pode executar o pipeline de CD como uma conta de serviço, que tem permissão para abrir PRs (solicitações de pull) ou confirmar uma nova alteração de imagem de contêiner diretamente para um repositório de configuração. Essas alterações também podem provisionar todos os objetos YAML necessários para o aplicativo.

O diagrama de processo a seguir ilustra o processo de CI do aplicativo tradicional incorporado com as alterações compatíveis com o GitOps.

Diagram that shows the standard GitOps process.

Processo de atualização de componentes em todo o cluster

  • Os Operadores de Cluster precisam gerenciar componentes em todo o cluster. Portanto, provavelmente isso não é proveniente do pipeline de CD usado para implantar os aplicativos e serviços. Defina um processo de promoção específico para Operadores de Cluster, para garantir que as alterações possam fazer uma transição sem problemas de um ambiente para outro.
  • Se você precisar aplicar uma configuração idêntica do GitOps em escala aos clusters do Kubernetes habilitados para Azure Arc, aplique um Azure Policy que possa instalar automaticamente a extensão do Flux e aplicar a configuração do GitOps aos clusters do Kubernetes habilitados para Azure Arc existentes ou a novos clusters, à medida que forem integrados ao Azure Arc.

Ao atualizar a configuração, provavelmente convém verificar se as alterações foram aplicadas com êxito ao ambiente desejado. Você pode definir notificações no Flux para integrar as ferramentas de CI/CD, email ou ferramentas de ChatOps e enviar alertas sobre as alterações bem-sucedidas e falhas de implantação automaticamente. Você também pode encontrar as informações do status de implantação no portal do Azure e por meio da CLI de k8s-configuration e da API do ARM.

Considerações de segurança

Examine as considerações de segurança a seguir, ao planejar a implementação do GitOps para o Kubernetes habilitado para Azure Arc.

Autenticação do repositório

  • Você pode usar um repositório Git público ou privado com o GitOps, mas devido à natureza confidencial das configurações do Kubernetes, recomendamos que você use um repositório privado que exija autenticação por chave SSH ou chave de API. O GitOps também funciona com repositórios Git que só podem ser acessados em uma rede privada, contanto que o cluster do Kubernetes possa acessá-lo, mas essa configuração limita a capacidade de usar provedores Git baseados em nuvem, como o Azure Repos ou o GitHub.
  • Os protocolos HTTPS e SSH oferecem uma conexão confiável e segura que você pode usar para se conectar à ferramenta de controle do código-fonte. No entanto, muitas vezes o HTTPS é mais fácil de configurar e usa uma porta que raramente exige que você abra mais portas nos firewalls.

Segurança de repositório e de ramificação

  • Defina permissões e políticas de ramificação no repositório de configuração. À medida que o repositório Git se torna a parte central das implantações do Kubernetes, é fundamental que você configure permissões para controlar quem pode ler e atualizar o código em uma ramificação e que você implemente políticas para impor a qualidade do código e o gerenciamento de alterações da equipe. Caso contrário, o fluxo de trabalho do GitOps pode enviar um código que não esteja de acordo com os padrões das organizações.
  • Os pipelines da PR (solicitação de pull) podem trabalhar com as políticas de ramificação para validar a configuração do YAML e/ou implantar ambientes de teste, conforme necessário. Os portões ajudam a eliminar erros de configuração e aumentam a segurança e a confiança da implantação.
  • Ao atribuir permissões de acesso, considere quais usuários em sua organização devem ter acesso de leitura ao repositório, acesso à criação de PR e acesso à aprovação de PR.

Gerenciamento de segredos

  • Evite armazenar segredos codificados em texto sem formatação ou base64 no repositório Git. Em vez disso, use um provedor de segredos externos, como o Azure Key Vault. O Provedor do Azure Key Vault para Driver CSI do Repositório de Segredos permite integrar um Azure Key Vault como repositório de segredos com a um cluster do AKS (Serviço de Kubernetes do Azure), usando um volume de CSI. Esse serviço está disponível por meio da extensão do Kubernetes habilitada para Azure Arc. O HashiCorp Vault é uma alternativa de provedor de segredos gerenciados de terceiros.
  • Outra maneira alternativa de gerenciar segredos é usar os Segredos Selados do Bitnami, que funcionam a partir do conceito de chaves públicas e privadas. Isso permite que os operadores armazenem um segredo criptografado unidirecional usando uma chave pública no Git, que só pode ser descriptografada por meio da chave privada, que é usada por um controlador SealedSecrets em execução no cluster.

Recomendações sobre design

Examine as recomendações de design a seguir, ao planejar a implementação do GitOps para o Kubernetes habilitado para Azure Arc.

O diagrama a seguir contém a arquitetura de referência que ilustra as responsabilidades, os repositórios e os pipelines necessários para implementar um processo do GitOps usando a Extensão do Flux do Kubernetes habilitado para Azure Arc.

Diagram that shows a GitOps Reference flow.

Repositórios

Três repositórios Git estão incluídos no design:

  • Repositório de códigos do aplicativo
    • Este repositório armazena o código do aplicativo e os scripts de definição e configuração de pipeline.
    • Use uma estratégia de ramificação de desenvolvimento fácil de entender e limite o número de ramificações de execução prolongada indesejadas.
  • Repositório de configuração de aplicativo
    • Este repositório armazena as configurações de aplicativos, incluindo objetos do Kubernetes, como objetos de ConfigMaps, Implantações, Serviços e HPA. Estruture esse repositório com diretórios diferentes para cada aplicativo. O Flux sincronizará as alterações desse repositório e da ramificação de destino com o cluster.
    • Incorpore ferramentas que facilitem a compilação de configurações iniciais por ambiente para desenvolvedores e operadores de aplicativos. Os Operadores de Aplicativo devem definir uma configuração de aplicativo específica do Kubernetes que use gerenciadores de pacotes, como o Helm, ou ferramentas de configuração, como o Kustomize, para simplificar a configuração.
    • Crie uma ramificação para representar cada tipo de ambiente. Isso permite o controle refinado de alterações em cada ambiente específico, como ambientes não produção e de produção.
    • Quando um aplicativo é implantado em um namespace específico, use o recurso de escopo do namespace na configuração do GitOps para impor a configuração para apenas determinado namespace.
  • Repositório de configuração em todo o cluster
    • Defina componentes em todo o cluster, como Controlador de Entrada, Namespaces, RBAC, monitoramento e pilha de segurança para gerenciamento do Operador de Cluster. O Flux sincroniza as alterações desse repositório e da ramificação de destino com o cluster.
    • Estruture esse repositório com diretórios diferentes que representam componentes diferentes.
    • Crie uma ramificação para representar cada tipo de ambiente. Isso permite o controle refinado de alterações em cada ambiente específico, como ambientes não produção e de produção.
    • Os Operadores de Cluster devem usar gerenciadores de pacotes, como o Helm, ou ferramentas de configuração, como as sobreposições do Kustomize, para simplificar a configuração.

CI/CD e o processo de atualização de configuração

CI/CD e as atualizações de imagem de contêiner

  • Pipeline de CI
    • As equipes de desenvolvimento devem definir um pipeline de CI por meio de um processo que inclua compilação, lint, teste e envio por push de um aplicativo para o registro de contêiner.
  • Pipeline de CD
    • Crie um pipeline de CD que execute um script direcionado a alterações no repositório de configuração do aplicativo. Esse script cria uma ramificação temporária proveniente do ambiente de destino, faz uma alteração na versão da marca de imagem, confirma a alteração e abre uma solicitação de pull na ramificação do ambiente de destino. Esse pipeline de CD pode ter fases de ambiente com as variáveis de ambiente apropriadas para direcionar o repositório correto e a ramificação correta da Configuração do GitOps.
    • Defina as etapas de aprovação manual das fases de ambiente, para limitar as solicitações de pull indesejadas para todos os ambientes.
  • Habilite as políticas de ramificação no repositório de configuração do aplicativo, para impor a revisão em pares ou aprovações para ambientes. Isso pode envolver um número mínimo de revisões necessárias ou uma aprovação automática para ambientes mais baixos. Considere também as integrações e aprovações de terceiros, conforme necessário, para atender aos padrões da sua organização.

Atualizações de configuração de aplicativo e em todo o cluster

  • Os operadores de cluster e os operadores de aplicativo definem cada configuração nos respectivos repositórios de configuração. Esses usuários não exigem ferramentas de pipeline para enviar as configurações. Em vez disso, eles usam processos nativos de confirmação de Git e PR, para definir uma configuração e enviar alterações para uma ramificação que representa um ambiente.
  • Para novas definições de configuração, comece definindo a configuração em ambientes inferiores, como Desenvolvimento, e promova ambientes mais altos por meio de mesclagens e solicitações de pull. Execute o cherry-pick das atualizações de configuração específicas para determinados ambientes, conforme necessário.

Comentários e alertas

  • Configure as Notificações do Flux para alertar quando não for possível sincronizar as configurações do GitOps ou quando elas estiverem gerando erros. Os Operadores de Aplicativo devem configurar alertas para determinar quando uma implantação de aplicativo foi realizada com sucesso e está íntegra. Os Operadores de Cluster devem configurar alertas para determinar quando a reconciliação de componentes em todo o cluster falhou e quando houver problemas de sincronização com o repositório Git.
  • Implemente o GitOps Connector para integrar comentários do agente do Flux às ferramentas de CI/CD.

Recomendações de segurança

  • Examine as recomendações de governança e segurança para os clusters do Kubernetes habilitado para Azure Arc.
  • Evite o acesso indesejado a qualquer configuração de cluster, usando um repositório Git privado com autenticação e autorização que você pode usar para definir qualquer repositório de configuração.
  • Acesse o repositório Git por meio do protocolo SSH e de uma chave SSH, se o provedor Git permitir. Se o SSH for inutilizável devido a restrições de conectividade de saída ou se o provedor Git não for compatível com as bibliotecas SSH necessárias, use uma conta de serviço dedicada e associe uma chave de API a essa conta para o Flux usar. Se você precisar de uma alternativa ao SSH ao usar o GitHub, pode criar um token de acesso pessoal para autenticação.
  • Configure políticas e permissões de ramificação que correspondam às responsabilidades do cluster. Defina um número mínimo de revisores para aprovar as alterações.
  • Configure um pipeline de PR para validar as configurações e a sintaxe YAML e, opcionalmente, implantar um cluster de teste do Kubernetes. Configure uma política de ramificação que exija que esse pipeline seja executado com êxito, antes que qualquer mesclagem seja aceita.
  • Implemente segredos usando o Provedor do Azure Key Vault Provider para Driver CSI do Repositório de Segredos, que permitirá a integração de um Azure Key Vault, como um repositório de segredos, com um cluster do Kubernetes habilitado para Azure Arc por meio de um volume de CSI.
  • A extensão do Flux permite configurações com escopo do namespace e do cluster. Escolha o escopo do namespace quando a configuração não deve ter acesso além de um único namespace.

Próximas etapas

Para obter mais informações sobre seu percurso na nuvem híbrida e multinuvem, confira os artigos a seguir.