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 de nome de recurso do Kubernetes, anotação de contêiner e, se aplicável, região ou local. No caso mais simples, organize 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. É possível mapear 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 resource.
É possível, mas não recomendado, criar dois recursos do Config Connector em namespaces diferentes que gerenciam o mesmo recurso do Google Cloud. O Config Connector só gerenciará o recurso do Google Cloud correspondente se for capaz de receber um lease no recurso do Google Cloud e a prevenção de conflitos estiver ativada.
As locatários têm escopo de namespace. Para conseguir um lease com escopo de namespace, o Config Connector adiciona dois recursos ao recurso:
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 será usado para definircnrm-lease-holder-id
. Para ver o mapeamento do namespace para o valorcnrm-lease-holder-id
, consulte o ConfigMapnamespace-id
no namespacecnrm-system
.cnrm-lease-expiration
: um prazo de validade em Hora de época do Unix.
O Config Connector poderá atualizar esses valores se qualquer uma das seguintes condições for verdadeira:
- O valor de
cnrm-lease-holder-id
corresponde ao ID globalmente exclusivo do namespace. - O valor de
cnrm-lease-holder-id
está vazio ou inexistente. - O valor de
cnrm-lease-expiration
está no passado.
Quando uma instância do Config Connector recebe uma alocação em um recurso, o prazo de validade é definido como 40 minutos no futuro. A mesma instância do Config Connector mantém o gerenciamento, desde que o recurso esteja no namespace. O Config Connector estende o prazo de validade 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 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 seguintes valores:
resource
: os conflitos de gerenciamento são evitados no nível do recurso salvando os rótulos 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 com recursos que não são compatíveis com rótulos. Mesmo que você altere o valor de
none
pararesource
, ele ainda não funcionará.Se você tiver Gerenciamento 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.