Managing conflicts with multiple Config Connector instances

This page describes how Config Connector handles cases where the same resource can be managed by multiple instances.

Config Connector manages or acquires resources by mapping the combination of Kubernetes resource name, container annotation, and if applicable, region or location. In the simplest case, you organize your resources with Google Cloud projects.

Google Cloud supports additional levels of hierarchy beyond projects: Folders, Projects, and Organizations. You can map resources to your Folders, Projects, and Organizations with an annotation. When you create a resource without an annotation using Config Connector, the resource is created in the project that shares the resource's namespace.

It is possible, but not recommended, to create two Config Connector resources in different namespaces that manage the same Google Cloud resource. Config Connector will only manage the corresponding Google Cloud resource if it is able to obtain a lease on the Google Cloud resource and conflict prevention is enabled.

Leases are namespace-scoped. To obtain a namespace-scoped lease, Config Connector adds two labels to the resource:

  1. A globally unique ID for the namespace (cnrm-lease-holder-id), and
  2. An expiration time (cnrm-lease-expiration) in Unix epoch time.

Config Connector is able to update these values if any of the following is true:

  • The value of cnrm-lease-holder-id matches the namespace's globally unique id.
  • The value of cnrm-lease-holder-id is empty or non-existent.
  • The value of cnrm-lease-expiration is in the past.

When a Config Connector instance obtains a lease on a resource, the expiration time is set to 40 minutes in the future. The same instance of Config Connector retains management as long as the resource is in the Namespace. Config Connector extends the expiration time by 40 minutes when less than 20 minutes remain.

If Config Connector is unable to obtain a lease on a given resource, the output of kubectl describe on the resource will list a Status of ManagementConflict.

Modifying conflict prevention

You can control conflict prevention by adding the cnrm.cloud.google.com/management-conflict-prevention-policy annotation to the resource with one of the following values,

  • resource: management conflicts are prevented at the resource level by saving the appropriate lease labels into the resource as described above.
  • none: management conflicts are not prevented.

The default value depends on if a Config Connector resource supports labels.

If the resource supports labels, the default is resource. If the resource does not support labels, then the default is none.

In the example below, a manifest for the default ComputeNetwork uses a management policy of 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