This page describes configs, the files Anthos Config Management reads from Git and applies to your clusters automatically. You can create a config and commit it to your repo.
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 kubectl apply
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: enabled
is applied to the Kubernetes object
The
foo-corp
cluster has a ClusterRole namedpod-accountant
that does not have theconfigmanagement.gke.io/managed: enabled
annotation, and no config for the ClusterRole object exists in the repo. Anthos Config Management does not configure thepod-accountant
ClusterRole.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.yaml
file in the repo. This config defines a ClusterRole calledquota-viewer
. Because the config is created in thecluster/
directory, it affects all enrolled clusters. Anthos Config Management detects the newly-committed config and applies it. Thequota-viewer
ClusterRole now exists in the cluster, has theconfigmanagement.gke.io/managed: enabled
annotation, and is in sync with the contents ofquota-viewer-clusterrole.yaml
.Some time later, someone deletes the
cluster/quota-viewer-clusterrole.yaml
file from the repo. Anthos Config Management detects this change and removes thequota-viewer
ClusterRole from the cluster.You can start managing an existing object in a cluster by adding the
configmanagement.gke.io/managed: enabled
annotation.The
foo-corp
cluster has a namespace directory calledshipping-dev
. Within this namespace directory, a config for a Role calledjob-creator
exists and has theconfigmanagement.gke.io/managed: enabled
annotation. Someone updates the filenamespaces/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.
The
foo-corp
cluster has a RoleBinding namedpod-creator
and a corresponding/namespaces/pod-creator/pod-creator.yaml
file in the repo. The diagram shows thatshipping-prod
,shipping-staging
, andshipping-dev
are all namespaces (they each have anamespace.yaml
file that defines a namespace) within theshipping-dev-backend
abstract namespace directory. Each of these namespaces inherits thepod-creator
RoleBinding.Some time later, someone modifies the
pod-creator
RoleBinding in theshipping-prod
namespace directory. The Operator detects the change and updatespod-creator
to match the config in the repo.Eventually, someone removes the
pod-creator
config from the repo. Anthos Config Management detects the change and removes thepod-creator
RoleBinding from each of the three namespaces.Anthos Config Management allows you to manually apply changes and doesn't manage objects unless they have the
configmanagement.gke.io/managed: enabled
annotation.Someone manually creates a new Role called
secret-admin
in theshipping-prod
namespace. No config exists for thesecret-admin
Role in the repo. Thesecret-admin
Role does not have theconfigmanagement.gke.io/managed: enabled
annotation. Anthos Config Management takes no action.Some time later, someone manually adds the
configmanagement.gke.io/managed:enabled
annotation to thesecret-admin
Role. There is still no corresponding config in the repo, so Anthos Config Management deletes thesecret-admin
Role from the namespace.Anthos Config Management creates missing namespaces if configs exist for them.
Someone commits a new config for the
audit
namespace, which doesn't exist in the cluster. Anthos Config Management creates theaudit
namespace in the cluster and applies theconfigmanagement.gke.io/managed: enabled
annotation to it.Anthos Config Management can manage configs for a namespace that doesn't have the
configmanagement.gke.io/managed: enabled
annotation.The
shipping-dev
namespace exists in the cluster but does not have theconfigmanagement.gke.io/managed: enabled
annotation. However, theshipping-dev
namespace directory in the repo has a RoleBinding namedjob-creators
, which has theconfigmanagement.gke.io/managed: enabled
annotation.Someone adds a config for the
shipping-dev
namespace to the repo, but there is no config for thejob-creators
RoleBinding. Since no config exists for the RoleBinding, but the RoleBinding has theconfigmanagement.gke.io/managed: enabled
annotation, Anthos Config Management deletes the RoleBinding.Later, someone adds a config for the
job-creators
RoleBinding. Thejob-creators
RoleBinding is re-created with the properties defined in the config.