Add configs to Git repositories
Config Sync is designed for cluster operators who manage many clusters. You can ensure that your clusters meet business and compliance standards by letting Config Sync manage namespaces, Roles, RoleBindings, ResourceQuotas, and other important Kubernetes objects, across your fleet.
When Config Sync manages these resources, it keeps your enrolled clusters in
sync using configs. A config is a YAML or JSON file that is stored in a Git
repository. Configs contain the same type of configuration details that you can
manually apply to a cluster using the
kubectl apply command. You can create a
config for any Kubernetes object that can exist in a cluster. However, some
Kubernetes objects, such as Secrets, contain sensitive information that might be
inappropriate to store in a Git repository. Use your judgment when considering
whether to manage these types of objects using Config Sync.
You can also use Config Sync with Config Connector to sync configs for Google Cloud resources. To learn more about working with Config Connector, see managing Google Cloud resources using Config Connector. You can also simplify the installation of Config Sync and Config Connector by setting up Config Controller.
This page shows you how to add configs to your repositories. To learn how to create a config, see Create configs. To learn how to publish an OCI image, see Publish config images to Artifact Registry (Preview).
Select how to organize your configs
The unstructured source format lets you organize the configs in your repository in whatever way is most convenient. This format can be especially useful if you are organizing or generating configs using a tool such as Kustomize, kpt, or Helm. For an example of how you might organize your configs, see Example format for an unstructured repository.
The hierarchical, or structured, source format separates configs into distinct categories to help you organize the configs. The categories are system configuration, cluster metadata, cluster-level configuration, and namespace configuration. For more information about the hierarchical repository structure, see Structure of the hierarchical repo.
Unstructured is the recommended format for most users. In addition, namespace repositories must use the unstructured repository format.
Supported features for unstructured and hierarchical repositories
The following table highlights the differences between the unstructured and hierarchical formats:
|Features||Unstructured format (recommended)||Hierarchical format|
|Used as the format for a root repository||Supported||Supported|
|Used as the format for a namespace repository||Supported||Not supported|
|Used together with Hierarchy Controller||Supported||Not recommended|
||Supported with the
||Supported with the
|Abstract namespaces||Not supported||Supported|
|Hierarchical namespaces in Hierarchy Controller||Supported||Not supported|
Add configs to your repository
If you are creating an unstructured repository, you can start adding configs to
it as soon as it's created. If you are creating a hierarchical repository, use
nomos init command to
initialize the repository, or create the directory structure manually.
Empty directories cannot be committed to a Git repository, so before you configure Config Sync, create configs and add them into your repository.
After you have created the repository and added configs to it, use the
nomos vet command to verify your
repository's structure and check syntax and validity of your configs.
Configure Config Sync to read from the repository
After you've created a repository and placed your configs into it, you can configure Config Sync to read from the repository. After you've completed this step, Config Sync syncs configs from your repository to your clusters.
You configure the location of the repository when you install Config Sync, and you can edit Config Sync's configuration later. In addition to the location of the repository, you can specify a Git branch and a subdirectory to watch, if the Git repository has contents other than configs.
If you are using a hierarchical repository, and
installing Config Sync manually with
do not place the Operator's config in the
directory, or any of the other reserved directories such as
namespaces/. Placing the config in one of the reserved directories causes
nomos vet to fail and logs an error such as
or KNV1039: IllegalKindInClusterError.
You can grant people access to a given product team's deployment repository. However, when you grant a person access to a deployment repository, that person is also granted the same RBAC as the reconciler running for that repository.
To configure authentication and authorization between Config Sync and
the repository, see the installation step about
Ignore object mutations
If you don't want Config Sync to maintain the state of the object in the
cluster after it exists, you can add the
client.lifecycle.config.k8s.io/mutation: ignore annotation to the object that
you want Config Sync to ignore mutations in. To use the annotation, you need
to enable syncing from multiple repositories and use a version of 1.7.0 or
later. Syncing from multiple repositories is enabled by default if you used the
Google Cloud console or the Google Cloud CLI to install Config Sync with a
version of 1.7.0 or later. If you installed Config Sync using
true in your ConfigManagement object.
The following example shows you how to add the annotation to an object:
metadata: annotations: client.lifecycle.config.k8s.io/mutation: ignore
You cannot manually modify this annotation on managed objects in the cluster.