Como gerenciar conflitos com várias instâncias do Config Connector

Nesta página, descrevemos como o Config Connector lida com casos em que o mesmo recurso pode ser gerenciado por várias instâncias.

O Config Connector gerencia ou adquire recursos mapeando a combinação do nome do recurso Kubernetes, a anotação do contêiner e, se aplicável, a região ou o local. No caso mais simples, você organiza seus recursos com os projetos do Google Cloud.

O Google Cloud é compatível com outros níveis de hierarquia além dos projetos: Pastas, Projetos e Organizações. Mapeie recursos para suas Pastas, Projetos e Organizações com uma anotação. Quando você cria um recurso sem uma anotação usando o Config Connector, o recurso é criado no projeto que compartilha o namespace do recurso.

É possível, mas não recomendado, criar dois recursos do Config Connector em diferentes namespaces que gerenciam o mesmo recurso do Google Cloud. O Config Connector gerenciará apenas o recurso correspondente do Google Cloud se receber uma concessão do recurso do Google Cloud e se a prevenção de conflitos estiver ativada.

Os leases têm escopo de namespace. Para conseguir um lease com escopo de namespace, o Config Connector adiciona dois rótulos ao recurso:

  1. Um código exclusivo globalmente para o namespace (cnrm-lease-holder-id) e
  2. Um tempo de expiração (cnrm-lease-expiration) no tempo de época Unix.

O Config Connector poderá atualizar esses valores se alguma das situações a seguir for verdadeira:

  • O valor de cnrm-lease-holder-id corresponde ao código exclusivo globalmente do namespace.
  • O valor de cnrm-lease-holder-id está vazio ou não existe.
  • O valor de cnrm-lease-expiration está no passado.

Quando uma instância do Config Connector recebe uma concessão de um recurso, o tempo de expiração é definido como 40 minutos no futuro. A mesma instância do Config Connector mantém o gerenciamento enquanto o recurso estiver no Namespace. O Config Connector prolonga o tempo de expiração em 40 minutos, quando restam menos de 20 minutos.

Se o Config Connector não receber uma concessão de um determinado recurso, o resultado de kubectl describe no recurso listará um Status de ManagementConflict.

Como modificar a prevenção de conflitos

É possível controlar a prevenção de conflitos adicionando a anotação cnrm.cloud.google.com/management-conflict-prevention-policy ao recurso com um dos valores a seguir:

  • resource: conflitos de gerenciamento são evitados no nível do recurso salvando os rótulos de concessão apropriados no recurso, conforme descrito acima.
  • none: conflitos de gerenciamento não são evitados.

O valor padrão depende de um recurso do Config Connector ser compatível ou não com rótulos.

Se o recurso for compatível com rótulos, o padrão será resource. Se o recurso não for compatível com rótulos, o padrão será none.

No exemplo abaixo, um manifesto para o ComputeNetwork padrão usa uma política de gerenciamento de none.

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeNetwork
metadata:
 annotations:
   cnrm.cloud.google.com/management-conflict-prevention-policy: "none"
   cnrm.cloud.google.com/project-id: "[PROJECT-ID]"
   cnrm.cloud.google.com/deletion-policy: "abandon"
 name: default
spec:
 description: Default network for the project