Stay organized with collections Save and categorize content based on your preferences.

Install Config Sync

With Config Sync, you can manage Kubernetes resources by using files, called configs, that are stored in one or more Git repositories. This page shows you how to enable and configure Config Sync so that it syncs from your root repository. Config Sync is available if you use Anthos or Google Kubernetes Engine (GKE).

When you install Config Sync using the Google Cloud console or the Google Cloud CLI, the RootSync and RepoSync APIs are enabled by default. This provides you with additional features such as syncing from multiple repositories and syncing Kustomize and Helm configurations.

Before you begin

Before you install Config Sync, prepare your environment, clusters, and roles, and enable Anthos Config Management.

Prepare your local environment

Prepare your local environment by completing the following tasks:

  1. Create, or make sure you have access to, a Git repository. This is where you add the configs that Config Sync syncs to. To learn more about how to set up your configs and repository, see Add configs to Git repositories. The repository you select becomes your root repository.
  2. Install and initialize the Google Cloud CLI, which provides the gcloud, and nomos commands. If you use Cloud Shell, the Google Cloud CLI comes pre-installed.

Cluster requirements

Create, or make sure you have access to, a cluster that meets the following requirements:

Prepare your cluster

After you have created a suitable cluster, complete the following steps:

  1. If you are using Anthos Config Management for the first time, enable Anthos Config Management.

  2. Grant the required IAM roles to the user registering the cluster.

  3. If you plan to use the Google Cloud CLI to configure Config Sync, register your GKE clusters or clusters outside of Google Cloud to a fleet now. If you plan to use the Google Cloud console, register your clusters when you configure Config Sync.

Install Config Sync

In the following sections, you grant Config Sync access to your repository. After you have granted access, you configure the installation for your root repository.

Grant access to Git

Config Sync needs read-only access to your Git repository so that it can read the configs committed to the repository and apply them to your clusters.

If your repository does not require authentication for read-only access, you can continue to configure Config Sync and use none as your authentication type. For example, if you can browse the repository using a web interface without logging in, or if you can use git clone to create a clone of the repository locally without providing credentials or using saved credentials, then you do not need to authenticate. In this case, you do not need to create a Secret.

However, most users need to create credentials because read access to their repository is restricted. If credentials are required, they are stored in the git-creds Secret on each enrolled cluster (unless you are using a Google service account). The Secret must be named git-creds because this is a fixed value.

Config Sync supports the following mechanisms for authentication:

  • SSH key pair
  • cookiefile
  • Token
  • Google service account (Cloud Source Repositories only)

The mechanism that you choose depends on what your repository supports. Generally, we recommend using an SSH key pair. GitHub and Bitbucket both support using an SSH key pair. However, if you are using a repository in Cloud Source Repositories, we recommend that you use a Google service account instead as the process is simpler. If your organization hosts your repository and you don't know which authentication methods are supported, contact your administrator.

SSH key pair

An SSH key pair consists of two files, a public key and a private key. The public key typically has a .pub extension.

To use an SSH key pair, complete the following steps:

  1. Create an SSH key pair to allow Config Sync to authenticate to your Git repository. This step is necessary if you need to authenticate to the repository to clone it or read from it. Skip this step if a security administrator provides you with a key pair. You can use a single key pair for all clusters, or a key pair per cluster, depending on your security and compliance requirements.

    The following command creates a 4096-bit RSA key. Lower values are not recommended:

    ssh-keygen -t rsa -b 4096 \
-C "GIT_REPOSITORY_USERNAME" \
-N '' \
-f /path/to/KEYPAIR_FILENAME

    Replace the following:

    • GIT_REPOSITORY_USERNAME: the username that you want Config Sync to use to authenticate to the repository
    • /path/to/KEYPAIR_FILENAME: a path to the key pair

    If you are using a third-party Git repository host such as GitHub, or you want to use a service account with Cloud Source Repositories, we recommend that you use a separate account.

  2. Configure your repository to recognize the newly created public key. Refer to the documentation for your Git hosting provider. Instructions for some popular Git hosting providers are included for convenience:

  3. Add the private key to a new Secret in the cluster:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME

    Replace /path/to/KEYPAIR_PRIVATE_KEY_FILENAME with the name of the private key (the one without the .pub suffix).

  4. Delete the private key from the local disk or otherwise protect it.

  5. When you configure Config Sync and add the URL for your Git repository, use the SSH protocol. If you are using a repository in Cloud Source Repositories, you must use the following format when you enter your URL:

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME

    Replace the following:

    • EMAIL: your Google Cloud username
    • PROJECT_ID: the ID of the Google Cloud project where the repository is located
    • REPO_NAME: the name of the repository

cookiefile

The process for acquiring a cookiefile depends on the configuration of your repository. For an example, see Generate static credentials in the Cloud Source Repositories documentation. The credentials are usually stored in the .gitcookies file in your home directory, or they might be provided to you by a security administrator.

To use a cookiefile, complete the following steps:

  1. After you create and obtain the cookiefile, add it to a new Secret in the cluster.

    If you don't use an HTTPS proxy, create the Secret with the following command:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE

    If you need to use an HTTPS proxy, add it to the Secret together with cookiefile by running the following command:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    Replace the following:

    • /path/to/COOKIEFILE: the appropriate path and filename
    • HTTPS_PROXY_URL: the URL for the HTTPS proxy that you use when communicating with the Git repository

  2. Protect the contents of the cookiefile if you still need it locally. Otherwise, delete it.

Token

If your organization does not permit the use of SSH keys, you might prefer to use a token. With Config Sync, you can use GitHub's personal access tokens (PATs), GiLab's PATs or deploy keys, or Bitbucket's app password as your token.

To create a Secret using your token, complete the following steps:

  1. Create a token using GitHub, GitLab, or Bitbucket:

  2. After you create and obtain the token, add it to a new Secret in the cluster.

    If you don't use an HTTPS proxy, create the Secret with the following command:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace="config-management-system" \
  --from-literal=username=USERNAME \
  --from-literal=token=TOKEN

    Replace the following:

    • USERNAME: the username that you want to use.
    • TOKEN: the token that you created in the previous step.

    If you need to use an HTTPS proxy, add it to the Secret together with username and token by running the following command:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-literal=username=USERNAME \
  --from-literal=token=TOKEN \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    Replace the following:

    • USERNAME: the username that you want to use.
    • TOKEN: the token that you created in the previous step.
    • HTTPS_PROXY_URL: the URL for the HTTPS proxy that you use when communicating with the Git repository.

  3. Protect the token if you still need it locally. Otherwise, delete it.

Google service account

If your repository is in Cloud Source Repositories, you can give Config Sync access to a repository in the same project as your managed cluster by using a Google service account.

To use a repository in Cloud Source Repositories as your Config Sync repository, complete the following steps:

  1. Retrieve your Cloud Source Repositories URL:

    1. List all repositories:

      gcloud source repos list

    2. From the output, copy the URL from the repository that you want to use. For example:

      REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr

      You need to use this URL when you configure Config Sync in the following section. If you configure Config Sync using the Google Cloud console, you add the URL in the URL field. If you configure Config Sync using the Google Cloud CLI, you add the URL to the syncRepo field of your configuration file.

  2. When you configure Config Sync, select the appropriate authentication type. The authentication type that you should pick differs depending on what type of cluster you have and how you have enabled Workload Identity.

    • Workload Identity enabled: Use this method if you have GKE Workload Identity enabled or if you're using fleet Workload Identity. If you're using fleet Workload Identity, then you can use this authentication method for both GKE and non-GKE clusters.

      Config Sync uses fleet Workload Identity by default if the cluster is registered in a fleet. Make sure that fleet Workload Identity is enabled on your registered clusters. For more information, see Register a cluster. If your cluster is in a project different from the fleet host project, you need to bind the Google service account with the Kubernetes service account in the fleet host project.

    • Workload Identity not enabled: You can only use the method for GKE clusters.

    Workload Identity enabled

    1. If necessary, create a service account. Ensure that the service account has read access to Cloud Source Repositories by granting it the source.reader role.

    2. If you configure Config Sync using the Google Cloud console, select Workload Identity as the Authentication Type and then add your service account email.

      If you configure Config Sync using the Google Cloud CLI, add gcpserviceaccount as the secretType and then add your service account email to gcpServiceAccountEmail.

    3. After configuring Config Sync, create an IAM policy binding between the Kubernetes service account and the Google service account. The Kubernetes service account is not created until you configure Config Sync for the first time.

      If you are using clusters that are registered to a fleet, you only have to create the policy binding once per fleet. All clusters registered in a fleet share the same Workload Identity pool. With fleet's concept of sameness, if you add the IAM policy to your Kubernetes service account in one cluster, then the Kubernetes service account from the same namespace on other clusters in the same fleet also get the same IAM policy.

      This binding lets the Config Sync Kubernetes service account act as the Google service account:

      gcloud iam service-accounts add-iam-policy-binding \
   --role roles/iam.workloadIdentityUser \
   --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

      Replace the following:

      • PROJECT_ID: If you're using GKE Workload Identity, add your organization's project ID.

        If you're using fleet Workload Identity, you can use two different project IDs. In serviceAccount:PROJECT_ID, add the project ID of the fleet that your cluster is registered to. In GSA_NAME@PROJECT_ID, add a project ID for any project that has read access to the repository in Cloud Source Repositories.

      • KSA_NAME: the Kubernetes service account for the reconciler. For root repositories, if the RootSync name is root-sync, KSA_NAME is root-reconciler. Otherwise, it is root-reconciler-ROOT_SYNC_NAME.

        For namespace repositories, if the RepoSync name is repo-sync, KSA_NAME is ns-reconciler-NAMESPACE. Otherwise, it is ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

      • GSA_NAME: the custom Google service account that you want to use to connect to Cloud Source Repositories. Make sure that the Google service account that you select has the source.reader role.

    Workload Identity not enabled

    If you configure Config Sync using the Google Cloud console, select Google Cloud Repository as the Authentication Type.

    If you configure Config Sync using the Google Cloud CLI, add gcenode as the secretType.

    Selecting either Google Cloud Repository or gcenode lets you use the Compute Engine default service account. By default, the Compute Engine default service account, PROJECT_ID-compute@developer.gserviceaccount.com, has source.reader access to the repository for the same project. However, if your Cloud Source Repositories is located in a project different from your cluster's project, you have to grant default Compute Engine service account from the cluster's project, the source.reader in the Cloud Source Repositories's project.

    You can add the source.reader role with the following command:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --role roles/source.reader

    Replace the following:

    • PROJECT_ID: your organization's project ID
    • PROJECT_NUMBER: your organization's project number

    You cannot modify access scopes after you create a node pool. However, you can create a new node pool with the proper access scope while using the same cluster. The default gke-default scope does not include cloud-source-repos-ro.

Configure Config Sync

In this section, you configure the settings for your root repository. The Google Cloud console guides you through the installation process and automates many of the steps. You can also use the Google Cloud CLI to complete the installation.

When you install Config Sync using the Google Cloud console or the Google Cloud CLI, Config Sync automatically creates a RootSync object named root-sync. You can use kubectl commands to modify root-sync and add additional Config Sync configurations. To learn more, see Configure Config Sync with kubectl commands.

Console

Register your clusters

To use Config Management, you must first register your clusters. Registering your clusters lets them share a common set of configurations and policies.

To register your clusters, complete the following tasks:

  1. In the Google Cloud console:
  2. Click Install Config Sync.
  3. In the Select registered clusters for Config Management page, locate the Unregistered clusters from this project table, and find the cluster that you want to register.

  4. Click Register next to the cluster that you want to register.

    After the cluster is successfully registered, it appears in the Select registered clusters for Config Management table.

Install Config Sync

After you have registered your clusters, you can continue on to install and configure Config Sync.

To install Config Sync, complete the following steps:

  1. In the Select registered clusters for Config Management page, select the clusters that you want to configure, and click Next.

  2. If you want to install Policy Controller, leave the Enable Policy Controller checkbox selected and click Next.

  3. In the Repository drop-down list, select either Use Google sample or Custom.

    Google sample

    Select Use Google sample to use the Google sample repository. This repository includes Policy Controller bundles.

    To select this option, you must install Policy Controller, install Policy Controller's constraint template library, and enable referential constraints. These Policy Controller options are enabled by default.

    Custom

    Select Custom to to use your own Git repository and then configure the following fields:

    1. In the URL field, add the URL of the Git repository to use as the source of truth. Enter URLs using either the HTTPS or SSH protocol. For example, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. If you plan to use SSH as your Authentication type, enter your URL with the SSH protocol.

    2. Click Show advanced options.

    3. In the Authentication type drop-down list, select the one of the following options:

      • None: Use no authentication.
      • SSH: Use an SSH key pair.
      • Cookiefile: Use a cookiefile.
      • Token: Use a token.
      • Google Cloud Repository: Use a Google service account to access a Cloud Source Repositories repository. Only select this option if Workload Identity is not enabled in your cluster.
      • Workload Identity: Use a Google service account to access a Cloud Source Repositories repository. You can only select Workload Identity when you use GKE clusters with Workload Identity enabled. The integration with Fleet Workload Identity for other Anthos clusters isn't supported. When you select Workload Identity, you need to add your Google service account email address. For example, acm@PROJECT_ID.iam.gserviceaccount.com. If you select this authentication type, you also need to create an IAM policy binding after you finish configuring Config Sync. For details, see the Google service account tab of the Grant Config Sync read-only access to Git section.

    4. Follow the instructions in the Google Cloud console to grant Config Sync read-only access to Git and click Continue.

    5. Optional: In the Branch field, add the branch of the repository to sync from. The default is the master branch.

    6. Optional: In the Tag/Commit field, add the Git revision (tag or hash) to check out. The default is HEAD.

    7. Optional: In the Configuration directory field, add the path of the directory to sync from, relative to the root of the Git repository. All sub-directories of the directory that you specify are included and synced to the cluster. The default value is the root directory of the repository.

    8. Optional: In the Sync wait field, add the period in seconds between consecutive syncs. The default is 15 seconds.

    9. Optional: In the Git proxy field, enter the URL for the HTTPS proxy to be used when communicating with the Git repository. This is an optional field, and if it's left blank, no proxy is used. Proxy is only supported when using an authorization type of cookiefile, none, or token.

      The URL for the HTTPS proxy is shown as plain text in the RootSync resource that Config Sync creates. If the URL contains sensitive information such as a username or password and you need to hide the sensitive information, you can leave Git proxy empty and add the URL for the HTTPS proxy into the same Secret used for the Git credential. Storing the proxy in the Secret is supported when the authorization type is cookiefile or token.

    10. Optional: From the Source format drop-down list, choose either unstructured or hierarchy. The default is unstructured and we recommend that you select unstructured as this format lets you organize your configs in the way that is most convenient to you.

    11. Optional: From the Config Management version drop-down list, select the Anthos Config Management version that you want to use. The default is the current version.

  4. To finish the installation, click Complete. You are taken back to the Config Management page.

gcloud

Before you continue, make sure you've registered your clusters to a fleet.

  1. Prepare the configuration by either creating a new apply-spec.yaml manifest or by using an existing manifest. Using an existing manifest lets you configure your cluster with the same settings used by another cluster.

Create new manifest

To configure Config Sync with new settings for your cluster, create a file named apply-spec.yaml and copy the following YAML file into it.

You can set all of the optional spec.configSync fields that you need when you create your manifest, and later use kubectl commands for configuration. You can also only set the spec.configSync.enabled field as true and omit the optional fields. You can then later use kubectl commands to create additional RootSync objects or RepoSyncs that you can fully manage using kubectl commands later.

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a Git repository or an OCI image, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

Replace the following:

  • SOURCE_TYPE: add git to sync from a Git repository. Add oci to sync from an OCI image. If no value is specified, the default is git.
  • FORMAT: add unstructured to use an unstructured repository or add hierarchy to use a hierarchical repository. These values are case-sensitive. This field is optional and the default value is hierarchy. We recommend that you add unstructured, because this format lets you organize your configs in the way that is most convenient to you.

  • REPO: add the URL of the Git repository or the OCI image to use as the source of truth. Git URLs use either the HTTPS or SSH protocol. For example, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. If you plan to use SSH as your secretType, enter your URL with the SSH protocol. This field is required and if you don't enter a protocol, the URL is treated as an HTTPS URL.

    OCI URLs use the following format: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. By default, the image is pulled from the latest tag, but you can pull in images by TAG or DIGEST instead. Specify TAG or DIGEST in the PACKAGE_NAME:

    • To pull by TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
    • To pull by DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

  • BRANCH: the branch of the repository to sync from. This field is optional and the default is master.

  • SECRET_TYPE: one of the following secretTypes:

    git

    • none: Use no authentication.
    • ssh: Use an SSH key pair.
    • cookiefile: Use a cookiefile.
    • token: Use a token.
    • gcpserviceaccount: Use a Google service account to access a Cloud Source Repositories. If you select this authentication type, you need to create an IAM policy binding after you finish configuring Config Sync. For details, see the Google service account tab of the Grant Config Sync read-only access to Git section.
    • gcenode: Use a Google service account to access a Cloud Source Repositories. Only select this option if Workload Identity is not enabled in your cluster.

    For more information on these authentication types, see Granting Config Sync read-only access to Git.

    oci

    • none: Use no authentication
    • gcenode: Use the Compute Engine default service account to access an image in Artifact Registry or Container Registry. Only select this option if Workload Identity is not enabled in your cluster.
    • gcpserviceaccount: Use a Google service account to access an image.

  • EMAIL: If you added gcpserviceaccount as your secretType, add your Google service account email address. For example, acm@PROJECT_ID.iam.gserviceaccount.com.

  • DIRECTORY: the path of the directory to sync from, relative to the root of the Git repository. All sub-directories of the directory that you specify are included and synced to the cluster. The default value is the root directory of the repository.

  • PREVENT_DRIFT: If set to true, enables the Config Sync admission webhook to prevent drifts by rejecting conflicting changes from being pushed to live clusters. The default setting is false. Config Sync always remediates drifts no matter the value of this field.

For a complete list of fields that you can add to the spec field, see gcloud fields.

Use existing manifest

To configure your cluster with the same settings used by another cluster, fetch the settings from a registered cluster:

gcloud alpha container fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH

Replace the following:

  • MEMBERSHIP_NAME: the membership name of the registered cluster that has the Config Sync settings you want to use
  • PROJECT_ID: your project ID
  • CONFIG_YAML_PATH: the path to the apply-spec.yaml file which contains the settings fetched from the cluster

2. Apply the apply-spec.yaml file. If you are using an existing manifest, you should apply the file to the cluster that you want to configure with the settings that you fetched in the previous command:

  gcloud beta container fleet config-management apply \
      --membership=MEMBERSHIP_NAME \
      --config=CONFIG_YAML_PATH \
      --project=PROJECT_ID

Replace the following:

  • MEMBERSHIP_NAME: the membership name that you chose when you registered your cluster. You can find the name with gcloud container fleet memberships list.
  • CONFIG_YAML_PATH: the path to your apply-spec.yaml file.
  • PROJECT_ID: your project ID.

After you have finished configuring your root repository, you can optionally choose to configure syncing from multiple repositories, including other root repositories and namespace repositories. The namespace repositories are helpful if you want a repository that contains namespace-scoped configs synced to a particular namespace across clusters.

Verify the installation

After you have installed and configured Config Sync, you can verify that the installation completed successfully.

Console

Complete the following steps:

  1. In the Google Cloud console:
  2. In the cluster table, view the Config sync status column. A successful installation has a status of Synced.

gcloud

Run the following command:

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

Replace PROJECT_ID with your project's ID.

A successful installation has a status of SYNCED. If you see an error after running the preceding command, make sure that you created the git-creds Secret. If you have created the Secret, try rerunning the following command:

gcloud beta container fleet config-management apply

You can also use the nomos status command to check if the Config Sync is installed successfully. A valid installation with no problems has a status of PENDING or SYNCED. An invalid or incomplete installation has a status of NOT INSTALLED OR NOT CONFIGURED. The output also includes any reported errors.

It's possible to have an invalid configuration that isn't detected right away, such as a missing or invalid git-creds Secret. For troubleshooting steps, see Valid but incorrect ConfigManagement object in the Troubleshooting page.

Upgrade Config Sync

Config Sync is upgraded whenever you upgrade Anthos Config Management. To learn more, see Upgrade Anthos Config Management.

Resource requests

Summary of total resource requests

The following tables list the combined amount of resource requests for each supported version of Config Sync, depending on what features you are using.

1.14

Feature CPU (m) Memory (Mi)
Config Sync 330 m + 80 m * (number of RootSync and RepoSync objects) 850 Mi + 600 Mi * (number of RootSync and RepoSync objects)
Config Sync with the admission webhook enabled 350 m + 80 m * (number of RootSync and RepoSync objects) 1050 Mi + 600 Mi * (number of RootSync and RepoSync objects)
Hierarchy Controller 200 m 200 Mi

1.13

Feature CPU (m) Memory (Mi)
Config Sync 330 m + 80 m * (number of RootSync and RepoSync objects) 850 Mi + 600 Mi * (number of RootSync and RepoSync objects)
Config Sync with the admission webhook enabled 350 m + 80 m * (number of RootSync and RepoSync objects) 1050 Mi + 600 Mi * (number of RootSync and RepoSync objects)
Hierarchy Controller 200 m 200 Mi

1.12

Feature CPU (m) Memory (Mi)
Config Sync 330 m + 80 m * (number of RootSync and RepoSync objects) 700 Mi + 600 Mi * (number of RootSync and RepoSync objects)
Config Sync with the admission webhook enabled 350 m + 80 m * (number of RootSync and RepoSync objects) 900 Mi + 600 Mi * (number of RootSync and RepoSync objects)
Hierarchy Controller 200 m 200 Mi

Detailed resource requests

The following table lists Kubernetes resource requirements for Config Sync components. For more information, see Managing Resources for Containers in the Kubernetes documentation.

1.14

Deployment name CPU request (m) per replica Memory request (Mi) per replica Single or multiple repositories
git-importer 450 400 Single
monitor Default1 Default Single
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (one per RootSync and RepoSync) 80 + default 600 + default Multi
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 The default resource request uses a CPU request of 10 milliCPU (mCPU) and a memory request of 10 Mi.

2 The admission webhook has two replicas, so when calculating the total resource requests, you need to double the value if you are using the admission webhook. The admission webhook is disabled by default.

1.13

Deployment name CPU request (m) per replica Memory request (Mi) per replica Single or multiple repositories
git-importer 450 400 Single
monitor Default1 Default Single
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (one per RootSync and RepoSync) 80 + default 600 + default Multi
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 The default resource request uses a CPU request of 10 milliCPU (mCPU) and a memory request of 10 Mi.

2 The admission webhook has two replicas, so when calculating the total resource requests, you need to double the value if you are using the admission webhook. The admission webhook is disabled by default.

1.12

Deployment name CPU request (m) per replica Memory request (Mi) per replica Single or multiple repositories
git-importer 450 400 Single
monitor Default1 Default Single
resource-group-controller-manager 110+default 150+default Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (one per RootSync and RepoSync) 80+default 600+default Multi
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 The default resource request uses a CPU request of 10 milliCPU (mCPU) and a memory request of 10 Mi.

2 The admission webhook has two replicas, so when calculating the total resource requests, you need to double the value if you are using the admission webhook. The admission webhook is disabled by default.

What's next