This page describes configs, the files Anthos Config Management reads from Git and applies to your clusters automatically. You can create a config.
Anthos Config Management keeps your enrolled clusters in sync using configs. A
config is a YAML or JSON file that is stored in your
repo and contains the same types of configuration
details that you can manually apply to a cluster using the
command. This topic covers how configs work, how to write them, and how
Anthos Config Management applies them to your enrolled clusters.
Anthos Config Management is designed for cluster operators who manage many clusters. You can ensure that your clusters meet business and compliance standards by allowing Anthos Config Management to manage Namespaces, Roles, RoleBindings, ResourceQuotas, and other important Kubernetes objects, across your fleet. You can create a config for any Kubernetes object that can exist in a cluster.
Working with configs over time
The following decision tree illustrates the results of different configuration changes in a hypothetical group of clusters managed by Anthos Config Management over time. Following the diagram, some hypothetical actions by cluster operators and the results of those actions are discussed and used to illustrate how Anthos Config Management works.
This cluster uses the example repo. The cluster is already registered with Operator.
Anthos Config Management applies configs only when at least one of the following is true:
- a relevant config exists in the repo
- the annotation
configmanagement.gke.io/managed: enabledis applied to the Kubernetes object
foo-corpcluster has a ClusterRole named
pod-accountantthat does not have the
configmanagement.gke.io/managed: enabledannotation, and no config for the ClusterRole object exists in the repo. Anthos Config Management does not configure the
Anthos Config Management applies a relevant change automatically when it is committed to the repo.
A cluster administrator commits a config to the
cluster/quota-viewer-clusterrole.yamlfile in the repo. This config defines a ClusterRole called
quota-viewer. Because the config is created in the
cluster/directory, it affects all enrolled clusters. Anthos Config Management detects the newly-committed config and applies it. The
quota-viewerClusterRole now exists in the cluster, has the
configmanagement.gke.io/managed: enabledannotation, and is in sync with the contents of
Some time later, someone deletes the
cluster/quota-viewer-clusterrole.yamlfile from the repo. Anthos Config Management detects this change and removes the
quota-viewerClusterRole from the cluster.
You can start managing an existing object in a by adding the
foo-corpcluster has a namespace directory called
shipping-dev. Within this namespace directory, a config for a Role called
job-creatorexists and has the
configmanagement.gke.io/managed: enabledannotation. Someone updates the file
namespaces/dev/shipping-dev/job-creator-role.yaml. The Operator detects and applies the change.
Anthos Config Management allows you to apply configuration changes to Namespaces in a grouped hierarchical way.
foo-corpcluster has a RoleBinding named
pod-creatorand a corresponding
/namespaces/pod-creator/pod-creator.yamlfile in the repo. The diagram shows that
shipping-devare all Namespaces (they each have a
namespace.yamlfile that defines a Namespace) within the
shipping-dev-backendabstract namespace directory. Each of these Namespaces inherits the
Some time later, someone modifies the
pod-creatorRoleBinding in the
shipping-prodnamespace directory. The Operator detects the change and updates
pod-creatorto match the config in the repo.
Eventually, someone removes the
pod-creatorconfig from the repo. Anthos Config Management detects the change and removes the
pod-creatorRoleBinding from each of the three Namespaces.
Anthos Config Management allows you to manually apply changes and doesn't manage objects unless they have the
Someone manually creates a new Role called
shipping-prodNamespace. No config exists for the
secret-adminRole in the repo. The
secret-adminRole does not have the
configmanagement.gke.io/managed: enabledannotation. Anthos Config Management takes no action.
Some time later, someone manually adds the
configmanagement.gke.io/managed:enabledannotation to the
secret-adminRole. There is still no corresponding config in the repo, so Anthos Config Management deletes the
secret-adminRole from the Namespace.
Anthos Config Management creates missing Namespaces if configs exist for them.
Someone commits a new config for the
auditNamespace, which doesn't exist in the cluster. Anthos Config Management creates the
auditNamespace in the cluster and applies the
configmanagement.gke.io/managed: enabledannotation to it.
Anthos Config Management can manage configs for a Namespace that doesn't have the
shipping-devNamespace exists in the cluster but does not have the
configmanagement.gke.io/managed: enabledannotation. However, the
shipping-devnamespace directory in the repo has a RoleBinding named
job-creators, which has the
Someone adds a config for the
shipping-devNamespace to the repo, but there is no config for the
job-creatorsRoleBinding. Since no config exists for the RoleBinding, but the RoleBinding has the
configmanagement.gke.io/managed: enabledannotation, Anthos Config Management deletes the RoleBinding.
Later, someone adds a config for the
job-creatorsRoleBinding is re-created with the properties defined in the config.