避免設定偏移

Config Sync 透過自動自我修復、定期重新同步處理和選用的漂移防護功能，降低「影子作業」的風險。當 Config Sync 偵測到叢集與可靠來源之間有差異時，可以允許並快速還原，也可以完全拒絕。

自我修復功能會監控代管資源、偵測與可靠資料來源的差異，並還原該差異。自我修復功能一律會啟用。

定期重新同步會在上次成功同步後一小時自動執行， 即使資料來源沒有任何變更，系統也會執行這項作業。系統一律會啟用定期重新同步功能。

雖然自我修復和定期重新同步有助於修正漂移，但漂移防護功能會攔截變更受管理物件的要求，並驗證是否應允許變更。如果變更與可靠來源不符，系統會拒絕變更。預設為停用漂移防護功能。啟用後，系統預設會保護 RootSync 物件，您也可以設定保護 RepoSync 物件。

如要使用防止偏移功能，必須啟用 RootSync 和 RepoSync API。

啟用漂移防護功能

1. 將設定檔中的 preventDrift 欄位設為 true，然後套用設定檔：

   gcloud

   如果使用 Google Cloud 控制台或 gcloud CLI 安裝 Config Sync，請使用 gcloud CLI 啟用防止偏移功能。 請務必將 gcloud CLI 更新至最新版本。將 gcloud 設定檔的 spec.configSync.preventDrift 欄位設為 true，然後套用 gcloud 設定檔。

   kubectl (1.19.2 或更早版本)

   如果您使用 kubectl 手動安裝 Config Sync，請使用 kubectl 啟用偏移防護功能。 將 ConfigManagement 物件的 spec.preventDrift 欄位設為 true，然後套用 ConfigManagement 物件。

2. 等待 ConfigManagement Operator 建立 Config Sync ValidateWebhookConfiguration 物件：

   kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io
   

   您會看到類似以下範例的輸出內容：

   NAME                                  WEBHOOKS   AGE
   admission-webhook.configsync.gke.io   0          2m15s
   

3. 將要同步處理的新變更提交至單一事實來源，以便 root-reconciler Deployment 將 Webhook 新增至 Config Sync ValidatingWebhookConfiguration 物件。另一種做法是刪除 root-reconcilier Deployment，觸發協調程序。新的 root-reconciler Deployment 會更新 Config Sync ValidatingWebhookConfiguration 物件。

4. 等待 Webhook 伺服器準備就緒。Config Sync 許可控制 Webhook 部署記錄應包含 serving webhook server。這可能需要幾分鐘的時間。

   kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"
   

   您會看到類似以下範例的輸出內容：

   I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
   I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
   

停用偏移防護功能

這會刪除所有 Config Sync 許可控制 Webhook 資源。 由於 Config Sync ValidatingWebhookConfiguration 物件已不存在，Config Sync 調解器不會再為受管理資源產生 Webhook 設定。

在命名空間範圍來源中啟用准入 Webhook

Webhook 無法完全保護命名空間範圍內的單一事實來源。每個命名空間來源的 Config Sync 調解器無權讀取或更新叢集層級的 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

如果您不想為命名空間範圍的單一事實來源使用 Webhook 保護機制，可以忽略這項錯誤。不過，如果您想使用 Webhook，請在設定從多個單一資料來源同步處理資料後，為每個命名空間範圍的單一資料來源授予協調器權限。 如果 ns-reconciler-NAMESPACE 的 RoleBinding 已具備 ClusterRole cluster-admin 權限，您可能不需要執行這些步驟。

1. 在根可靠來源中，宣告新的 ClusterRole 設定，授予 Config Sync 准入 Webhook 權限。每個叢集只需定義一次這個 ClusterRole：

   # ROOT_SOURCE/cluster-roles/webhook-role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: admission-webhook-role
   rules:
   - apiGroups: ["admissionregistration.k8s.io"]
     resources: ["validatingwebhookconfigurations"]
     resourceNames: ["admission-webhook.configsync.gke.io"]
     verbs: ["get", "update"]
   

2. 針對每個需要授予許可的命名空間範圍來源，請宣告 ClusterRoleBinding 設定，授予許可給准入 Webhook：

   # ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
   kind: ClusterRoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-webhook
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-NAMESPACE
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: admission-webhook-role
     apiGroup: rbac.authorization.k8s.io
   

   將 NAMESPACE 替換為您在其中建立命名空間範圍來源的命名空間。

3. 將變更提交至根資料來源，例如從 Git 存放區同步處理時：

   git add .
   git commit -m 'Providing namespace repository the permission to update the admission webhook.'
   git push
   
   

4. 如要驗證，請使用 kubectl get 確保已建立 ClusterRole 和 ClusterRoleBinding：

   kubectl get clusterrole admission-webhook-role
   kubectl get clusterrolebindings syncs-webhook
   

針對已捨棄的資源停用漂移防範功能

刪除 RootSync 或 RepoSync 物件時，Config Sync 預設不會修改先前由該 RootSync 或 RepoSync 物件管理的資源。這可能會留下多個 標籤和註解，Config Sync 會使用這些標籤和註解追蹤資源物件。如果啟用偏差防護功能，系統可能會拒絕先前管理資源的任何變更。

如果您未使用刪除傳播，留下的資源物件可能仍會保留 Config Sync 新增的標籤和註解。

如要保留這些受管理資源，請先取消管理這些資源，再刪除 RootSync 或 RepoSync 物件。方法是在真實來源中宣告的每個受管理資源上，將 configmanagement.gke.io/managed 註解設為 disabled。這會指示 Config Sync 從受管理資源中移除標籤和註解，但不會刪除這些資源。同步完成後，即可移除 RootSync 或 RepoSync 物件。

如要刪除這些受管理資源，有兩種做法：

• 從單一事實來源刪除受管理資源。接著，Config Sync 會從叢集刪除受管理物件。同步完成後，即可移除 RootSync 或 RepoSync 物件。
• 刪除 RootSync 或 RepoSync 物件前，請先啟用刪除作業傳播功能。接著，Config Sync 會從叢集刪除受管理物件。

如果 RootSync 或 RepoSync 物件在取消管理或刪除受管理資源前遭到刪除，您可以重新建立 RootSync 或 RepoSync 物件，該物件會採用叢集上與真實現狀來源相符的資源。接著，您可以取消管理或刪除資源、等待變更同步處理，然後再次刪除 RootSync 或 RepoSync 物件。

後續步驟

• 瞭解如何排解 Webhook 問題。