Práticas recomendadas para o Config Connector
Nesta página, explicamos as práticas recomendadas que você precisa considerar ao usar o Config Connector.
Gerenciar limites de cota da API
Se ocorrer erros indicando que excedeu o limite de cota da API, talvez você tenha criado muitos recursos do Config Connector do mesmo tipo no mesmo projeto de cota. Quando você cria muitos recursos, eles podem gerar muitas solicitações de API para o mesmo endpoint de API devido à estratégia de reconciliação usada pelo Config Connector.
Uma maneira de resolver esse problema é solicitar um aumento de cota. Além de um aumento de cota, se você tiver confirmado que o erro de cota é causado por solicitações GET nos recursos do Google Cloud gerenciados pelos recursos do Config Connector, considere uma das seguintes opções:
- Aumente o intervalo de reconciliação para seus recursos do Config Connector
- Divida seus recursos em vários projetos
- Alternar o Config Connector para o modo com namespace
Aumentar o intervalo de reconciliação
É possível aumentar o tempo entre a reconciliação de um recurso pelo Config Connector para evitar atingir as cotas da API. A recomendação é definir o intervalo de reconciliação como 1 hora.
Para aumentar o intervalo de reconciliação, siga as etapas em Como configurar o intervalo de reconciliação.
Dividir seus recursos em vários projetos
Essa abordagem distribui os recursos do Config Connector em diferentes projetos. Essa abordagem funciona bem ao adicionar novos recursos, mas pode ser
arriscado dividir os atuais porque é necessário excluir os recursos
atuais e recriá-los em projetos diferentes. A exclusão de recursos pode
causar perda de dados com alguns tipos de recursos, como os recursos SpannerInstance
ou
BigtableTable
. Faça backup dos seus dados antes de excluí-los.
Para dividir os recursos atuais do Config Connector em projetos diferentes, siga estas etapas:
- Decida quais recursos do Config Connector você planeja mover para diferentes projetos.
- Exclua os recursos do Config Connector.
Verifique se a anotação
cnrm.cloud.google.com/deletion-policy
não está definida comoabandon
. - Atualize o campo
spec.projectRef
ou a anotaçãocnrm.cloud.google.com/project-id
na configuração YAML dos recursos do Config Connector que você planeja mover para os novos projetos. - Conceda à conta de serviço do IAM usada pelo Config Connector as permissões adequadas nos novos projetos.
- Aplique a configuração YAML atualizada para criar os recursos do Config Connector.
Alternar para o modo com namespace
É possível vincular diferentes contas de serviço do IAM de diferentes projetos do Google Cloud a diferentes namespaces em que o Config Connector está instalado no modo com namespace e dividir seus recursos em namespaces distintos. Para fazer isso, siga estas etapas:
Configure o Config Connector para ser executado no modo com namespace. Crie novas contas de serviço do IAM de projetos diferentes e vincule-as a namespaces distintos seguindo as instruções para configurar o Config Connector para cada projeto.
Conceda às novas contas de serviço do IAM as permissões adequadas ao projeto que contém os recursos.
Decida quais recursos do Config Connector você planeja mover para diferentes namespaces.
Atualize a configuração YAML dos recursos do Config Connector e defina a anotação
cnrm.cloud.google.com/deletion-policy
comoabandon
.Aplique a configuração YAML atualizada para atualizar a política de exclusão dos recursos do Config Connector.
Atualize o campo
metadata.namespace
na configuração YAML dos recursos do Config Connector que você planeja mover para os diferentes namespaces.Aplique a configuração YAML atualizada para adquirir os recursos abandonados.
Gerenciar pools de nós em clusters do GKE
É possível que ocorram erros ao criar um cluster ao aplicar um
recurso ContainerCluster
no Config Connector e tentar atualizar o
nodeConfig
ou outros campos relacionados ao nó aplicando uma configuração
ContainerCluster
atualizada. Esses erros ocorrem devido a campos imutáveis como
nodeConfig
, nodeConfig.labels
e nodeConfig.taint
, que é uma limitação
técnica da
API Google Cloud subjacente.
Se você precisar atualizar esses campos, use o recurso
ContainerNodePool
para gerenciar pools de nós em que esses campos não são imutáveis. Para gerenciar
pools de nós usando o recurso ContainerNodePool
, especifique uma
anotação cnrm.cloud.google.com/remove-default-node-pool: "true"
. Essa anotação remove o pool de nós padrão gerado durante a criação do cluster. Em seguida, para criar pools de nós separados, especifique os campos nodeConfig
em
ContainerNodePool
em vez de em ContainerCluster
. Consulte o
exemplo de recurso ContainerNodePool
para referência.
Defina a anotação
cnrm.cloud.google.com/state-into-spec: absent
para os recursos ContainerCluster
e ContainerNodePool
. Essa anotação evita possíveis erros de reconciliação durante a interação entre o controlador do Config Connector e as APIs subjacentes.
Os exemplos abaixo mostram uma configuração ContainerCluster
e ContainerNodePool
com essas anotações definidas:
apiVersion: container.cnrm.cloud.google.com/v1beta1 kind: ContainerCluster metadata: name: containercluster-sample annotations: cnrm.cloud.google.com/remove-default-node-pool: "true" cnrm.cloud.google.com/state-into-spec: absent spec: description: A sample cluster. location: us-west1 initialNodeCount: 1
apiVersion: container.cnrm.cloud.google.com/v1beta1 kind: ContainerNodePool metadata: labels: label-one: "value-one" name: containernodepool-sample annotations: cnrm.cloud.google.com/state-into-spec: absent spec: location: us-west1 autoscaling: minNodeCount: 1 maxNodeCount: 3 nodeConfig: machineType: n1-standard-1 preemptible: false oauthScopes: - "https://www.googleapis.com/auth/logging.write" - "https://www.googleapis.com/auth/monitoring" clusterRef: name: containercluster-sample