Compartilhar via

GitOps para Serviço de Kubernetes do Azure

AKS (Serviço de Kubernetes do Azure)
GitHub

O GitOps é um conjunto de princípios para operar e gerenciar um sistema de software. Este artigo descreve técnicas para usar os princípios do GitOps para operar e gerenciar um cluster do AKS (Serviços de Kubernetes do Azure).

Os logotipos Flux, Argo CD, OPA Gatekeeper, Kubernetes e Git são marcas comerciais de suas respectivas empresas. Nenhum endosso está implícito pelo uso dessas marcas.

Arquitetura

Dois operadores GitOps que você pode usar com o AKS são Flux e Argo CD. Ambos são projetos de CNCF (Cloud Native Computing Foundation). Os cenários a seguir mostram maneiras de usá-los.

Cenário 1: GitOps com Flux e AKS

Diagrama do GitOps com Flux v2, GitHub e AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 1

O Flux é uma extensão de cluster que se integra nativamente ao AKS. Uma extensão de cluster fornece uma plataforma para instalar e gerenciar soluções em um cluster do AKS. Você pode usar o portal do Azure, a CLI do Azure ou scripts iac (infraestrutura como código), como scripts Terraform ou Bicep, para habilitar o Flux como uma extensão para o AKS. Você também pode usar o Azure Policy para aplicar as configurações do Flux v2 em escala em clusters do AKS. Para obter mais informações, consulte Implantar aplicativos consistentemente em escala usando configurações do Flux v2 e do Azure Policy.

O Flux pode implantar manifestos do Kubernetes, gráficos do Helm e arquivos Kustomization no AKS. O Flux é um processo baseado em pesquisa, portanto, ele pode detectar, efetuar pull e reconciliar alterações de configuração sem expor pontos de extremidade de cluster aos agentes de build.

Nesse cenário, os administradores do Kubernetes podem alterar objetos de configuração do Kubernetes, como segredos e ConfigMaps, e confirmar as alterações diretamente em um repositório GitHub.

O fluxo de dados a seguir corresponde ao diagrama anterior:

  1. O desenvolvedor confirma alterações de configuração no repositório GitHub.

  2. O Flux detecta o desvio de configuração no repositório Git e obtém as alterações de configuração.

  3. Reconcilia o estado no cluster do Kubernetes.

Alternativas para o cenário 1

  • Você pode usar o Flux com outros repositórios Git, como Azure DevOps, GitLab e Bitbucket.

  • Em vez de repositórios Git, a API do Flux Bucket define uma fonte para gerar um artefato para objetos de soluções de armazenamento como buckets do Amazon S3 e do Google Cloud Storage. Você também pode usar uma solução que tenha uma API compatível com S3. Dois exemplos são MinIO e OsS (Serviço de Armazenamento de Objetos na Nuvem) do Alibaba, mas há outras soluções.

  • Você também pode configurar o Flux em um contêiner do Armazenamento de Blobs do Azure como uma fonte para produzir artefatos. Para obter mais informações, consulte Configurações do GitOps Flux v2 com o AKS e o Kubernetes habilitado para Azure Arc.

  • O Flux v2 dá suporte à multilocação, permitindo que equipes separadas implantem cargas de trabalho em um único cluster compartilhado do Kubernetes. Vários repositórios Git que representam um locatário diferente podem ser sincronizados com o cluster. Para garantir o isolamento da carga de trabalho entre as equipes, cada equipe pode ter seu próprio namespace ou namespaces dentro do cluster do AKS ao qual o acesso é restrito por meio de políticas de RBAC (controle de acesso baseado em função) do Kubernetes.

  • O Flux pode usar um cluster para gerenciar os aplicativos no mesmo cluster ou em outros clusters. Um cluster AKS hub com o operador Flux gerencia a entrega contínua via GitOps de aplicativos e cargas de trabalho de infraestrutura para vários clusters spoke AKS.

Cenário 2: usar o GitOps com Flux, GitHub e AKS para implementar CI/CD

Diagrama que mostra como implementar CI/CD usando o GitOps com Flux, GitHub e AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 2

Esse cenário é um pipeline de DevOps baseado em pull para um aplicativo Web típico. O pipeline usa o GitHub Actions para build. Para implantação, ele usa o Flux como o operador GitOps para efetuar pull e sincronizar o aplicativo.

O fluxo de dados a seguir corresponde ao diagrama anterior:

  1. O código do aplicativo é desenvolvido usando um IDE (ambiente de desenvolvimento integrado), como o Visual Studio Code.

  2. O código do aplicativo é confirmado em um repositório GitHub.

  3. O GitHub Actions cria uma imagem de contêiner do código do aplicativo e envia a imagem de contêiner por push para o Registro de Contêiner do Azure.

  4. O GitHub Actions atualiza um arquivo de manifesto de implantação do Kubernetes com a versão atual da imagem, baseada no número de versão da imagem de contêiner no Container Registry.

  5. O operador Flux detecta o descompasso de configuração no repositório Git e efetua pull das alterações de configuração.

  6. O Flux usa arquivos de manifesto para implantar o aplicativo no cluster do AKS.

Cenário 3: GitOps com CD do Argo, repositório GitHub e AKS

Diagrama do GitOps com o Argo CD, o GitHub e o AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 3

Você pode habilitar o Argo CD como uma extensão de cluster no AKS. Nesse cenário, os administradores do Kubernetes podem alterar objetos de configuração do Kubernetes, como segredos e ConfigMaps, e confirmar as alterações diretamente para o repositório GitHub.

O fluxo de dados a seguir corresponde ao diagrama anterior:

  1. O administrador do Kubernetes faz alterações de configuração em arquivos YAML e confirma as alterações no repositório GitHub.

  2. O Argo CD extrai as alterações do repositório Git.

  3. O Argo CD reconcilia as alterações de configuração com o cluster do AKS.

O Argo CD não precisa sincronizar automaticamente o estado de destino desejado com o cluster do AKS. Ele é implementado como um controlador do Kubernetes que monitora continuamente a execução de aplicativos. Ele compara o estado dinâmico atual do cluster do AKS com o estado de destino desejado especificado no repositório Git. O Argo CD relata e visualiza as diferenças e fornece ferramentas para sincronizar automaticamente ou manualmente o estado dinâmico de volta ao estado de destino desejado.

O Argo CD fornece uma interface do usuário baseada em navegador. Você pode usá-lo para adicionar configurações de aplicativo, observar o estado de sincronização em relação ao cluster e iniciar a sincronização com o cluster. Você também pode usar a linha de comando do Argo CD para realizar essas tarefas. A interface do usuário e a interface de linha de comando fornecem recursos para exibir o histórico de alterações de configuração e reverter para uma versão anterior.

Por padrão, a interface do usuário do Argo CD e o servidor de API não são expostos. Para acessá-los, recomendamos que você criar um controlador de entrada que tenha um endereço IP interno. Ou você pode usar um balanceador de carga interno para expô-los.

Alternativas para o cenário 3

Qualquer repositório compatível com o Git, incluindo o Azure DevOps, pode servir como o repositório de origem de configuração.

Cenário 4: usar o GitOps com o Argo CD, o GitHub Actions e o AKS para implementar CI/CD

Diagrama que mostra como implementar CI/CD usando o GitOps com o Argo CD, o GitHub e o AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 4

Esse cenário é um pipeline de DevOps baseado em pull para um aplicativo Web típico. O pipeline usa o GitHub Actions para build. Para implantação, ele usa o Argo CD como o operador GitOps para efetuar pull e sincronizar o aplicativo.

O fluxo de dados a seguir corresponde ao diagrama anterior:

  1. O código do aplicativo é desenvolvido usando um IDE, como o Visual Studio Code.

  2. O código do aplicativo é confirmado em um repositório GitHub.

  3. O GitHub Actions cria uma imagem de contêiner do código do aplicativo e envia a imagem do contêiner por push para o Registro de Contêiner.

  4. O GitHub Actions atualiza um arquivo de manifesto de implantação do Kubernetes com a versão atual da imagem, baseada no número de versão da imagem de contêiner no Registro de Contêiner.

  5. O Argo CD extrai do repositório Git.

  6. O Argo CD implanta o aplicativo no cluster do AKS.

Alternativas para o cenário 4

Qualquer repositório compatível com o Git, incluindo o Azure DevOps, pode servir como o repositório de origem de configuração.

Detalhes do cenário

O GitOps é um conjunto de princípios para operar e gerenciar um sistema de software.

  • Ele usa o controle do código-fonte como a única fonte de verdade para o sistema.

  • Ele aplica práticas de desenvolvimento como controle de versão, colaboração, conformidade e ci/cd (integração contínua e implantação contínua) à automação de infraestrutura.

  • Você pode aplicá-lo a qualquer sistema de software.

O GitOps geralmente é usado para gerenciamento de cluster do Kubernetes e entrega de aplicativos.

De acordo com os princípios do GitOps, o estado desejado de um sistema gerenciado pelo GitOps deve atender aos seguintes critérios:

  • Declarativo: Um sistema gerenciado pelo GitOps deve ter seu estado desejado expresso declarativamente. Normalmente, a declaração é armazenada em um repositório Git.

  • Com versão e imutável: O estado desejado é armazenado de uma maneira que impõe imutabilidade e controle de versão e mantém um histórico de versão completo.

  • Efetuado automaticamente: Os agentes de software retiram automaticamente as declarações de estado desejadas da origem.

  • Reconciliado continuamente: Os agentes de software continuamente observam o estado real do sistema e tentam aplicar o estado desejado.

No GitOps, a IaC usa código para declarar o estado desejado de componentes de infraestrutura, como VMs (máquinas virtuais), redes e firewalls. Esse código tem controle de versão e é auditável.

O Kubernetes descreve tudo, desde o estado do cluster até implantações de aplicativos declarativamente usando manifestos. O GitOps para Kubernetes coloca o estado desejado da infraestrutura de cluster sob controle de versão. Um componente no cluster, normalmente chamado de operador, sincroniza continuamente o estado declarativo. Essa abordagem possibilita examinar e auditar alterações de código que afetam o cluster. Melhora a segurança ao apoiar o princípio do menor privilégio (PoLP).

Os agentes do GitOps reconciliam continuamente o estado do sistema com o estado desejado armazenado em seu repositório de código. Alguns agentes do GitOps podem reverter operações executadas fora do cluster, como a criação manual de objetos kubernetes. Por exemplo, os controladores de admissão impõem políticas em objetos durante operações de criação, atualização e exclusão. Você pode usá-las para garantir que as implantações sejam alteradas somente se o código de implantação no repositório de origem for alterado.

Você pode combinar ferramentas de gerenciamento e imposição de políticas com o GitOps para impor políticas e fornecer comentários sobre as alterações de política propostas. Você pode configurar notificações para equipes individuais para mantê-las informadas sobre o status atual do GitOps. Por exemplo, você pode enviar notificações de êxitos de implantação e falhas de reconciliação.

GitOps como a única fonte de verdade

O GitOps fornece consistência e padronização do estado do cluster e pode ajudar a aprimorar a segurança. Você também pode usar o GitOps para garantir o estado consistente em vários clusters. Por exemplo, o GitOps pode aplicar a mesma configuração entre clusters primários e de recuperação de desastre (DR) ou em um grupo de clusters.

Para impor o GitOps como o único método para alterar o estado do cluster, restrinja o acesso direto ao cluster. Para definir essa configuração, use o RBAC (controle de acesso baseado em função) do Azure, controladores de admissão ou outras ferramentas.

Usar o GitOps para inicializar a configuração inicial

Às vezes, a implantação de cluster do AKS é necessária como parte da configuração de linha de base. Por exemplo, talvez seja necessário implantar serviços compartilhados ou configurações no nível do sistema antes de implantar cargas de trabalho do aplicativo. Esses serviços compartilhados podem configurar os seguintes complementos e ferramentas:

Você pode habilitar o Flux como uma extensão aplicada ao criar um cluster do AKS. O Flux pode inicializar a configuração de linha de base para o cluster. A arquitetura de linha de base de um cluster do AKS recomenda que você use o GitOps para inicialização. Se você usar a extensão Flux, poderá inicializar clusters logo após a implantação.

Outras ferramentas e complementos do GitOps

Você pode estender os cenários descritos para outras ferramentas do GitOps. O Jenkins X é outra ferramenta do GitOps que fornece instruções para integrar ao Azure. Você pode usar ferramentas de entrega progressivas, como do Flagger para mudança gradual de cargas de trabalho de produção implantadas por meio do GitOps.

Possíveis casos de uso

Essa solução beneficia as organizações que desejam implantar aplicativos e IaC e manter um rastro de auditoria de cada alteração.

O GitOps simplifica o gerenciamento de contêiner para desenvolvedores, o que aumenta a produtividade. Os desenvolvedores podem continuar a trabalhar com ferramentas familiares, como o Git, para gerenciar atualizações e novos recursos.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Confiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Se um cluster ficar indisponível, o GitOps deverá ser usado como parte da criação de um novo cluster. Ele usa o repositório Git como a única fonte de verdade para a configuração do Kubernetes e a lógica do aplicativo. Ele pode criar e aplicar a configuração do cluster e a implantação da aplicação como uma unidade de escala e pode estabelecer o padrão Deployment Stamps.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Com a abordagem do GitOps, desenvolvedores ou administradores individuais não acessam diretamente os clusters do Kubernetes para aplicar mudanças ou atualizações. Em vez disso, os usuários enviam alterações por push para um repositório Git e o operador GitOps, como Flux ou Argo CD, lê as alterações e as aplica ao cluster. Essa abordagem segue a melhor prática de segurança de privilégios mínimos, sem conceder permissões de gravação para a API do Kubernetes às equipes de DevOps. Em cenários de diagnóstico ou solução de problemas, você pode conceder permissões de cluster por um tempo limitado e caso a caso.

Além de configurar permissões de repositório, considere implementar as seguintes medidas de segurança em repositórios Git que sincronizam com clusters do AKS:

  • Proteção de ramificação: proteja as ramificações que representam o estado dos clusters do Kubernetes contra mudanças feitas diretamente neles. Use PRs (solicitações de pull) para fazer alterações e faça com que pelo menos outra pessoa examine cada PR. Use também PRs para fazer verificações automáticas.

  • Revisão de PR: Exigir que as PRs tenham pelo menos um revisor para impor o princípio de quatro olhos. Você também pode usar o recurso proprietários de código do GitHub para definir indivíduos ou equipes responsáveis por revisar arquivos específicos em um repositório.

  • Histórico imutável: permite somente novas confirmações sobre as mudanças existentes. O histórico imutável é especialmente importante para fins de auditoria.

  • Outras medidas de segurança: exigir que os usuários do GitHub ativem a autenticação de dois fatores. Permitir somente confirmações assinadas para impedir alterações.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

  • A camada gratuita do AKS oferece a gestão de cluster sem custos. Os custos são limitados aos recursos de computação, armazenamento e rede usados pelo AKS para hospedar nós. A camada gratuita do AKS não inclui um SLA (contrato de nível de serviço) e não é recomendada para cargas de trabalho de produção.

  • O GitHub fornece um serviço gratuito, mas para usar recursos avançados relacionados à segurança, como proprietários de código ou revisores necessários, você precisa do plano de equipe. Para obter mais informações, consulte os preços do GitHub.

  • O Azure DevOps fornece uma camada gratuita que você pode usar para alguns cenários.

  • Use a Calculadora de Preços do Azure para estimar os custos.

Excelência operacional

A Excelência operacional abrange os processos de operações que implantam uma aplicação e as mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design para Excelência Operacional.

O GitOps pode aumentar produtividade do DevOps. Um dos recursos mais úteis é a capacidade de reverter rapidamente as alterações que se comportam inesperadamente executando operações git. O grafo de confirmação ainda contém todas as confirmações, para que possa ajudar na análise retrospectiva.

As equipes do GitOps geralmente gerenciam vários ambientes para o mesmo aplicativo. É comum ter vários estágios de um aplicativo implantado em diferentes clusters ou namespaces do Kubernetes. O repositório Git, que é a única fonte de verdade, mostra as versões de aplicativos implantadas no momento em um cluster.

Selecionar um cenário

Para obter mais informações sobre como implantar os cinco cenários, consulte os seguintes recursos:

  • Cenário 1: Para obter diretrizes sobre como usar o GitOps com o Flux v2 para implantar aplicativos no AKS, consulte Tutorial: Implantar aplicativos usando o GitOps com o Flux v2. Para obter um exemplo de como usar a extensão Flux para inicializar a implantação de cluster do AKS, consulte a implementação de referência para ode linha de base do AKS.

  • Cenário 2: Para obter diretrizes sobre como usar o GitOps com o Flux v2 no AKS para implantar aplicativos e implementar CI/CD, consulte Tutorial: Implementar CI/CD com GitOps (Flux v2).

  • Cenários 3 e 4: Para obter diretrizes passo a passo sobre como implantar uma carga de trabalho de exemplo com o Argo CD e o AKS, consulte o cenário de CI/CD baseado em pull na automação de linha de base do AKS.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas