구성 동기화는 자가 복구, 주기적 재동기화, 선택적 드리프트 방지를 통해 '그림자 작업' 위험을 줄여줍니다. 구성 동기화에서 클러스터와 정보 소스 간의 드리프트를 감지하면 이를 허용하고 빠르게 되돌리거나 완전히 거부할 수 있습니다.
자가 복구는 관리형 리소스를 감시하고 정보 소스에서 드리프트를 감지하며 이러한 드리프트를 되돌립니다. 자가 복구는 항상 사용 설정되어 있습니다.
주기적 재동기화는 정보 소스에 변경사항이 없더라도 마지막 동기화가 성공한지 후 1시간 후에 자동으로 동기화됩니다. 주기적 재동기화는 항상 사용 설정되어 있습니다.
자가 복구 및 주기적 재동기화는 드리프트를 해결하는 데 도움이 되지만 드리프트 방지는 관리형 객체 변경 요청을 가로채고 변경이 허용되는지 여부를 검증합니다. 변경사항이 정보 소스와 일치하지 않으면 변경이 거부됩니다. 드리프트 방지는 기본적으로 중지되어 있습니다. 사용 설정된 경우 드리프트 방지는 기본적으로 RootSync 객체를 보호하며 RepoSync 객체를 보호하도록 구성할 수도 있습니다.
Google Cloud Console 또는 gcloud CLI를 사용하여 구성 동기화를 설치한 경우 gcloud CLI를 사용해서 드리프트 방지를 사용 설정합니다.
최신 버전으로 gcloud CLI를 업데이트해야 합니다.
gcloud 구성 파일의 spec.configSync.preventDrift 필드를 true로 설정한 후 gcloud 구성 파일을 적용합니다.
kubectl
kubectl을 사용하여 구성 동기화를 수동으로 설치한 경우 kubectl을 사용하여 드리프트 방지를 사용 설정합니다.
ConfigManagement 객체의 spec.preventDrift 필드를 true로 설정한 후 ConfigManagement 객체를 적용합니다.
ConfigManagement Operator에서 구성 동기화 ValidateWebhookConfiguration 객체를 만들 때까지 기다립니다.
NAME WEBHOOKS AGE
admission-webhook.configsync.gke.io 0 2m15s
root-reconciler 배포가 웹훅을 구성 동기화 ValidatingWebhookConfiguration 객체에 추가할 수 있도록 새 변경사항을 동기화할 정보 소스에 커밋합니다. 다른 방법은 root-reconcilier 배포를 삭제하여 조정을 트리거하는 것입니다. 새 root-reconciler 배포는 구성 동기화 ValidatingWebhookConfiguration 객체를 업데이트합니다.
웹훅 서버가 준비될 때까지 기다립니다. 구성 동기화 허용 웹훅 배포 로그에는 serving webhook server가 포함되어야 합니다. 몇 분 정도 걸릴 수 있습니다.
Google Cloud Console 또는 gcloud CLI를 사용하여 구성 동기화를 설치한 경우 gcloud CLI를 사용해서 드리프트 방지를 사용 중지합니다.
최신 버전으로 gcloud CLI를 업데이트해야 합니다.
gcloud 구성 파일의 spec.configSync.preventDrift 필드를 false로 설정하거나 필드를 삭제한 후 gcloud 구성 파일을 적용합니다.
kubectl
kubectl을 사용하여 구성 동기화를 수동으로 설치한 경우 kubectl을 사용하여 드리프트 방지를 중지합니다.
ConfigManagement 객체의 spec.preventDrift 필드를 false로 설정하거나 필드를 삭제한 후 ConfigManagement 객체를 적용합니다.
모든 구성 동기화 허용 웹훅 리소스가 삭제됩니다.
구성 동기화 ValidatingWebhookConfiguration 객체가 더 이상 존재하지 않으므로 구성 동기화 조정자는 더 이상 관리형 리소스의 웹훅 구성을 생성하지 않습니다.
네임스페이스 범위의 소스에서 허용 웹훅 사용 설정
네임스페이스 범위의 정보 소스는 웹훅에서 완벽하게 보호되지 않습니다. 각 네임스페이스 소스의 구성 동기화 조정자는 클러스터 수준에서 ValidatingWebhookConfiguration 객체를 읽거나 업데이트할 권한이 없습니다.
이러한 권한이 없으면 다음 예시와 유사하게 네임스페이스 조정자 로그에 대한 오류가 발생합니다.
Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope
네임스페이스 범위의 정보 소스에 대해 웹훅 보호를 사용하지 않으려면 이 오류를 무시해도 됩니다. 하지만 웹훅을 사용하려면 둘 이상의 정보 소스에서 동기화를 구성한 후 각 네임스페이스 범위의 정보 소스의 조정자에게 권한을 부여합니다.
ns-reconciler-NAMESPACE의 RoleBinding에 이미 ClusterRole cluster-admin 권한이 있는 경우 이 단계를 수행할 필요가 없습니다.
루트 정보 소스에서 구성 동기화 허용 웹훅에 권한을 부여하는 새 ClusterRole 구성을 선언합니다. 이 ClusterRole은 클러스터당 한 번만 정의하면 됩니다.
RootSync 또는 RepoSync 객체를 삭제하면 기본적으로 구성 동기화는 해당 RootSync 또는 RepoSync 객체에서 이전에 관리했던 리소스를 수정하지 않습니다. 이로 인해 구성 동기화가 이러한 리소스 객체를 추적하는 데 사용하는 여러 라벨과 주석 남을 수 있습니다. 드리프트 보호가 사용 설정된 경우 이전에 관리형 리소스에 대한 변경사항이 거부될 수 있습니다.
삭제 전파를 사용하지 않은 경우 남은 리소스 객체가 구성 동기화에서 추가한 라벨과 주석을 계속 보존할 수 있습니다.
이러한 관리형 리소스를 유지하려면 정보 소스에 선언된 모든 관리형 리소스에서 configmanagement.gke.io/managed 주석을 disabled로 설정하여 RootSync 또는 RepoSync 객체를 삭제하기 전에 해당 리소스를 관리 해제합니다. 이렇게 하면 구성 동기화에 이러한 리소스를 삭제하지 않고 관리형 리소스에서 라벨 및 주석을 삭제하도록 지시합니다. 동기화가 완료되면 RootSync 또는 RepoSync 객체를 삭제할 수 있습니다.
이러한 관리형 리소스를 삭제하려면 다음 두 가지 옵션이 있습니다.
정보 소스에서 관리형 리소스를 삭제합니다. 그런 다음 구성 동기화가 클러스터에서 관리형 객체를 삭제합니다. 동기화가 완료되면 RootSync 또는 RepoSync 객체를 삭제할 수 있습니다.
RootSync 또는 RepoSync 객체를 삭제하기 전에 이 객체에 삭제 전파를 사용 설정하세요. 그런 다음 구성 동기화가 클러스터에서 관리형 객체를 삭제합니다.
관리형 리소스를 관리 해제하거나 삭제하기 전에 RootSync 또는 RepoSync 객체가 삭제되면 RootSync 또는 RepoSync 객체를 다시 만들 수 있으며 정보 소스와 일치하는 클러스터에서 리소스를 채택합니다. 그런 다음 리소스를 관리 해제하거나 삭제하고 변경사항이 동기화될 때까지 기다린 후 RootSync 또는 RepoSync 객체를 다시 삭제할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-11-22(UTC)"],[],[],null,["# Prevent config drift\n\nConfig Sync reduces the risk of \"shadow ops\" through automatic self-healing,\nperiodic re-sync, and optional drift prevention. When Config Sync detects\ndrift between the cluster and the , it can either be allowed\nand quickly reverted or completely rejected.\n\nSelf-healing watches managed resources, detects drift from the source of truth,\nand reverts that drift. Self-healing is always enabled.\n\nPeriodic re-sync automatically syncs an hour after the last successful sync,\neven if no change has been made to the source of truth. Periodic re-sync is\nalways enabled.\n\nWhile self-healing and periodic re-syncs help remediate drift, drift prevention\nintercepts requests to change managed objects and validates whether the change\nshould be allowed. If the change doesn't match the , the\nchange is rejected. Drift prevention is disabled by default. When enabled, drift\nprevention protects `RootSync` objects by default, and can also be configured to protect\n`RepoSync` objects.\n\nTo use drift prevention, you must enable the\n[`RootSync` and `RepoSync` APIs](/kubernetes-engine/enterprise/config-sync/docs/reference/rootsync-reposync-fields).\n| **Note:** All of these features use [server-side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/), which means they only prevent or revert changes to fields explicitly specified in the source of truth. Unspecified fields are allowed to drift. This is required because many Kubernetes controllers update metadata and spec fields at runtime, not just status fields.\n\nEnable drift prevention\n-----------------------\n\n1. If you used the Google Cloud console or gcloud CLI to install Config Sync, enable drift prevention by using gcloud CLI.\n Make sure to [update your gcloud CLI](/sdk/gcloud/reference/components/update)\n to the latest version.\n Set the `spec.configSync.preventDrift` field of the gcloud\n config file to `true`, and then apply the gcloud config file.\n\n2. Wait until the Config Sync `ValidateWebhookConfiguration` object is created\n by the ConfigManagement Operator:\n\n kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io\n\n You should see output similar to the following example: \n\n NAME WEBHOOKS AGE\n admission-webhook.configsync.gke.io 0 2m15s\n\n3. Commit a new change to the source of truth to be synced so that the\n `root-reconciler` Deployment can add webhooks into the Config Sync\n ValidatingWebhookConfiguration object. An alternative is to delete the\n `root-reconcilier` Deployment to trigger a reconciliation. The new `root-reconciler` Deployment\n would update the Config Sync ValidatingWebhookConfiguration object.\n\n4. Wait until the webhook server is ready. The Config Sync admission webhook\n Deployment log should include `serving webhook server`. This can take several minutes.\n\n kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep \"serving webhook server\"\n\n You should see output similar to the following example: \n\n I1201 18:05:41.805531 1 deleg.go:130] controller-runtime/webhook \"level\"=0 \"msg\"=\"serving webhook server\" \"host\"=\"\" \"port\"=10250\n I1201 18:07:04.626199 1 deleg.go:130] controller-runtime/webhook \"level\"=0 \"msg\"=\"serving webhook server\" \"host\"=\"\" \"port\"=10250\n\nDisable drift prevention\n------------------------\n\nDisable drift prevention using gcloud CLI if you installed Config Sync using the Google Cloud console or gcloud CLI.\nMake sure to [update your gcloud CLI](/sdk/gcloud/reference/components/update)\nto the latest version.\nSet the `spec.configSync.preventDrift` field of the gcloud\nconfig file to `false` or remove the field, and then apply the\ngcloud config file.\n\nThis deletes all the Config Sync admission webhook resources.\nSince the Config Sync `ValidatingWebhookConfiguration` object no longer exists,\nthe Config Sync reconcilers no longer generate the webhook configs for\nmanaged resources.\n\nEnable the admission webhook in namespace-scoped sources\n--------------------------------------------------------\n\nNamespace-scoped sources of truth are not fully protected by the webhook. The\nConfig Sync reconciler for each namespace source does not have permission to\nread or update the `ValidatingWebhookConfiguration` objects at the cluster level.\n\nThis lack of permission results in an error for the namespace reconcilers logs\nsimilar to the following example: \n\n Failed to update admission webhook: KNV2013: applying changes to\n admission webhook: Insufficient permission. To fix, make sure the reconciler has\n sufficient permissions.:\n validatingwebhookconfigurations.admissionregistration.k8s.io \"admission-\n webhook.configsync.gke.io\" is forbidden: User \"system:serviceaccount:config-\n management-system:ns-reconciler-NAMESPACE\" cannot update resource\n \"validatingwebhookconfigurations\" in API group \"admissionregistration.k8s.io\" at\n the cluster scope\n\nYou can ignore this error if you don't want to use the webhook protection for your\nnamespace-scoped source of truth. However, if you want to use the webhook, grant\npermission to the reconciler for each namespace-scoped source of truth after you have\n[configured syncing from more than one source of truth](/kubernetes-engine/enterprise/config-sync/docs/how-to/multiple-repositories).\nYou might not need to perform these steps if a RoleBinding for the\n`ns-reconciler-NAMESPACE` already exists with ClusterRole `cluster-admin` permissions.\n| **Caution:** Giving permission to read or update the ValidatingWebhookConfiguration objects to a namespace-scoped source of truth means that the namespace-scoped source owners can make changes to the Config Sync admission webhook configs in the cluster.\n\n1. In the root source of truth, declare a new ClusterRole configuration that grants\n permission to the Config Sync admission webhook. This ClusterRole only\n needs to be defined once per cluster:\n\n # ROOT_SOURCE/cluster-roles/webhook-role.yaml\n apiVersion: rbac.authorization.k8s.io/v1\n kind: ClusterRole\n metadata:\n name: admission-webhook-role\n rules:\n - apiGroups: [\"admissionregistration.k8s.io\"]\n resources: [\"validatingwebhookconfigurations\"]\n resourceNames: [\"admission-webhook.configsync.gke.io\"]\n verbs: [\"get\", \"update\"]\n\n2. For each namespace-scoped source where the admission webhook permission needs\n to be granted, declare a ClusterRoleBinding configuration to grant access\n to the admission webhook:\n\n # ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml\n kind: ClusterRoleBinding\n apiVersion: rbac.authorization.k8s.io/v1\n metadata:\n name: syncs-webhook\n subjects:\n - kind: ServiceAccount\n name: ns-reconciler-\u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e\n namespace: config-management-system\n roleRef:\n kind: ClusterRole\n name: admission-webhook-role\n apiGroup: rbac.authorization.k8s.io\n\n Replace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e with the namespace that you\n created your namespace-scoped source in.\n3. Commit the changes to the root source of truth, for example, if syncing from a\n Git repository:\n\n git add .\n git commit -m 'Providing namespace repository the permission to update the admission webhook.'\n git push\n\n4. To verify, use `kubectl get` to make sure the ClusterRole and\n ClusterRoleBinding have been created:\n\n kubectl get clusterrole admission-webhook-role\n kubectl get clusterrolebindings syncs-webhook\n\nDisable drift prevention for abandoned resources\n------------------------------------------------\n\n| **Note:** Starting in version 1.21.0, Config Sync drift prevention doesn't reject changes to abandoned resources. This section only applies to versions earlier than 1.21.0.\n\nWhen you delete a `RootSync` or `RepoSync` object, by default Config Sync doesn't\nmodify the resources previously managed by that `RootSync` or `RepoSync` object. This can\nleave behind several [labels and\nannotations](/kubernetes-engine/enterprise/config-sync/docs/reference/labels-and-annotations) that\nConfig Sync uses to track these resource objects. If drift protection is\nenabled, this can cause any changes to the previously managed resources to be\nrejected.\n\nIf you didn't use [deletion\npropagation](/kubernetes-engine/enterprise/config-sync/docs/how-to/managing-objects#bulk_delete_objects), the\nresource objects left behind might still retain labels and annotations added by\nConfig Sync.\n\nIf you want to keep these managed resources, unmanage these resources before\ndeleting the `RootSync` or `RepoSync` objects by setting the\n`configmanagement.gke.io/managed` annotation to `disabled` on every managed\nresource declared in the source of truth. This tells Config Sync to remove\nits labels and annotations from the managed resources, without deleting these\nresources. After the sync is complete, you can remove the `RootSync` or `RepoSync`\nobject.\n\nIf you want to delete these managed resources, you have two options:\n\n- Delete the managed resources from the source of truth. Then, Config Sync will delete the managed objects from the cluster. After the sync is complete, you can remove the `RootSync` or `RepoSync` object.\n- Enable deletion propagation on the `RootSync` or `RepoSync` object before deleting it. Then, Config Sync will delete the managed objects from the cluster.\n\nIf the `RootSync` or `RepoSync` object is deleted before unmanaging or deleting its\nmanaged resources, you can recreate the `RootSync` or `RepoSync` object, and it\nadopts the resources on the cluster that match the source of truth. Then you can\nunmanage or delete the resources, wait for the changes to sync, and delete the\n`RootSync` or `RepoSync` object again.\n\nWhat's next\n-----------\n\n- Learn how to [troubleshoot the webhook](/kubernetes-engine/enterprise/config-sync/docs/troubleshooting/webhook)."]]
