Nesta página, descrevemos como o Config Connector lida com conflitos. Eles podem acontecer 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 aceita níveis adicionais de hierarquia além dos projetos: pastas, projetos e organizações. É possível mapear recursos para 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 puder conseguir um lease no recurso do Google Cloud e a prevenção contra 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:
- Um ID globalmente exclusivo para o namespace (
cnrm-lease-holder-id) - 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-idcorresponde ao código exclusivo globalmente do namespace. - O valor de
cnrm-lease-holder-idestá vazio ou não existe. - O valor de
cnrm-lease-expirationestá 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 conseguir um lease em um determinado recurso, a saída de kubectl describe no recurso listará o status 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 seguintes valores:
resource: conflitos de gerenciamento são evitados no nível do recurso salvando os rótulos de alocação apropriados no recurso, conforme descrito na seção anterior.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 a seguir, um manifesto para o ComputeNetwork padrão usa uma política de gerenciamento de 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 conflito não funciona para recursos que não aceitam rótulos. Mesmo que você altere o valor de
nonepararesource, ele ainda não funcionará.Se você estiver gerenciando recursos com o campo resourceID, poderá criar vários recursos com o mesmo nome de recurso do Google Cloud, criados no mesmo namespace. Esses recursos criam conflitos que o Config Connector não pode gerenciar.