Partilhar via

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

  • Artigo

Como uma construção nativa da nuvem, o Kubernetes requer uma abordagem nativa da nuvem para implantação e operações. Com o GitOps, você declara o estado desejado de suas implantações baseadas em aplicativos em arquivos armazenados em repositórios Git. Os aplicativos têm objetos Kubernetes que precisam executar, que podem incluir Implantações, Horizontal-Pod-Autoscalers, Serviços e ConfigMaps. Os operadores do Kubernetes são executados nos clusters e reconciliam continuamente o estado de cada cluster com o estado desejado declarado em seu repositório Git. Esses operadores extraem arquivos de seus repositórios Git e aplicam o estado desejado aos seus clusters. Os operadores também garantem continuamente que seu cluster permaneça no estado desejado.

A implementação do GitOps permite:

  • Melhore a visibilidade geral do estado e da configuração do cluster Kubernetes.
  • Tenha uma auditoria simples e um histórico de versões das alterações no seu cluster através do histórico de alterações do Git que mostre quem fez alterações, quando essas alterações foram feitas e por quê.
  • Corrija automaticamente o desvio que pode ocorrer no cluster.
  • Reverta sua configuração do Kubernetes para uma versão anterior por meio dos comandos Git revert ou Git rollback. A recriação da implantação de cluster para cenários de recuperação de desastres também se torna um processo rápido e direto porque a configuração de cluster desejada 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 no cluster.
  • Implemente um pipeline de CI/CD para implantar aplicativos em seu 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 em seu cluster. O Flux fornece suporte para fontes de arquivos comuns (repositórios Git, repositórios Helm, Buckets) e tipos de modelo (YAML, Helm e Kustomize). O Flux também suporta multilocação e gerenciamento de dependência de implantação, entre outros recursos.

Arquitetura

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

Processo de provisionamento do Flux v2 Cluster Extension:

Diagram that shows Flux extension installation.

Processo de configuração do GitOps:

Diagram that shows how to configure GitOps.

GitOps Flow mostrando uma atualização do aplicativo:

Diagram that shows a typical GitOps workflow.

Considerações de design

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

Configuração

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

Camadas de configuração

  • Configuração de aplicativo necessária para implantar um aplicativo e seus objetos Kubernetes relacionados no cluster, como recursos de Implantação, Serviço, HPA e ConfigMap. As configurações da aplicação são normalmente aplicadas a uma configuração GitOps a nível do espaço de nomes, o que exige que os componentes da aplicação sejam configurados dentro de um único espaço de nome.
  • Configuração comum a todo o cluster para a criação de objetos do Kubernetes, por exemplo, Espaço de Nomes, ServiceAccounts, Funções e RoleBindings e outras políticas comuns a todo o cluster.
  • Os componentes comuns a todo o cluster, por exemplo, Controlador de Entradas, pilha de monitorização e de segurança e vários agentes que operam ao longo de todo o cluster.

Responsabilidades

  • Os desenvolvedores de aplicativos são responsáveis por enviar seu código-fonte, acionar compilações e criar imagens de contêiner.
  • Os operadores de aplicativos são responsáveis pela manutenção dos repositórios de aplicativos, configurações, variáveis de ambiente, gráficos de leme específicos do aplicativo, Kustomizations, etc.
  • Os Operadores do cluster são responsáveis pela configuração da linha de base do cluster. Normalmente, preocupam-se com a configuração de políticas e componentes comuns a todo o cluster. Estes mantêm um diretório de repositório Git ou diretórios que contêm ferramentas de infraestrutura comuns, por exemplo, Espaço de Nomes, Contas de Serviço, RoleBindings, CRDs, políticas comuns a todo o cluster, componentes de entrada, etc.

Estrutura do repositório

Considere os compromissos ao escolher uma estrutura de repositório Git. A estrutura que escolher definirá o estado do cluster do Kubernetes, o que inclui aplicações e componentes comuns a todo o cluster. Dependendo das responsabilidades e personas com as quais se identifica, é importante considerar qualquer colaboração necessária ou a independência de equipa desejada, necessária para diferentes opções de estrutura do repositório.

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

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

  • Repositório único (Ramificação por ambiente):
    • Permite a maior flexibilidade para controlar permissões e políticas Git para cada ramificação que representa um ambiente.
    • A desvantagem é que não há compartilhamento da configuração comum entre ambientes, já que ferramentas como o Kustomize não funcionam com ramificações do Git.
  • 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 seu ambiente que substitui as configurações na base.
    • Essa abordagem pode reduzir arquivos YAML duplicados para cada ambiente, mas também reduz a separação de configuração entre ambientes. Realizar uma única alteração ao repositório pode potencialmente afetar todos os ambientes ao mesmo tempo, pelo que a compreensão dos efeitos das alterações aos diretórios de base deve ser completamente compreendida e realizado com cuidado.
  • Vários repositórios (cada um serve um propósito específico):
    • Pode ser utilizado para separar repositórios de configuração para cada aplicação, equipa, camada ou inquilino.
    • Isso permite que as equipes tenham um controle mais independente, mas se afasta 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 as necessidades de multi-inquilinos. Existe um controlo de acesso baseado em funções (RBAC) e segurança integrada para limitar que configuração uma equipa/inquilino atribuído a um repositório específico pode aplicar, por exemplo, apenas permitir a implementação em certos espaços de nomes.

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

Configuração de aplicações e plataformas

Os Operadores de Plataforma e os Operadores de Aplicativos têm várias opções para gerenciar a configuração do Kubernetes:

  • Os arquivos YAML brutos do Kubernetes que representam as especificações do YAML para cada objeto da API do Kubernetes que você está implantando podem funcionar bem para ambientes únicos. A desvantagem de usar arquivos YAML brutos é que a personalização se torna difícil quando você começa a incorporar vários ambientes, uma vez que você precisa duplicar arquivos YAML e não há um bom método de reutilização.
  • Helm é uma ferramenta de gerenciamento de pacotes para objetos Kubernetes. É uma opção válida que os Operadores de Cluster podem usar para instalar aplicativos prontos para uso de terceiros. Certifique-se de não usar modelos muito pesadamente como uma ferramenta de gerenciamento de configuração para aplicativos internos, porque ele pode se tornar complexo de gerenciar à medida que seus modelos crescem.
    • Se estiver usando o Helm, o Flux inclui um Controlador Helm que permite gerenciar declarativamente as versões do Helm Chart com manifestos do Kubernetes. Você pode criar um objeto HelmRelease para gerenciar esse processo.
  • Kustomize é uma ferramenta de gerenciamento de configuração nativa do Kubernetes que introduz uma maneira livre de modelos para personalizar a configuração do aplicativo.
    • Se estiver usando o Kustomize, o Flux inclui um controlador Kustomize especializado na execução de 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 Kustomization para gerenciar esse processo.
  • Com o Kubernetes habilitado para Azure Arc, em vez de precisar gerenciar o ciclo de vida e o suporte dos componentes por conta própria, você pode usar uma lista de extensões disponíveis que a Microsoft gerencia e suporta. Essas extensões são gerenciadas por meio do Gerenciador de Recursos do Azure. Algumas dessas extensões, como o Azure Key Vault Secrets Provider, 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 despesas gerais para suporte e gerenciamento do ciclo de vida.

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

As seções a seguir fornecem considerações para o pipeline de aplicativos e o processo de atualização de componentes.

Pipeline de aplicativos

  • Considere a compilação, o teste e as validações do aplicativo que você precisa incluir em seu processo de CI. Isso pode incluir linting e testes relacionados à segurança, integração e desempenho, que você precisa para criar um candidato de versão (RC) 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 em seu pipeline de CI e sua 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 solicitações pull (PRs) ou confirmar uma nova alteração de imagem de contêiner diretamente em um repositório de configuração. Essas alterações também podem provisionar todos os objetos YAML necessários para seu aplicativo.

O diagrama de processo a seguir ilustra o processo de CI de aplicativo tradicional incorporado com alterações que suportam 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, isso provavelmente não se originará do pipeline de CD usado para implantar seus aplicativos e serviços. Considere a definição de um processo de promoção específico para Operadores de Cluster para garantir que as alterações possam transitar suavemente de um ambiente para outro.
  • Se você precisar aplicar uma configuração idêntica do GitOps em escala aos seus clusters Kubernetes habilitados para Azure Arc, considere aplicar uma Política do Azure que possa instalar automaticamente a extensão do Flux e aplicar sua configuração do GitOps a clusters Kubernetes existentes habilitados para Azure Arc ou a novos clusters à medida que eles são integrados ao Azure Arc.

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

Considerações de segurança

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

Autenticação do repositório

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

Repo e segurança de filiais

  • Defina permissões e políticas de filial em seu repositório de configuração. À medida que seu repositório Git se torna a peça central de suas 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 implemente políticas para impor a qualidade do código e o gerenciamento de alterações da sua equipe. Caso contrário, seu fluxo de trabalho do GitOps pode enviar código que não está de acordo com os padrões de sua organização.
  • Os pipelines de solicitação pull (PR) podem trabalhar com suas 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 de repositório, acesso de criação de RP e acesso de aprovação de RP.

Gestão de segredos

  • Evite armazenar texto simples ou segredos codificados em base64 em seu repositório Git. Em vez disso, considere usar um provedor de segredos externo, como o Azure Key Vault. O Azure Key Vault Provider for Secrets Store CSI Driver permite integrar um cofre de chaves do Azure como um repositório de segredos com um cluster do Serviço Kubernetes do Azure (AKS) usando um volume CSI. Esse serviço está disponível por meio da extensão Kubernetes habilitada para Azure Arc. HashiCorp Vault é uma alternativa de provedor secreto gerenciado por terceiros.
  • Outra maneira alternativa de gerenciar segredos é usar os Segredos Selados da Bitnami, que operavam 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 de design

Analise 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 arquitetura de referência que ilustra as responsabilidades, repositórios e pipelines necessários para implementar um processo GitOps usando a Extensão de Fluxo do Kubernetes habilitada 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ódigo de aplicativo
    • Este repositório armazena o código do aplicativo e qualquer definição de pipeline e scripts de configuração.
    • Use uma estratégia de ramificação de desenvolvimento que seja fácil de entender e limite o número de ramificações indesejadas de longa duração.
  • Repositório de configuração de aplicativos
    • Esse repositório armazena configurações de aplicativos, incluindo objetos Kubernetes, como ConfigMaps, Deployments, Services e objetos HPA. Estruture este repositório com diretórios diferentes para cada aplicativo. O Flux sincronizará as alterações desse repositório e ramificação de destino com seu cluster.
    • Incorpore ferramentas que tornam mais fácil para os desenvolvedores e operadores de aplicativos criar configurações iniciais por ambiente. Os operadores de aplicativos devem definir uma configuração de aplicativo específica do Kubernetes que use gerenciadores de pacotes como Helm ou ferramentas de configuração como Kustomize para tornar a configuração mais simples.
    • Crie uma ramificação para representar cada tipo de ambiente. Isso permite o controle de grão fino de mudanças em cada ambiente específico, como ambientes não-prod e de produção.
    • Quando um aplicativo é implantado em um namespace específico, use o recurso de escopo de namespace dentro da configuração do GitOps para impor a configuração para apenas um determinado namespace.
  • Repositório de configuração em todo o cluster
    • Defina componentes em todo o cluster, como Ingress Controller, Namespaces, RBAC, monitoramento e pilha de segurança para gerenciamento do Operador de Cluster. O Flux sincroniza as alterações desse repositório e ramificação de destino com seu cluster.
    • Estruture este repositório com diferentes diretórios representando diferentes componentes.
    • Crie uma ramificação para representar cada tipo de ambiente. Isso permite o controle de grão fino de mudanças em cada ambiente específico, como ambientes não-prod e de produção.
    • Os operadores de cluster devem usar gerenciadores de pacotes como Helm ou ferramentas de configuração como sobreposições Kustomize para tornar a configuração mais simples.

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

Atualizações de CI/CD e imagens de contêiner

  • Gasoduto CI
    • As equipes de desenvolvimento devem definir um pipeline de CI por meio de um processo que inclua a criação, o alinhamento, o teste e o envio de um aplicativo para o registro do contêiner.
  • CD Pipeline
    • 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 originada do seu ambiente de destino, faz uma alteração na versão da marca de imagem, confirma a alteração e abre uma solicitação pull na ramificação do ambiente de destino. Esse pipeline de CD pode ter estágios de ambiente com variáveis de ambiente apropriadas para direcionar o repositório e a ramificação corretos da Configuração do GitOps.
    • Defina etapas de aprovação manual para estágios de ambiente para limitar solicitações pull indesejadas a todos os ambientes.
  • Habilite políticas de ramificação em seu repositório de configuração de aplicativos para impor revisões ou aprovações por pares para ambientes. Isso pode envolver um número mínimo de revisões necessárias ou uma aprovação automática para ambientes inferiores. Considere também 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 aplicativos e em todo o cluster

  • Os Operadores de Cluster e os Operadores de Aplicativos definem a configuração em seus respetivos repositórios de configuração. Esses usuários não precisam de ferramentas de pipeline para enviar configurações por push. Em vez disso, eles usam processos nativos de confirmação e RP do Git para definir uma configuração e enviar alterações por push para uma ramificação que representa um ambiente.
  • Para novas definições de configuração, comece definindo a configuração em ambientes inferiores, como Dev, e promova para ambientes mais altos por meio de mesclagens e solicitações pull. Escolha seletivamente atualizações de configuração específicas para determinados ambientes, conforme necessário.

Feedback e alertas

  • Configure as Notificações de Fluxo para alertar quando as configurações do GitOps não conseguirem sincronizar ou estiverem lançando erros. Os operadores de aplicativos devem configurar alertas para determinar quando uma implantação de aplicativo foi bem-sucedida 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 há problemas de sincronização com seu repositório Git.
  • Implemente o GitOps Connector para integrar o feedback do agente Flux às suas ferramentas de CI/CD.

Recomendações de segurança

  • Analise as recomendações de governança e segurança para seus clusters Kubernetes habilitados 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 seu repositório Git através do protocolo SSH e uma chave SSH se seu provedor Git o suportar. Se o SSH estiver inutilizável devido a restrições de conectividade de saída ou se o seu provedor Git não suportar 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, poderá Criar um token de acesso pessoal para autenticação.
  • Configure políticas e permissões de filial que correspondam às responsabilidades do seu cluster. Defina um número mínimo de revisores para aprovar as alterações.
  • Configure um pipeline PR para validar configurações e sintaxe do YAML e, opcionalmente, implante um cluster Kubernetes de teste. Configure uma política de ramificação que exija que esse pipeline seja executado com êxito antes que qualquer mesclagem possa ser aceita.
  • Implemente segredos usando o Azure Key Vault Provider for Secrets Store CSI Driver, que permitirá a integração de um Azure Key Vault como um repositório de segredos com um cluster Kubernetes habilitado para Azure Arc por meio de um volume CSI.
  • A extensão Flux suporta configurações de namespace e escopo de cluster. Escolha o escopo do namespace quando sua configuração não deve ter acesso além de um único namespace.

Próximos passos

Para obter mais informações sobre sua jornada de nuvem híbrida e multicloud, consulte os artigos a seguir.