You're viewing documentation for Anthos Config Management 1.3. This version has reached end of life and is no longer supported. View the latest documentation.

Anthos Config Management overview

Anthos Config Management allows cluster operators to manage single clusters, multi-tenant clusters, and multi-cluster Kubernetes deployments by using files, called configs, stored in a Git repository (or repo).

Some configs are Kubernetes object manifests. Other configs are not object manifests, but instead provide information needed by Anthos Config Management. You can write configs in YAML or JSON. Anthos Config Management watches for updates to these files and applies changes to all relevant clusters automatically.

A configuration-as-code approach allows you to manage the configuration of your Google Kubernetes Engine (GKE) or Anthos clusters on VMware clusters by using the same principles that you may already be using to manage your applications deployed in Kubernetes. With Anthos Config Management, you can do the following:

  • Require code reviews before changes are pushed to the live environment, and audit exactly which commit caused a configuration change.
  • Reduce the risk of shadow ops, where unvetted changes are pushed to live clusters, and where it is difficult to understand the differences between a documented configuration and your live environment. You can require that all cluster configuration changes are propagated by using Anthos Config Management and lock down direct access to the Kubernetes API.
  • Apply configuration changes to hundreds of clusters with a single Git commit instead of writing scripts to run thousands of kubectl apply commands manually.
  • Ensure that a change is pushed to each relevant cluster and only relevant clusters, based on metadata applied to each cluster.
  • Use Continuous Integration/Continuous Deployment (CI/CD) pipelines to test your changes and apply them automatically when tests pass.
  • Use a revert then investigate strategy to roll back breaking changes and get your live clusters back into a good working state before fixing the problematic change and applying it as a new commit. This strategy reduces downtime due to configuration-related outages.

Anthos Config Management synchronizes the states of your clusters with your Git repository. The Config Management Operator custom controller monitors your Git repository and the states of your clusters, keeping them consistent for each Kubernetes object that you choose. If Operator fails to apply changes to a resource, the resource is left in the last known good state.

Anthos Config Management can configure a single cluster or multiple clusters from a single Git repository.


Anthos Config Management requires an active Anthos entitlement. For pricing information, contact sales.

Anthos Config Management uses namespaces, labels, and annotations as core parts of its implementation, and a good understanding of these concepts is helpful before you get started.

Before you write a config, you need to understand the required and optional fields allowed for that Kubernetes object.

In addition, Anthos Config Management introduces some new terminology and concepts. These are discussed briefly in the next section, along with links to more information about each concept.

New concepts

The following new concepts are central to Anthos Config Management.


A config is a Kubernetes configuration declaration, written in YAML or JSON, that Anthos Config Management reads and applies to one or more clusters to create or configure a Kubernetes object or resource in those clusters. Configs are stored in a Git repository (see also the definition for repo). A config can contain any configuration detail that you could apply to a Kubernetes cluster by using kubectl edit or kubectl apply. You can even configure custom resources that already exist on the cluster. Multiple configs can be defined in a single file.

For more information, see Configuring Kubernetes objects.


The repo is the Git repository where configs are stored, including the config for Anthos Config Management. All configs must be stored in the same repo. When you configure Anthos Config Management, you configure the repo, the branch, and the subdirectory that Anthos Config Management monitors for changes.

The structure of the repo is important and is discussed further in Using the Anthos Config Management repo.

Abstract namespace directory

Anthos Config Management provides a mechanism called abstract namespaces. Abstract namespaces let you apply policies to multiple related namespaces without duplicating configs, and give you the ability to override or extend a config for a given namespace or set of namespaces.

Abstract namespaces work by using a filesystem-style hierarchy in the repo. The directory structure of the namespaces/ subdirectory determines which policies apply to a namespace by using a mechanism similar to a file system tree. Namespaces can be nested into subdirectories called abstract namespace directories.

For more information, see Namespace inheritance overview.

Viewing and verifying files

Anthos Config Management provides an API. The nomos and nomos.exe commands consume the API and simplify the process of setting up the repo and validating configs.

For more information, see Using the nomos command.

What's next?