Esta página foi traduzida pela API Cloud Translation.

Práticas recomendadas para o Config Connector

Nesta página, explicamos as práticas recomendadas a serem consideradas ao usar o Config Connector.

Gerenciar limites de cota de API

Se você encontrar erros indicando que excedeu o limite de cota da API, talvez 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 é pedir um aumento de cota. Além de um aumento de cota, se você confirmou que o erro de cota é causado por solicitações GET nos recursos Google Cloud gerenciados pelos recursos do Config Connector, considere uma das seguintes opções:

Aumente o intervalo de reconciliação dos recursos do Config Connector.
Divida seus recursos em vários projetos
Mudar o Config Connector para o modo com namespace

Aumentar o intervalo de conciliação

É possível aumentar o tempo entre o reconciliamento de um recurso pelo Config Connector para evitar atingir as cotas da API. A recomendação é definir o intervalo de conciliação como 1 hora.

Para aumentar o intervalo de conciliação, siga as etapas em Configurar o intervalo de conciliação.

Dividir 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 recursos atuais porque é necessário excluir os recursos existentes e recriá-los em projetos diferentes. A exclusão de recursos pode causar perda de dados com alguns tipos de recursos, como 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 projetos diferentes.
Exclua os recursos do Config Connector. Verifique se a anotação cnrm.cloud.google.com/deletion-policy não está definida como abandon.
Atualize o campo spec.projectRef ou a anotação cnrm.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.

Mudar para o modo com namespace

É possível vincular diferentes contas de serviço do IAM de diferentes projetosGoogle Cloud a namespaces diferentes em que o Config Connector está instalado no modo de namespace e dividir os recursos em namespaces diferentes. Para isso, siga estas etapas:

Configure o Config Connector para ser executado no modo com namespace. Crie contas de serviço do IAM em projetos diferentes e vincule-as a namespaces diferentes seguindo as instruções para configurar o Config Connector em cada projeto.
Conceda às novas contas de serviço do IAM as permissões adequadas para o projeto que contém os recursos.
Decida quais recursos do Config Connector você planeja mover para namespaces diferentes.
Atualize a configuração YAML dos recursos do Config Connector e defina a anotação cnrm.cloud.google.com/deletion-policy abandon.
Aplique a configuração YAML atualizada para atualizar a política de exclusão dos recursos do Config Connector.
Abandone os 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

Você pode encontrar erros ao criar um cluster aplicando um recurso ContainerCluster no Config Connector e tentar atualizar o nodeConfig ou outros campos relacionados a nós aplicando uma configuração ContainerCluster atualizada. Esses erros são causados por campos imutáveis, como nodeConfig, nodeConfig.labels e nodeConfig.taint, que é uma limitação técnica da Google Cloud API.

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 criado durante a criação do cluster. Em seguida, para criar pools de nós separados, especifique os campos nodeConfig em ContainerNodePool em vez de 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 a seguir mostram uma configuração de 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