Como gerenciar conflitos com vários recursos do Config Connector

---

Nesta página, descrevemos como o Config Connector lida com conflitos. Podem ocorrer conflitos quando o mesmo recurso é gerenciado por vários recursos.

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 suporta com outros níveis de hierarquia além dos projetos: Pastas, Projetos e Organizações. Mapeie recursos para as 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 gerencia apenas o recurso correspondente do Google Cloud se adquirir um lease 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 identificadores ao recurso:

1. cnrm-lease-holder-id: o Config Controller gera um ID exclusivo para cada namespace que gerencia um recurso com a prevenção de conflitos ativada. Esse ID exclusivo é o que é usado para definir cnrm-lease-holder-id. Para ver o mapeamento do namespace para o valor cnrm-lease-holder-id, consulte o ConfigMap namespace-id no namespace cnrm-system.
2. cnrm-lease-expiration: um tempo de expiração no período do 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 um lease de um determinado recurso, a saída de kubectl describe no recurso lista 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: os conflitos de gerenciamento são evitados no nível do recurso salvando os identificadores de lease apropriados no recurso, conforme descrito na seção anterior.
• none: conflitos de gerenciamento não são evitados.

O valor padrão é none.

No exemplo a seguir, um manifesto para a ComputeNetwork padrão usa uma política de gerenciamento none, o que significa que os conflitos não são evitados:

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

Limitações

A prevenção de conflitos tem as seguintes limitações:

• A prevenção de conflitos não funciona para recursos que não são compatíveis com rótulos. Mesmo que você altere o valor de none para resource, ele ainda não funcionará.

• Se você estiver gerenciando de recursos com o campo resourceID, é possível criar vários recursos com o mesmo nome de recurso do Google Cloud, criado com o mesmo namespace. Esses recursos criam conflitos que o Config Connector não pode gerenciar.