This page shows you how to safely break one root repository into two or more root repositories. The steps can also be applied to namespace repositories.
A repository synced by Config Sync refers to the combination of a Git repository, a branch, a revision, and a directory.
When there are a large number of resources, for example more than 5000, in your root repository, Config Sync might not behave well for the following two reasons:
- The ResourceGroup object might exceed the etcd object size limit. The ResourceGroup object records the Group, Kind, Namespace, and Name of all the resources in the Git repository. Having a large number of resources leads to a large ResourceGroup object.
- It takes a longer time to sync all of the resources than a repository with a smaller number of resources. Config Sync applies the resources sequentially to the cluster. Sometimes the resources can't be applied successfully the first time, and Config Sync has to retry applying them.
When you encounter these issues, you can break up your root repository from one into multiple so that each root repository has fewer resources.
Break up an unstructured root repository
RootSync objects are used to explain the steps. The steps can also be applied to the RepoSync objects.
Assume that your root repository is synced by the object RootSync root-sync
.
After breaking it up, you have two root repositories. One is synced by the
RootSync object root-sync
while the other is synced by the
RootSync object root-split
.
To break up the repository, follow these steps:
In your existing root repository, choose the resources that you plan to move to a different repository or a directory and add the annotation
configmanagement.gke.io/managed: disabled
to them. This annotation ensures that the existing objects in the cluster are not affected when you move their configuration from one repository to another repository. If you use the Kustomize format or helm charts, you can choose about half of the bases and add the common annotation to thekustomization.yaml
file, such as in this example:# kustomization.yaml commonAnnotations: configmanagement.gke.io/managed: disabled
Commit and push the change:
git commit -am 'disable Config Sync management on subset of the configuration'
Wait for the existing RootSync object
root-sync
to be synced by using thegcloud alpha anthos config sync repo describe
command:# gcloud command gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \ --sync-namespace config-management-system --sync-name root-sync
Replace
MEMBERSHIP_NAME
with the membership name of your registered cluster.Set up your second repository by following these steps:
- Create a new repository or a new directory in your existing Git repository.
- Copy the resources with annotation
configmanagement.gke.io/managed: disabled
into the new repository or new directory. - Remove the annotation
configmanagement.gke.io/managed: disabled
in the new repository or directory. - If you are splitting up your root repository into more than 2 repositories, repeat these steps as necessary.
Commit and push the change:
git commit -am 'add configuration for the new root repository'
Apply a RootSync object
root-split
to sync the new repository or directory so that the existing objects in the cluster will be managed by the new RootSync objectroot-split
.apiVersion: configsync.gke.io/v1beta1 kind: RootSync metadata: name: root-split namespace: config-management-system spec: sourceFormat: unstructured git: repo: NEW_ROOT_REPOSITORY revision: NEW_ROOT_REVISION branch: NEW_ROOT_BRANCH dir: "NEW_ROOT_DIRECTORY" auth: ROOT_AUTH_TYPE gcpServiceAccountEmail: ROOT_EMAIL # secretRef should be omitted if the auth type is none, gcenode, or gcpserviceaccount. secretRef: name: git-creds
Replace the following:
NEW_ROOT_REPOSITORY
: the URL of the Git repository to use as the new root repository. You can enter URLs using either the HTTPS or SSH protocol. For example,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
uses the HTTPS protocol. If you don't enter a protocol, the URL is treated as an HTTPS URL.NEW_ROOT_REVISION
: (Optional) add the Git revision (tag or hash) of the new root repository to check out.NEW_ROOT_BRANCH
: (Optional) add the branch of the new root repository to sync from.NEW_ROOT_DIRECTORY
: (Optional) add the path in the Git repository to the new root directory that contains the configuration that you want to sync to.ROOT_AUTH_TYPE
: This should be the same as the existing RootSync/root-sync object.ROOT_EMAIL
: This should be the same as the existing RootSync/root-sync object.
Wait for the new RootSync object
root-split
to be synced. This can be done by using thegcloud alpha anthos config sync repo describe
command:$ gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \ --sync-namespace config-management-system --sync-name root-split
Replace
MEMBERSHIP_NAME
with the membership name of your registered cluster. root repository is synced to.Remove the resources with annotation
configmanagement.gke.io/managed: disabled
from the original repository. Commit and push the change:git commit -am 'remove configuration managed by the new root repository'
Wait for the existing RootSync object
root-sync
to be synced using thegcloud
command:$ gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \ --sync-namespace config-management-system --sync-name root-sync
Replace
MEMBERSHIP_NAME
with the membership name of your registered cluster.
Break up a hierarchical root repository
The steps to break up a hierarchical repository are similar to the steps of breaking up an unstructured repository.
There are three major differences:
The new root repository (or new directory) should also be hierarchical. You need to copy the existing directory
system/
andclusterregistry/
directories into the new root repository (or the new directory).The resources in a namespace cannot spread throughout multiple repositories. Otherwise, different reconcilers fight to manage the namespace.
The RootSync object
root-split
should usespec.sourceFormat: hierarchical
.
Since we recommend unstructured repositories, you might also consider converting your hierarchical repository to an unstructured repository before you break it up.