Diretrizes de fragmentação do Config Controller

Este documento fornece recomendações sobre como fragmentar o uso do Config Controller. A fragmentação é o processo de dividir recursos do Google Cloud gerenciados pelo Config Controller em vários namespaces, clusters ou projetos.

A fragmentação traz os seguintes benefícios:

  • Redução do impacto das alterações: se um único fragmento parar de funcionar, os outros fragmentos não serão afetados.
  • Ajuda a gerenciar a segurança: cada fragmento pode ter configurações dedicadas do IAM e RBAC. Invasores mal-intencionados que comprometem um fragmento não podem acessar outros. A configuração incorreta em um fragmento não afeta outros.
  • Melhor escalonabilidade: um único fragmento pode ter gargalos de escalonabilidade, como o número de objetos gerenciados ou cotas de API. Ter vários fragmentos aumenta a escalonabilidade geral do uso do Config Controller.

Usar fragmentação com o Config Controller

Há algumas maneiras diferentes de implementar a fragmentação. A melhor abordagem dependerá das suas necessidades e requisitos específicos.

Como fragmentar modelos

Há dois modelos principais de fragmentação:

  • Por linhas de negócios ou equipes de aplicativos: esse modelo normalmente é usado quando o Config Controller é usado por equipes diferentes. Nesse modelo, cada equipe tem o próprio fragmento.
  • Por ambiente: esse modelo normalmente é usado quando o Config Controller é utilizado em ambientes diferentes. Por exemplo, é possível ter um fragmento para seu ambiente de desenvolvimento, um para o ambiente de controle de qualidade e um fragmento para o ambiente de produção.

Minimizar a necessidade de referências de fragmentos cruzados

Ao fragmentar o uso do Config Controller, minimize a necessidade de referências de fragmentos cruzados. As referências de fragmentos cruzados podem tornar a configuração mais complexa e difícil de gerenciar. Consulte Referências de recursos entre instâncias para mais detalhes.

Mecanismos de fragmentação

Há três principais mecanismos de fragmentação:

  • Por namespaces: é possível criar mais namespaces e configurar o Config Connector para gerenciar recursos nesses namespaces.
  • Por instâncias do Config Controller: é possível criar várias instâncias do Config Controller em um projeto do Google Cloud.
  • Por projetos: é possível criar várias instâncias do Config Controller em vários projetos do Google Cloud. Esse mecanismo ajuda a resolver problemas de cota da API se você estiver atingindo os gargalos de cota em um único projeto. Consulte Dividir recursos em vários projetos para mais detalhes.

Advertências ao implementar a fragmentação

Ao implementar a fragmentação para o uso do Config Controller, há alguns possíveis problemas que você precisa conhecer e planejar como resolver.

Referências de recursos entre instâncias

Um dos desafios de fragmentar o Config Controller é lidar com referências de recursos entre instâncias. Por exemplo, uma equipe de plataforma pode criar Projetos em uma instância e, em seguida, as equipes de apps podem criar recursos que se referem a esses projetos em outras instâncias. Isso pode criar problemas como os seguintes:

  • Maior complexidade: gerenciar referências de recursos em clusters pode tornar a configuração mais complexa e difícil de gerenciar.
  • Risco elevado: se um recurso é excluído em um fragmento, ele ainda pode ser referenciado por recursos em outros fragmentos. Isso pode levar a comportamentos inesperados e perda de dados.
  • Degradação de desempenho: as referências de recursos entre clusters podem aumentar a latência das alterações de configuração.

Há algumas maneiras de contornar o desafio da referência cruzada:

  • Fragmentar os fragmentos de modo que não seja necessária nenhuma referência entre os fragmentos. Isso pode ser feito por meio da fragmentação por ambientes ou por equipes.
  • Usar referências externas. Isso significa que o objeto que está sendo referenciado não é gerenciado pelo Config Controller. Essa pode ser uma boa opção se o objeto não muda com frequência.
  • Ter o mesmo objeto disponível em todos os fragmentos. Essa é uma opção mais complexa, mas pode ser a melhor opção se o objeto muda com frequência. Os objetos precisam compartilhar a mesma fonte de verdade para evitar disputas de reconciliação entre esses objetos em fragmentos diferentes. É necessário definir a política de prevenção de conflitos como none para esses objetos.

Antes de escolher, é importante avaliar com cuidado as vantagens e desvantagens de cada abordagem.

Cotas da API

A fragmentação pode aumentar suas cotas de API. Você deve estar ciente disso e se planejar adequadamente. Consulte Gerenciar limites de cota de APIs para conferir as práticas recomendadas de gerenciamento de limites de cota de APIs.

A seguir