A ClusterSelector limits where Anthos Config Management (ACM) applies a managed Kubernetes resource. Instead of maintaining a separate manifest for every cluster, label each cluster with attributes such as environment, location, or purpose, then select the clusters that should receive the resource. section 8.3.2 section 11.2.2
Configure targeting in three parts:
- Define a Cluster object for each ACM-managed cluster and attach the labels used for selection. In a hierarchy repository, place Cluster definitions in the clusterregistry directory. section 8.3.2 section 11.2.2
- Define a ClusterSelector with spec.selector. Use matchLabels for required label values; matchExpressions can express conditions such as a label not existing. In a hierarchy repository, place ClusterSelectors in clusterregistry too. section 8.3.2 section 11.2.2 section 11.3.3
- Add configmanagement.gke.io/cluster-selector: <selector-name> to the managed resource’s metadata.annotations. ACM applies that resource only to matching clusters; eligible resources include Deployments, ConfigMaps, Secrets, and ClusterRoles. section 8.3.2 section 11.2.2
kind: ClusterSelector apiVersion: configmanagement.gke.io/v1 metadata: name: production-edge spec: selector: matchLabels: environment: production kind: edge
The production-edge selector requires both environment: production and kind: edge. A cluster carrying only one of those labels does not match. section 8.3.2
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: node-reader annotations: configmanagement.gke.io/cluster-selector: production-edge rules: - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"]
The ClusterRole annotation names production-edge, restricting creation of that role to matching clusters. section 8.3.2
Selectors can also target application-specific resources and, in a multiple-repository setup, RepoSync resources so a namespace repository syncs only to selected clusters. A NamespaceSelector solves a different problem: choosing namespaces rather than clusters. section 8.3.2 section 11.2.2
Separate rollout testers from other locations
Label test clusters is-rollout-tester: true. Assign one Deployment, using a newer image, to a selector matching that label; assign the other Deployment to a selector whose matchExpression requires the label not to exist. The groups do not overlap. Leaving the selector off the second Deployment would make both versions valid on test clusters, creating a collision. section 11.3.3
Check the intended scope before applying policies. An ACM-managed mTLS policy applies to every cluster managed by its external repository unless a ClusterSelector limits it. Policy Controller constraints can likewise be paired with selectors to enforce different restrictions across clusters. section 13.7 section 11.2.3
