이 페이지에서는 구성 컨트롤러 클러스터 하나에서 다른 구성 컨트롤러 클러스터로 구성 커넥터 리소스를 마이그레이션하는 방법을 설명합니다. 기본 구성 컨트롤러 클러스터가 실패하여 바꿔야 하는 경우 또는 변경할 수 없는 클러스터 구성을 변경해야 하는 경우에는 리소스를 마이그레이션해야 할 수 있습니다.
이 페이지에서는 다음 용어를 사용합니다.
소스 클러스터: 마이그레이션해야 하는 구성 커넥터 리소스가 포함된 클러스터입니다.
대상 클러스터: 리소스를 마이그레이션할 클러스터입니다.
추천
프로덕션 환경에서 변경하기 전에 테스트 환경에서 다음 단계를 완료합니다.
구성 컨트롤러 클러스터를 여러 개 마이그레이션해야 하는 경우 중요도가 가장 낮은 클러스터부터 개별적으로 마이그레이션합니다.
구성 동기화 클러스터가 둘 이상의 정보 소스로부터 동기화되는 경우 각 소스의 모든 리소스를 한 번에 마이그레이션합니다.
여러 시나리오의 마이그레이션 단계
모든 리소스 마이그레이션
모든 리소스를 마이그레이션하려면 다음 단계를 완료합니다.
대상 클러스터를 만듭니다.
소스 클러스터가 동기화되도록 구성된 정보 소스에 대한 변경사항 게시를 중지합니다. 구성 동기화는 정보 소스에서 동기화를 계속 수행합니다. 소스 클러스터가 동기화되는 변경사항만 중지해야 합니다.
정보 소스에 대한 최근 변경사항이 클러스터에서 동기화되었고 모든 리소스가 소스 클러스터에서 최신 상태인지 확인합니다.
일부 리소스에 오류가 있으면 리소스를 개별적으로 분석해야 할 수 있습니다. 오류로 인해 리소스가 아직 생성되지 않았으면 나중에 대상 클러스터에서 실행 중인 구성 커넥터를 통해 생성됩니다. 이러한 오류는 일반적으로 무시해도 됩니다. 그러나 대부분의 오류에서는 마이그레이션을 시도하기 전에 근본 원인을 찾고 수정해야 합니다.
소스 클러스터가 구성된 동일한 정보 소스에서 읽도록 대상 클러스터에 구성 동기화를 설정합니다. 여러 동기화가 둘 이상의 정보 소스에서 동기화하도록 설정된 경우 동기화마다 이 작업을 수행합니다.
nomos status 명령어를 사용하여 대상 클러스터가 정보 소스의 모든 리소스와 동기화되었는지 확인합니다.
대상 클러스터로 마이그레이션해야 하는 리소스에 cnrm.cloud.google.com/deletion-policy: abandon 주석을 표시합니다. 이 주석은 구성 컨트롤러 클러스터에서 구성 커넥터 리소스가 삭제될 때 구성 커넥터에서 기본 리소스를 삭제하지 않도록 합니다.
소스 클러스터에서 폐기된 것으로 표시된 리소스를 삭제합니다. 이 삭제는 구성 동기화를 다시 시작하기 전에 정보 소스에서 이러한 리소스가 삭제된 경우에만 작동합니다.
다른 정보 소스 또는 동일한 정보 소스 내의 다른 폴더로 이러한 리소스를 이동합니다.
리소스를 이동한 위치에서 동기화할 대상 클러스터를 설정합니다. 이제 대상 클러스터가 이러한 리소스를 가져와서 관리할 수 있습니다.
개별 리소스 마이그레이션
구성 컨트롤러 클러스터를 삭제할 수 없는 경우(예: 리소스의 하위 집합을 다른 클러스터로만 마이그레이션하는 경우)에 개별 리소스를 삭제할 수 있습니다. 개별 리소스를 삭제하려면 구성 동기화를 중지한 후 삭제해야 하는 개별 리소스에 cnrm.cloud.google.com/deletion-policy: abandon 주석을 설정합니다.
서비스로 생성된 resourceID가 있는 리소스 마이그레이션
resourceID 필드가 명시적으로 제공되지 않은 리소스의 경우 다른 구성 커넥터 인스턴스에서 리소스를 가져오기 위해 resourceID를 지정하지 않아도 됩니다. 하지만 추가 단계가 필요한 서비스로 생성된 리소스 ID가 있는 리소스가 있습니다. resourceID가 서비스로 생성되더라도 다른 구성 커넥터 인스턴스에서 이러한 리소스를 가져오려면 제공해야 합니다. 이러한 리소스의 경우 대상 클러스터에서 리소스를 가져오려고 하기 전 정보 소스에 resourceID를 추가해야 합니다.
충돌 방지 정책을 사용하여 리소스 마이그레이션
기본적으로 리소스에는 충돌 방지 정책이 중지되어 있습니다. 다음 주석을 설정하여 리소스에서 사용 설정할 수 있습니다.
한번 설정된 다음에는 구성 커넥터가 기본 리소스에 대해 임대를 획득해야만 이를 변경할 수 있습니다. 즉, 임대가 소스 클러스터의 구성 커넥터에 있으므로 대상 클러스터가 임대를 즉시 획득할 수 없습니다. 40분 동안 임대가 부여됩니다. 하지만 20분 후에는 구성 커넥터에서 임대 갱신을 사전에 시도합니다. 이 동작으로 인해 소스 클러스터의 구성 커넥터가 정상이고 실행 중이면 대상 클러스터에서 임대를 획득할 수 없습니다. 대상 클러스터에서 임대를 획득하려면 먼저 소스 클러스터가 임대를 해제해야 합니다. 이렇게 하려면 소스 클러스터를 삭제하거나 소스 클러스터에서 리소스를 삭제하면 됩니다.
소스 클러스터에서 임대를 해제하면 대상 클러스터가 임대를 획득할 수 있습니다. 대상 클러스터는 최대 40분 후에 임대를 획득하고 리소스를 관리할 수 있습니다. 대상 클러스터에서 임대를 획득할 때까지 구성 커넥터 리소스를 변경할 수 없습니다.
[[["이해하기 쉬움","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(UTC)"],[],[],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)."]]
