Break up a repository into multiple repositories

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:

  1. 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.
  2. 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:

  1. 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 the kustomization.yaml file, such as in this example:

    # kustomization.yaml
commonAnnotations:
  configmanagement.gke.io/managed: disabled

  2. Commit and push the change: git commit -am 'disable Config Sync management on subset of the configuration'

  3. Wait for the existing RootSync object root-sync to be synced by using the gcloud 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.

  4. Set up your second repository by following these steps:

    1. Create a new repository or a new directory in your existing Git repository.
    2. Copy the resources with annotation configmanagement.gke.io/managed: disabled into the new repository or new directory.
    3. Remove the annotation configmanagement.gke.io/managed: disabled in the new repository or directory.
    4. If you are splitting up your root repository into more than 2 repositories, repeat these steps as necessary.

  5. Commit and push the change:

    git commit -am 'add configuration for the new root repository'

  6. 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 object root-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.

  7. Wait for the new RootSync object root-split to be synced. This can be done by using the gcloud 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.

  8. 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'

  9. Wait for the existing RootSync object root-sync to be synced using the 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.

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:

  1. The new root repository (or new directory) should also be hierarchical. You need to copy the existing directory system/ and clusterregistry/ directories into the new root repository (or the new directory).

  2. The resources in a namespace cannot spread throughout multiple repositories. Otherwise, different reconcilers fight to manage the namespace.

  3. The RootSync object root-split should use spec.sourceFormat: hierarchical.

Since we recommend unstructured repositories, you might also consider converting your hierarchical repository to an unstructured repository before you break it up.