[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\u003cp\u003eConfig Connector API quota limits can be managed by increasing the reconciliation interval, splitting resources across multiple projects, or switching to namespaced mode.\u003c/p\u003e\n"],["\u003cp\u003eIncreasing the reconciliation interval involves adjusting the time between resource reconciliations to avoid frequent API requests, and setting it to 1 hour is recommended.\u003c/p\u003e\n"],["\u003cp\u003eSplitting resources into multiple projects helps to distribute API requests, but requires deleting and recreating resources, potentially causing data loss.\u003c/p\u003e\n"],["\u003cp\u003eSwitching to namespaced mode lets users use different IAM service accounts for different namespaces, which mitigates API quota limits by separating resources into namespaces.\u003c/p\u003e\n"],["\u003cp\u003eManaging node pools in GKE clusters with \u003ccode\u003eContainerNodePool\u003c/code\u003e is recommended over updating \u003ccode\u003enodeConfig\u003c/code\u003e in \u003ccode\u003eContainerCluster\u003c/code\u003e, due to the immutability of certain fields, and \u003ccode\u003ecnrm.cloud.google.com/state-into-spec: absent\u003c/code\u003e should be specified for both \u003ccode\u003eContainerCluster\u003c/code\u003e and \u003ccode\u003eContainerNodePool\u003c/code\u003e to prevent errors.\u003c/p\u003e\n"]]],[],null,["# Best practices for Config Connector\n===================================\n\n*** ** * ** ***\n\nThis page explains best practices you should consider when using\nConfig Connector.\n\nManage API quota limits\n-----------------------\n\nIf you've run into errors indicating that you've exceeded the API quota limit,\nit could be that you have created too many Config Connector resources of the\nsame Kind under the same [quota project](https://cloud.google.com/docs/quota).\nWhen you create a lot of resources, those resources can generate too many API\nrequests to the same API endpoint because of the\n[reconciliation strategy](/config-connector/docs/concepts/reconciliation)\nthat Config Connector uses.\n\nOne way to resolve this issue is to request a quota increase. Besides a quota\nincrease, if you've confirmed that the quota error is caused by GET requests\nagainst the Google Cloud resources managed by your Config Connector\nresources, you might consider one of the following options:\n\n- [Increase the reconciliation interval](#quota-reconcile) for your Config Connector resources\n- [Split your resources](#quota-split) into multiple projects\n- [Switch Config Connector to namespaced mode](#quota-namespaced)\n\n### Increase the reconciliation interval\n\nYou can increase the time between Config Connector reconciling a resource to\navoid hitting API quotas. The recommendation is to set the reconciliation\ninterval to 1 hour.\n\nTo increase the reconciliation interval, follow the steps in\n[Configuring the reconciliation interval](/config-connector/docs/concepts/reconciliation#configuring_the_reconciliation_interval).\n\n### Split your resources into multiple projects\n\nThis approach spreads out your Config Connector resources across different\nprojects. This approach works well when adding new resources, but it can be\nrisky to split existing resources because you need to delete the existing\nresources and recreate them under different projects. Deleting resources can\ncause data loss with some types of resources, such as `SpannerInstance` or\n`BigtableTable` resources. You should backup your data before deleting it.\n\nTo split existing Config Connector resources into different projects, complete\nthe following steps:\n\n1. Decide which Config Connector resources you plan to move to different projects.\n2. [Delete the Config Connector resources](/config-connector/docs/how-to/managing-deleting-resources#deleting_the_dataset). Make sure the `cnrm.cloud.google.com/deletion-policy` annotation is not set to `abandon`.\n3. Update the `spec.projectRef` field or `cnrm.cloud.google.com/project-id` annotation in the YAML configuration of the Config Connector resources you plan to move to the new projects.\n4. Grant the IAM service account used by Config Connector proper permissions on the new projects.\n5. Apply the updated YAML configuration to [create the Config Connector resources](/config-connector/docs/how-to/managing-deleting-resources#creating_a_resource).\n\n### Switch to namespaced mode\n\n| **Note:** If you want to use `requestProjectPolicy` and `billingProject` in `ConfigConnectorContext` to specify the quota project, you don't need to use IAM service accounts owned by different Google Cloud projects, but you should use different Google Cloud projects as `billingProject` for different `ConfigConnectorContext` objects to mitigate the API quota limit issue.\n\nYou can bind different IAM service accounts owned by different\nGoogle Cloud projects to different namespaces where Config Connector is\ninstalled in\n[namespaced mode](/config-connector/docs/concepts/installation-types#namespaced),\nand split your resources into different namespaces. To achieve this,\ncomplete the following steps:\n\n1. [Configure Config Connector to run in namespaced mode](/config-connector/docs/how-to/advanced-install#configure_to_run_in_namespaced_mode).\n Create new IAM service accounts from different projects, and\n bind them to different namespaces following the\n [instructions to configure Config Connector for each project](/config-connector/docs/how-to/advanced-install#project-namespace).\n\n2. Grant the new IAM service accounts proper permissions to\n the project that contains the resources.\n\n3. Decide which Config Connector resources you plan to move to different\n namespaces.\n\n4. Update the YAML configuration of the Config Connector resources and set the\n `cnrm.cloud.google.com/deletion-policy` annotation `abandon`.\n\n5. Apply the updated YAML configuration to update the Config Connector\n resources' deletion policy.\n\n6. [Abandon the Config Connector resources](/config-connector/docs/how-to/managing-deleting-resources#deleting_the_dataset).\n\n7. Update the `metadata.namespace` field in the YAML configuration of the\n Config Connector resources you plan to move to the different namespaces.\n\n8. Apply the updated YAML configuration to\n [acquire the abandoned resources](/config-connector/docs/how-to/managing-deleting-resources#acquiring_an_existing_resource).\n\nManage node pools in GKE clusters\n---------------------------------\n\nYou might experience errors when you create a cluster by applying a\n`ContainerCluster` resource in Config Connector, and then attempt to update the\n`nodeConfig` or other node-related fields by applying an updated\n`ContainerCluster` configuration. These errors are due to immutible fields such\nas `nodeConfig`, `nodeConfig.labels`, `nodeConfig.taint`, which is a technical\nlimitation of the underlying\n[Google Cloud API](/config-connector/docs/reference/resource-docs/container/containercluster).\n\nIf you need to update these fields, you can use the\n[`ContainerNodePool`](/config-connector/docs/reference/resource-docs/container/containernodepool)\nresource to manage node pools where these fields are not immutable. To manage\nnode pools using the `ContainerNodePool` resource, you must specify an\nannotation `cnrm.cloud.google.com/remove-default-node-pool: \"true\"`. This\nannotation removes the default node pool that gets created during cluster\ncreation. Then, to create separate node pools, specify `nodeConfig` fields in\n`ContainerNodePool` instead of in `ContainerCluster`. See the\n[`ContainerNodePool` resource example](/config-connector/docs/reference/resource-docs/container/containernodepool#basic_node_pool)\nfor reference.\n\nYou should set the annotation\n[`cnrm.cloud.google.com/state-into-spec: absent`](/config-connector/docs/concepts/ignore-unspecified-fields)\nfor both the `ContainerCluster` and `ContainerNodePool` resources. This\nannotation avoids potential reconciliation errors during the interaction between\nthe Config Connector controller and the underlying APIs.\n\nThe following examples show a `ContainerCluster` and a `ContainerNodePool`\nconfiguration with these annotations set: \n\n```\napiVersion: container.cnrm.cloud.google.com/v1beta1\nkind: ContainerCluster\nmetadata:\n name: containercluster-sample\n annotations:\n cnrm.cloud.google.com/remove-default-node-pool: \"true\"\n cnrm.cloud.google.com/state-into-spec: absent\nspec:\n description: A sample cluster.\n location: us-west1\n initialNodeCount: 1\n``` \n\n```\napiVersion: container.cnrm.cloud.google.com/v1beta1\nkind: ContainerNodePool\nmetadata:\n labels:\n label-one: \"value-one\"\n name: containernodepool-sample\n annotations:\n cnrm.cloud.google.com/state-into-spec: absent\nspec:\n location: us-west1\n autoscaling:\n minNodeCount: 1\n maxNodeCount: 3\n nodeConfig:\n machineType: n1-standard-1\n preemptible: false\n oauthScopes:\n - \"https://www.googleapis.com/auth/logging.write\"\n - \"https://www.googleapis.com/auth/monitoring\"\n clusterRef:\n name: containercluster-sample\n```"]]