[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-01 (世界標準時間)。"],[],[],null,["# Migrate Config Controller resources\n\nThis page shows you how to migrate\n[Config Connector resources](/config-connector/docs/reference/overview) from one\nConfig Controller cluster to another. You might need to migrate a resource\nif your primary Config Controller cluster fails and needs to be replaced, or\nyou need to change an immutable cluster configuration.\n\nThis page uses the following terminology:\n\n- **Source cluster**: The cluster that contains the Config Connector resources that you need to migrate.\n- **Destination cluster**: The cluster that you are going to migrate resources to.\n\nRecommendations\n---------------\n\n- Before you make changes in production, complete these steps in a test environment.\n- If you need to migrate multiple Config Controller clusters, migrate each one separately starting with the least critical cluster.\n- If the Config Sync cluster syncs from more than one source of truth, migrate all resources from each source at once.\n\nMigration steps for various scenarios\n-------------------------------------\n\n| **Caution:** [Some Config Connector resources can't be migrated](/config-connector/docs/how-to/managing-deleting-resources#resources_that_cannot_be_acquired) because they don't have support for acquiring existing Google Cloud resources.\n\n### Migrate all resources\n\nTo migrate all resources, complete the following steps:\n\n1. Create the destination cluster.\n\n2. Stop pushing changes to the source of truth that the source cluster is\n configured to sync from. Config Sync should continue to sync from the\n source of truth. Only changes that the source cluster syncs\n from should be stopped.\n\n3. Ensure that any recent changes to the source of truth have synced in the\n cluster and all resources are up to date in the source cluster.\n\n If there are errors for some resources, you might need to analyze the\n resources individually. If a resource has not yet been created due to an\n error, it's later created using the Config Connector running in the destination\n cluster. These errors can usually be ignored. However, for most errors, the\n root causes should be found and fixed before attempting migration.\n4. Set up Config Sync in the destination cluster to read from the same\n source of truth that the source cluster is configured from. If multiple syncs are\n set up to synchronize from more than one source of truth, then do this for each\n sync.\n\n5. Use the `nomos status` command to ensure that the destination cluster has\n synced all resources from the source of truth.\n\n6. Once the resources are synced, remove the\n [RootSync or RepoSync](/anthos-config-management/docs/reference/rootsync-reposync-fields)\n from the source cluster.\n\n7. Once each source of truth has been migrated, delete the source\n Config Controller cluster.\n\n | **Note:** Config Connector doesn't delete any resources when the Config Controller cluster is deleted. This means that if the Config Controller cluster is deleted, there is no need to set `cnrm.cloud.google.com/deletion-policy: abandon` on individual resources before deleting the cluster.\n\n### Migrate some resources\n\nTo migrate some resources, complete the following steps:\n\n1. Complete steps 1-6 from the preceding\n [Migrate all resources section](#migrate-all).\n\n2. Annotate the resources that should be migrated to the destination cluster\n with the `cnrm.cloud.google.com/deletion-policy: abandon` annotation. This\n annotation prevents Config Connector from deleting the underlying resources when\n the Config Connector resource is deleted from the Config Controller cluster.\n\n3. Delete the resources that have been marked as abandoned from the source\n cluster. This deletion only works if these resources are removed from the\n source of truth as well before resuming Config Sync.\n\n4. Move these resources to a different source of truth or a different folder\n within the same source of truth.\n\n5. Set up the destination cluster to sync from the location that you moved the\n resources to. The destination cluster can now acquire these resources and\n start managing them.\n\n### Migrate individual resources\n\nWhen a Config Controller cluster cannot be deleted (for example, when only\nmigrating a subset of resources to a different cluster) you can delete\nindividual resources. To delete individual resources, disable Config Sync\nand then set the annotation `cnrm.cloud.google.com/deletion-policy: abandon` on\nthe individual resources that you need to delete.\n\n### Migrate resources that have a service generated `resourceID`\n\nFor resources where the `resourceID` field has not been explicitly provided, the\n`resourceID` doesn't need to be specified for resource acquisition by another\nConfig Connector instance. However, there are\n[resources that have a service-generated resource ID](/config-connector/docs/how-to/managing-deleting-resources#service-generated-resource-id)\nwhich need additional steps. Even though the `resourceID` is service generated,\nit needs to be provided to acquire these resources from another Config Connector\ninstance. For these resources, the `resourceID`s should be added to the source\nof truth before trying to acquire resources from the destination cluster.\n\n### Migrate resources using conflict prevention policy\n\nBy default, the\n[conflict prevention policy](/config-connector/docs/concepts/managing-conflicts#modifying_conflict_prevention)\nis turned off for resources. You can enable it on a resource by setting the\nfollowing annotation:\n\n`cnrm.cloud.google.com/management-conflict-prevention-policy: \"resource\"`\n\nOnce set, Config Connector has to acquire a lease on the underlying resource before\nmaking any changes to it. This means that the destination cluster is not able to\nacquire the lease immediately since the lease is held by Config Connector in the\nsource cluster. The lease is granted for 40 minutes. However, after 20 minutes\nConfig Connector proactively tries to renew the lease. Because of this behavior, if\nConfig Connector in the source cluster is healthy and running, the destination\ncluster is not able to acquire the lease. The source cluster needs to release\nits lease before the destination cluster can acquire it. This can be\naccomplished either by deleting the source cluster, or by deleting the resource\nin the source cluster.\n| **Caution:** The Config Connector resource needs to be marked as abandoned before you delete it in the source cluster. Otherwise, the actual resource is deleted if it's deleted from the cluster. For instructions on how to safely accomplish this task, see [migrate only some resources](#migrate-some).\n\nOnce the source cluster has released the lease, the destination cluster is able\nto acquire the lease. The destination cluster can acquire the lease after at\nmost 40 minutes and can start managing the resources. No changes should be made\nto the Config Connector resources until the lease has been acquired by the\ndestination cluster.\n\nWhat's next\n-----------\n\n- [Troubleshoot Config Controller](/kubernetes-engine/enterprise/config-controller/docs/troubleshoot).\n- [Manual failover to a second Config Controller instance](/kubernetes-engine/enterprise/config-controller/docs/availability#second-config-controller-manual-failover).\n- [Managing resources with the `resourceID` field](/config-connector/docs/how-to/managing-resources-with-resource-ids).\n- [Stop and resume syncing configs](/kubernetes-engine/enterprise/config-sync/docs/how-to/stopping-resuming-syncing)."]]