Práticas recomendadas do GitOps do Kubernetes com o Config Sync

Nesta página, fornecemos um ponto de partida para ajudar você a planejar e arquitetar pipelines de GitOps de CI/CD para o Kubernetes, o que pode ajudar você a aproveitar ao máximo o Config Sync.

O GitOps é uma prática recomendada universal para organizações que gerenciam a configuração do Kubernetes como escala. Mas quando se trata de arquitetar essa solução, há muitas opções. Entender suas opções, os benefícios e as vantagens e desvantagens dessas decisões pode ajudar você a evitar a necessidade de reescrever a arquitetura no futuro.

Não é necessário seguir todas as práticas recomendadas listadas nesta página. As práticas recomendadas que você escolhe adotar dependem da situação específica. O objetivo desta página é ajudar você a tomar decisões fundamentadas ao configurar sua arquitetura do GitOps.

Usar um repositório de pacotes privado e centralizado

Usar um repositório central para pacotes públicos ou internos (como Helm ou kpt) pode ajudar as equipes a encontrar pacotes com mais facilidade. É possível usar serviços como o Artifact Registry ou repositórios Git.

A equipe da plataforma pode implementar políticas em que as equipes de aplicativo só podem usar pacotes do repositório central. Como alternativa, elas podem usar o repositório central como um conjunto de pacotes selecionados.

É possível limitar as permissões de gravação ao repositório a apenas um pequeno número de engenheiros. O restante da organização pode ter acesso de leitura. Recomendamos implementar um processo para promover pacotes no repositório central e transmitir atualizações.

A tabela a seguir lista os benefícios e desvantagens de usar um repositório de pacotes privado e centralizado:

Benefícios

Desvantagens

Ingira pacotes públicos em uma cadência definida, o que ajuda a evitar interrupções por conectividade ou desligamento de usuários. Analise e verifique pacotes compartilhados. Fornece uma maneira fácil de descobrir o que está em uso e o que é compatível. Por exemplo, as equipes podem encontrar com mais facilidade a implantação padrão do Redis armazenada no repositório central. Faça alterações nos pacotes upstream para garantir que eles atendam aos padrões internos, como valores padrão, adição de rótulos e repositórios de imagens de contêiner.

Alguém precisa manter o repositório central. Adicione mais processos para equipes de aplicativos.

Criar repositórios molhados

Crie repositórios com a saída YAML que corresponda ao estado pretendido do seu cluster ou namespace. As alterações no repositório molhado ou totalmente hidratado precisam ser fáceis de revisar usando uma comparação. Uma prática recomendada é fazer alterações apenas no repositório molhado por meio de um processo de revisão. Por exemplo, no GitHub, isso seria uma solicitação de pull.

A tabela a seguir lista os benefícios e desvantagens da criação de repositórios molhados:

Benefícios	Desvantagens
Mais fácil de examinar a diferença. Nenhum processamento é necessário para ver o estado pretendido da configuração.	Uma configuração totalmente hidratante pode levar à repetição do YAML.

Deslocar para a esquerda para validar configs

Aguardar até que o Config Sync comece a sincronizar para verificar se há problemas pode criar confirmações do Git e um longo ciclo de feedback desnecessário. Muitos problemas podem ser encontrados antes que uma configuração seja aplicada a um cluster usando funções de validador kpt, como kubeval.

A tabela a seguir lista os benefícios e desvantagens de verificar problemas antes de aplicar uma configuração:

Benefícios	Desvantagens
A exibição de alterações de configuração em uma solicitação de alteração pode ajudar a evitar erros em um repositório. Reduz o impacto de problemas em configurações compartilhadas.	É necessário adicionar ferramentas e lógica ao processo de confirmação para ajudar a detectar problemas.

Usar pastas em vez de branches

Use pastas para variantes da configuração em vez de branches. Com pastas, é possível usar o comando tree para ver variantes. Por exemplo, com ramificações, não é possível dizer se o delta entre um branch de produção e um de cenário é uma mudança futura na configuração ou uma diferença permanente entre os estágios e a produção.

A tabela a seguir lista os benefícios e desvantagens de usar pastas em vez de ramificações:

Benefícios

Desvantagens

A descoberta de pastas é mais fácil do que com as ramificações. É possível fazer a diferenciação em pastas com muitas ferramentas de CLI e GUI, enquanto a diferença de ramificações é menos comum fora dos provedores Git. Com as pastas, é mais fácil notar diferenças permanentes e não promovidas. É possível implementar alterações em vários clusters e namespaces em uma solicitação de alteração, enquanto as ramificações exigem várias solicitações de alteração para ramificações diferentes.

Não é possível promover alterações de configuração usando uma solicitação de alteração nos mesmos arquivos.

Minimizar o uso de ClusterSelectors

ClusterSelectors permite aplicar determinadas partes de uma configuração a um subconjunto de clusters. Em vez de configurar um RootSync ou RepoSync, é possível modificar o recurso que está sendo aplicado ou adicionar rótulos aos clusters. No entanto, com o tempo, à medida que o número de ClusterSelectors cresce, pode ser complicado entender o estado final do cluster.

O Config Sync permite sincronizar vários RootSyncs e RepoSyncs de uma só vez, o que significa que você pode adicionar a configuração relevante a um repositório separado e sincronizá-lo com os clusters que quiser.

A tabela a seguir lista os benefícios e desvantagens de não usar o ClusterSelectors:

Benefícios	Desvantagens
É mais fácil montar a configuração que estará no cluster em uma pasta em vez de tomar essa decisão no cluster. Reduz a carga mental de entender o que será realmente aplicado ao cluster.	Os rótulos são uma maneira leve de adicionar uma característica a um cluster. A criação de um novo "RepoSync" é mais complexa.

Evite gerenciar jobs com o Config Sync

Embora o Config Sync possa aplicar jobs para você, eles não são adequados para implantação do Git pelos seguintes motivos:

• Campos imutáveis: muitos campos do job são imutáveis. Para alterar um campo imutável, o objeto precisa ser excluído e recriado. No entanto, o Config Sync não exclui seu objeto, a menos que você o remova da origem.

• Execução não intencional de jobs: se você sincronizar um job com o Config Sync e ele for excluído do cluster, o Config Sync vai considerar o desvio do estado escolhido e recriar o Vaga. Se você especificar um Time to live (TTL), ele será excluído automaticamente, e o Config Sync o recria automaticamente, reiniciando o job até que você exclua o o job usando a fonte da verdade. Muitas vezes, isso não é o que era esperado, porque o Config Sync executa o job novamente.

• Problemas de reconciliação: o Config Sync normalmente espera a reconciliação dos objetos após a aplicação. No entanto, os jobs são considerados reconciliados quando começam a ser executados. Isso significa que o Config Sync não espera a conclusão do job para continuar a aplicar outros objetos. No entanto, se o job falhar posteriormente, isso será considerado uma falha de reconciliação. Em alguns casos, isso pode impedir que outros recursos sejam sincronizados e causar erros até que o problema seja corrigido. Em outros casos, a sincronização pode ser bem-sucedida e apenas a reconciliação vai falhar.

Por esses motivos, não recomendamos sincronizar jobs com o Config Sync.

Na maioria dos casos, os jobs e outras tarefas situacionais precisam ser gerenciados por um serviço que faça o gerenciamento do ciclo de vida. Em seguida, você pode gerenciar esse serviço com o Config Sync, em vez dos próprios jobs.

A tabela a seguir lista as vantagens e desvantagens de não usar o Config Sync para gerenciar jobs:

Benefícios

Desvantagens

Maior compatibilidade com o GitOps. Os jobs não funcionam bem com a abordagem declarativa e controlada por versões do GitOps por causa dos campos imutáveis. Reduz consequências não intencionais. Elimina o risco de o Config Sync recriar automaticamente os jobs excluídos, o que pode causar uma execução inesperada. Menos erros de sincronização. Possíveis conflitos de sincronização e erros acionados por jobs com falha são evitados.

Gerenciamento manual de jobs. É preciso encontrar outro serviço para gerenciar jobs.

Usar repositórios não estruturados

O Config Sync é compatível com duas estruturas para organizar um repositório: não estruturado e hierárquico. A abordagem não estruturada é a recomendada porque permite que você organize um repositório da maneira mais conveniente para você. Os repositórios hierárquicos, por comparação, impõem uma estrutura específica. Por exemplo, os CRDs precisam estar em um diretório específico. Isso pode causar problemas quando você precisa compartilhar configs. Por exemplo, se uma equipe publicar um pacote que contenha um CRD, outra equipe que precise usar esse pacote terá que mover o CRD para um diretório cluster, adicionando mais sobrecarga ao processo.

A tabela a seguir lista os benefícios e desvantagens do uso de repositórios não estruturados:

Benefícios	Desvantagens
É possível reutilizar pacotes de configuração compartilhados, mesmo se eles contiverem CRDs ou outras definições de todo o cluster neles.	Sem um processo ou diretrizes, as estruturas de repositório podem variar entre as equipes, o que pode dificultar a implementação de ferramentas para toda a frota.

Para saber como converter um repositório hierárquico, consulte Converter um repositório hierárquico em um repositório não estruturado.

Separar código e repositórios de configuração

Ao escalonar verticalmente um monorepositório, ele exige um build específico para cada pasta. Permissões e preocupações para pessoas que trabalham no código e na configuração do cluster geralmente são diferentes. Ao manter os repositórios de código e configuração separados, cada repositório pode ter as próprias permissões e estrutura.

A tabela a seguir lista os benefícios e desvantagens de separar códigos e repositórios de configuração:

Benefícios	Desvantagens
Evita confirmações de "looping". Por exemplo, a confirmação em um repositório de código pode acionar uma solicitação de CI, que pode produzir uma imagem, o que requer uma confirmação do código e assim por diante. É possível usar permissões diferentes para pessoas que trabalham no código do aplicativo e na configuração do cluster.	Reduz a descoberta da configuração do aplicativo, já que ele não está no mesmo repositório que o código do aplicativo. O gerenciamento de muitos repositórios pode ser demorado.

Usar repositórios separados para isolar alterações

Ao escalonar um repositório mono, permissões diferentes são necessárias em pastas diferentes. Por isso, a separação de repositórios permite limites de segurança entre a segurança, a plataforma e a configuração do aplicativo. Também é uma boa ideia separar os repositórios de produção e não produção.

A tabela a seguir lista os benefícios e desvantagens das alterações isoladas em repositórios separados:

Benefícios

Desvantagens

Em uma organização com equipes de plataforma, segurança e aplicativos, a cadência de alterações e permissões é diferente. As permissões permanecem no nível do repositório. Os arquivos CODEOWNERS permitem que as organizações limitem a permissão de gravação sem impedir a permissão de leitura. O Config Sync é compatível com várias sincronizações por namespace, o que pode gerar um "efeito combinado" a partir de vários repositórios.

Gerenciar vários repositórios é uma tarefa independente. Então, no caso de você criar um novo repo por cluster, o problema da configuração/desmontagem do cluster agora precisa incluir o gerenciamento de repo.

Fixar versões do pacote

Seja usando o Helm ou o Git, você precisa fixar a versão do pacote de configuração em algo que não seja movido acidentalmente sem uma implementação explícita.

A tabela a seguir lista os benefícios e desvantagens de fixar versões de pacote:

Benefícios	Desvantagens
A atualização da configuração compartilhada pode ter um impacto maior do que o planejado se a versão do pacote não estiver fixada.	Os lançamentos exigem verificações quando os pacotes compartilhados são atualizados.

Usar identidade da carga de trabalho

É possível ativar a Identidade da carga de trabalho nos clusters do GKE, o que permite que as cargas de trabalho do Kubernetes acessem os serviços do Google de maneira segura e gerenciável.

A tabela a seguir lista os benefícios e desvantagens de usar a Identidade da carga de trabalho:

Benefícios	Desvantagens
Reduz a complexidade e os possíveis problemas com senhas e secrets.	Serviços fora do Google Cloud (como GitHub e GitLab) não são compatíveis com a Identidade da carga de trabalho.

Arquitetura de alto nível

Em um nível alto, você provavelmente quer pelo menos quatro tipos de repositórios:

1. Um repositório de pacotes em que a configuração compartilhada é armazenada. Também pode ser um gráfico do Helm armazenado no Artifact Registry.
2. Um repositório de plataforma em que a equipe da plataforma armazena a configuração de toda a frota para clusters e namespaces.
3. Um repositório de configuração de aplicativo.
4. Um repositório de código do aplicativo.

O diagrama a seguir mostra o layout desses repositórios:

O diagrama a seguir mostra o fluxo de configuração do código do aplicativo para um repositório de configuração do aplicativo. As equipes de desenvolvimento enviam códigos para aplicativos e configurações de aplicativos para um repositório. O código para aplicativos e configurações é armazenado no mesmo local, e as equipes de aplicativo têm controle sobre esses repositórios. As equipes de aplicativos podem enviar o código para um build.

A seguir

• Primeiros passos com o Config Sync