Este documento fornece recomendações sobre como dividir a utilização do Config Controller. A divisão em partições é o processo de dividir os recursos geridos pelo Config Controller em vários espaços de nomes, clusters ou projetos. Google Cloud
A divisão em partições oferece as seguintes vantagens:
- Reduz o impacto das alterações: se um único fragmento deixar de funcionar, os outros fragmentos não são afetados.
- Ajuda a gerir a segurança: cada fragmento pode ter configurações de IAM e CABF dedicadas. Os atacantes maliciosos que comprometem um fragmento não podem aceder a outros fragmentos. A configuração incorreta num fragmento não pode afetar outros fragmentos.
- Melhor escalabilidade: um único fragmento pode ter gargalos de escalabilidade, como o número de objetos geridos ou quotas da API. Ter vários fragmentos aumenta a escalabilidade geral da sua utilização do Config Controller.
Use a divisão em partições com o Config Controller
Existem algumas formas diferentes de implementar a divisão. A melhor abordagem para si depende das suas necessidades e requisitos específicos.
Modelos de fragmentação
Existem dois modelos de divisão principais:
- Por linhas de negócio ou equipas de aplicações: este modelo é normalmente usado quando o Config Controller é usado por diferentes equipas. Neste modelo, cada equipa tem o seu próprio fragmento.
- Por ambiente: este modelo é normalmente usado quando o Config Controller é usado em diferentes ambientes. Por exemplo, pode ter um fragmento para o seu ambiente de desenvolvimento, um fragmento para o seu ambiente de controlo de qualidade e um fragmento para o seu ambiente de produção.
Minimize a necessidade de referências entre fragmentos
Quando divide a utilização do Config Controller, deve minimizar a necessidade de referências entre divisões. As referências entre partições podem tornar a sua configuração mais complexa e difícil de gerir. Consulte o artigo Referências de recursos em várias instâncias para ver mais detalhes.
Mecanismos de fragmentação
Existem três mecanismos de divisão principais:
- Por espaços de nomes: pode criar espaços de nomes adicionais e configurar o Config Connector para gerir recursos nesses espaços de nomes.
- Por instâncias do Config Controller: pode criar várias instâncias do Config Controller num Google Cloud projeto.
- Por projetos: pode criar várias instâncias do Config Controller em vários Google Cloud projetos. Este mecanismo ajuda a resolver problemas de quota da API se estiver a atingir gargalos de quota com um único projeto. Consulte o artigo Divida os seus recursos em vários projetos para ver mais detalhes.
Advertências ao implementar a divisão
Quando implementar a divisão em partições para a utilização do Config Controller, existem alguns potenciais problemas dos quais deve ter conhecimento e que deve planear mitigar.
Referências de recursos em várias instâncias
Um dos desafios da divisão em partições do Config Controller é lidar com referências de recursos em várias instâncias. Por exemplo, uma equipa de plataforma pode criar projetos numa instância e, em seguida, as equipas de apps podem criar recursos que fazem referência a esses projetos noutras instâncias. Isto pode criar problemas, como:
- Maior complexidade: a gestão de referências de recursos em vários clusters pode tornar a sua configuração mais complexa e difícil de gerir.
- Aumento do risco: se um recurso for eliminado num fragmento, ainda pode ser referenciado por recursos noutros fragmentos. Isto pode levar a um comportamento inesperado e à perda de dados.
- Degradação do desempenho: as referências de recursos em vários clusters podem aumentar a latência das alterações de configuração.
Existem algumas formas de contornar o desafio de referência cruzada:
- Fragmentação de forma que não seja necessária nenhuma referência entre fragmentos. Isto pode ser feito dividindo por ambientes ou por equipas.
- Usar referências externas. Isto significa que o objeto ao qual se faz referência não é gerido pelo Config Controller. Esta pode ser uma boa opção se o objeto não mudar com frequência.
- Ter o mesmo objeto disponível em todos os fragmentos. Esta é uma opção mais complexa, mas pode ser a melhor opção se o objeto mudar com frequência.
Os objetos devem partilhar a mesma fonte de dados fidedignos para evitar conflitos de conciliação entre estes objetos em diferentes fragmentos. Tem de definir a política de prevenção de conflitos como
none
para estes objetos.
É importante considerar cuidadosamente as vantagens e as desvantagens de cada abordagem antes de escolher uma.
Quotas da API
A divisão em partições pode aumentar as suas quotas da API. Deve ter isto em atenção e planear em conformidade. Consulte o artigo Gerir limites de quota da API para ver as práticas recomendadas de gestão dos limites de quota da API.
O que se segue?
- Saiba mais sobre a escalabilidade do Config Controller