Anthos Config Management (ACM) keeps selected Kubernetes resources aligned with configuration stored in Git. It gives operations and security teams a central, version-controlled way to apply cluster configuration, application resources, and policies across on-premises and cloud clusters. The repository is the source of truth; it is not a replacement for every deployment mechanism on a cluster. section 6.3 section 11.2
A Kubernetes operator runs on each managed cluster. A ConfigManagement object identifies the cluster, tells the operator where to fetch configuration, and enables components such as Config Sync, Policy Controller, or Hierarchy Controller. The operator manages only objects defined in its policy configuration. In multiple-repository mode, RootSync and namespaced RepoSync objects hold repository-fetch settings instead. section 11.2 section 11.2.2
Plan the repository and rollout around the resources you need to control:
- Choose hierarchical mode to apply a resource across a logical collection of namespaces. Choose unstructured mode for explicit namespace selection or compatibility with templating workflows; it requires specifying the intended namespaces. section 11.5
- Set the cluster name, Git location, policy directory, sync interval, and required credentials. Use ClusterSelectors or NamespaceSelectors to target subsets rather than assuming every policy should reach every cluster or namespace. section 11.2 section 11.2.2
- Review changes through pull requests and, where available, CI/CD checks before merging. Roll out to selected clusters first; use Git history to identify and revert a problematic change. section 11.1.3
Test a release on selected clusters
Give test clusters an is-rollout-tester label, then define one ClusterSelector for those clusters and another for clusters without that label. Annotate separate Deployment definitions with the respective selectors to send a newer image to testers and the existing image elsewhere. Keep the groups nonoverlapping: an unselected second Deployment with the same name would collide with the test deployment. section 11.3.3
Check fleet sync status and the enforced revision in the Config Management console. For a rollout problem, use nomos to inspect cluster state; operator events and logs are also available through Cloud Logging and Cloud Monitoring. If repository connectivity fails, the last synced policies remain in effect, but new changes cannot arrive until syncing resumes. section 2.4.3 section 11.1.2 section 7.4.2
Policy Controller adds policy enforcement, while Config Connector can provision Google Cloud resources declared as Kubernetes objects. Treat their configuration as a security decision: for example, an mTLS policy applies to every cluster managed by its repository unless a ClusterSelector limits it. Avoid storing Secrets directly in Git; Hierarchy Controller can replicate a Secret from a namespace to its descendants. section 11.5 section 13.7
