管理現有叢集物件

當 Config Sync 管理叢集物件時，會監控該物件和存放區中影響該物件的一組設定，並確保兩者同步。本主題說明如何開始管理現有物件，以及如何停止管理目前管理的物件，而不刪除該物件。

如果叢集中的物件具有 configmanagement.gke.io/managed: enabled 註解，且 configsync.gke.io/resource-id 註解 (追蹤物件的群組、種類、命名空間和名稱資訊) 正確無誤，則該物件會由 Config Sync 管理。

configsync.gke.io/resource-id 註解的格式為命名空間範圍物件的 GROUP_KIND_NAMESPACE_NAME，以及叢集範圍物件的 GROUP_KIND_NAME。

下圖說明導致物件成為受管理或不受管理狀態的部分情況：

圖表包含三個不同的流程：1) 開始管理物件、2) 停止管理物件，以及 3) 刪除受管理物件。

1. 我要開始管理物件，物件是否含有資訊清單？換句話說，物件在存放區中是否有設定？
   • 否：為物件建立設定。Config Sync 會設定 configmanagement.gke.io/managed: enabled 註解，並將 configsync.gke.io/resource-id 註解設為與物件相符，然後開始管理物件。
   • 是：設定是否設定下列註解？ configmanagement.gke.io/managed: disabled
     • 否：物件預設由系統管理。
     • 是：編輯設定，移除 configmanagement.gke.io/managed: disabled 註解。變更推送至來源存放區後，Config Sync 會注意到變更，並套用註解 configmanagement.gke.io/managed: enabled 和 configsync.gke.io/resource-id，然後套用設定。
2. 我想停止管理物件，但不想刪除物件。
   • 編輯存放區中物件的設定，並設定註解 configmanagement.gke.io/managed: disabled。偵測到設定變更時，Config Sync 會停止管理物件。
3. 我想停止管理物件並刪除物件。
   • 從存放區刪除物件的設定。刪除先前管理的物件設定時，Config Sync 會從設定套用的所有叢集或命名空間中刪除該物件。

除了 configmanagement.gke.io/managed: enabled 註解和 configsync.gke.io/resource-id 註解，Config Sync 還會將 app.kubernetes.io/managed-by: configmanagement.gke.io 標籤套用至管理的所有物件。有了這個標籤，您就能輕鬆列出Config Sync 的所有物件。

為什麼不手動套用註解？

Config Sync 會從存放區讀取所需設定，並使用陳述式模型將設定變更套用至叢集。如果您嘗試手動套用註解 (使用 kubectl 指令或 Kubernetes API)，Config Sync 會自動以存放區內容覆寫手動註解。

事前準備

以下範例以「開始使用 Config Sync」為基礎。開始執行下列步驟前，請先按照快速入門導覽課程完成所有步驟，然後探索及測試 Config Sync 安裝作業。

列出所有受管理物件

如要列出特定叢集或命名空間中由 Config Sync 管理的所有物件，請使用下列標籤選取器：

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

如要列出 Config Sync 未管理的物件，請使用類似下列的標籤選取器：

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

舉例來說，下列指令會列出 gamestore 命名空間中由 Config Sync 管理的 RoleBinding：

kubectl get rolebindings -n gamestore \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

輸出結果會與下列內容相似：

NAME                              ROLE                                          AGE
configsync.gke.io:ns-reconciler   ClusterRole/configsync.gke.io:ns-reconciler   34h
gamestore-admin                   ClusterRole/admin                             34h
gamestore-webstore-admin          ClusterRole/webstore-admin                    34h

這個指令會列出 kube-system 命名空間中未由 Config Sync 管理的 RoleBinding：

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

輸出結果會與下列內容相似：

NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

開始管理現有物件

在安裝 Config Sync 之前，您可以為叢集中現有的 Kubernetes 物件 (例如命名空間) 建立設定。不過，除非物件具有 configmanagement.gke.io/managed: enabled 註解和正確的 configsync.gke.io/resource-id 註解，否則系統會忽略這項設定。您必須為現有物件手動套用該註解。

尤其是命名空間，Config Sync 會套用的設定，會在沒有註解的命名空間中建立新物件，並套用 configmanagement.gke.io/managed: enabled 和 configsync.gke.io/resource-id 註解。不過，Config Sync 拒絕修改或移除叢集中任何沒有註解的叢集範圍物件。請參閱「隨時間變化的設定使用結果」一文中的圖表。

以下範例說明如何管理現有的 Role 物件。 首先，您需要手動建立角色，然後開始使用 Config Sync 管理角色。

1. 在 gamestore 命名空間中建立 myrole Role：

   kubectl create role -n gamestore myrole --verb=get --resource=pods

2. 查看「myrole」角色授予的權限：

   kubectl describe role -n gamestore myrole

   Name:         myrole
   Labels:       <none>
   Annotations:  <none>
   PolicyRule:
     Resources  Non-Resource URLs  Resource Names  Verbs
     ---------  -----------------  --------------  -----
     pods       []                 []              [get]
   

   這個角色只能 get Pod。

3. 此時，角色存在於叢集中，但 Config Sync 並不知道。

   1. 使用終端機前往存放區的本機副本。

   2. 請使用下列指令建立 myrole 的 YAML 資訊清單，並將資訊清單儲存至名為 gamestore-myrole.yaml 的新檔案。

      kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
      

   3. 編輯 gamestore-myrole.yaml 檔案。

      1. 移除 metadata 鍵底下的所有欄位，但 name 和 namespace 除外。
      2. 在 rules.verbs 清單欄位的 get 後方新增 list 動詞。

      儲存變更。產生的檔案包含下列內容：

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. 將變更提交至存放區。

   5. 請稍待片刻，讓 ConfigManagement Operator 注意到提交內容。如要確認 myrole Role 現在由 Config Sync 管理，請再次執行 kubectl describe。

      kubectl describe role myrole -n gamestore
      

請注意註解 configmanagement.gke.io/managed: enabled，這表示物件是由 Config Sync 管理，以及註解 configsync.gke.io/resource-id，這會追蹤群組、種類、命名空間和名稱資訊。此外，請注意註解，這些註解會顯示存放區中導致物件最近一次設定變更的路徑和檔案名稱，以及代表提交的 Git 雜湊。

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

停止管理受管理的物件

這個範例說明如何停止管理 Config Sync 目前管理的物件，例如開始管理現有物件中的 myrole Role。

1. 在存放區的本機副本中編輯 config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml 檔案，然後新增與下方粗體文字相符的 annotations: 區段：

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      annotations:
        configmanagement.gke.io/managed: disabled
      name: gamestore-webstore-admin
      namespace: gamestore
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-gamestore
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: webstore-admin
      apiGroup: rbac.authorization.k8s.io
   

   儲存檔案。

2. 使用變更建立 Git 修訂版本，並將該版本推送至存放區。

3. 稍待片刻，Config Sync 就會注意到並套用新的提交內容。

4. 使用下列指令驗證 gamestore-webstore-admin RoleBinding 的註解和標籤是否都為空白。Config Sync 不會將物件上的 configmanagement.gke.io/managed 註解設為 disabled。

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml
   

   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     annotations:
     name: gamestore-webstore-admin
     namespace: gamestore
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-gamestore
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: webstore-admin
     apiGroup: rbac.authorization.k8s.io
   

確認物件已停用後，您可以從存放區移除設定，並驗證系統是否未從命名空間刪除現在未受管理的物件。如要再次管理物件，請務必將其設定加回存放區。因此，您可能會想取消管理物件，並將其設定保留在存放區中。

現在物件不受管理，因此不會在新叢集或現有叢集上建立或重新建立，即使存在也不會移除。如要繼續管理先前停止管理的物件，請參閱下一個範例「繼續管理先前未受管理的物件」。

繼續管理先前未受管理的物件

本例說明如何繼續管理先前從管理中移除的物件，如「停止管理現有物件」一文所述。並假設您未移除 gamestore-webstore-admin RoleBinding 的設定。

1. 如果您在上次提交時從存放區刪除 gamestore-webstore-admin RoleBinding，請按照下列步驟操作。

   1. 使用 git revert 還原上次的提交：

      git revert HEAD~1
      

      系統會要求您確認還原作業。

   2. 將還原的修訂版本推送到存放區。

      git push
      

2. 在存放區的本機副本中編輯 config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml 檔案，然後移除 configmanagement.gke.io/managed: disabled 註解。儲存檔案。

3. 修訂並推送變更。Config Sync 會執行下列操作：

   • 注意到變更
   • 套用 configmanagement.gke.io/managed: enabled 註解和 configsync.gke.io/resource-id 註解，物件現在由系統管理。
   • 套用設定，就像處理任何受管理物件一樣。

4. 如要確認物件現在是否受管理，請列出其註解：

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       configmanagement.gke.io/cluster-name: my-cluster
       configmanagement.gke.io/managed: enabled
       configsync.gke.io/resource-id: rbac.authorization.k8s.io_rolebinding_gamestore_gamestore-webstore-admin
   ...
   

停止管理命名空間

停止管理命名空間的方式，與停止管理任何類型的物件相同。如要停止管理命名空間中的其他資源，請按照下列步驟操作：

1. 在命名空間設定和同一個命名空間中的所有設定中，新增 configmanagement.gke.io/managed:disabled 註解。命名空間中的所有物件都必須有這項註解。

2. 修訂並推送存放區的變更。等待 Operator 與存放區同步。

3. 從存放區中刪除未受管理的資源。

如果受管理設定的設定位於未受管理的命名空間目錄中，協調器會記錄錯誤，但其他設定會繼續正常同步。

刪除代管資源

從單一資訊來源移除資源後，當 Config Sync 下次從該來源同步處理時，該物件就會從叢集中刪除。或者，您也可以啟用刪除傳播功能，一次刪除多個物件。

刪除個別物件

根據 Config Sync 的預設行為，從可靠來源移除物件後，Config Sync 從該來源同步處理時，系統會從叢集刪除該物件。

您可以透過多種方式查看 Config Sync 狀態或特定物件的狀態：

• 使用 nomos status。
• 使用 kubectl 檢查資源。
• 使用 Config Sync 資訊主頁。

大量刪除物件

根據預設，刪除 RootSync 或 RepoSync 會導致 Config Sync 捨棄先前從可靠來源套用的物件。或者，您也可以啟用刪除傳播功能，刪除所有先前套用的物件。

在 RootSync 或 RepoSync 物件上啟用刪除傳播功能，然後刪除該物件時，Config Sync 會自動刪除由該 RootSync 或 RepoSync 管理的所有物件。

刪除傳播功能可協助您更輕鬆地清除資源，例如遷移至新命名空間或叢集、在示範或實驗後清除資源，或是解除安裝應用程式。

刪除傳播選項

刪除傳播功能預設為停用。如要啟用刪除作業傳播，請將 configsync.gke.io/deletion-propagation-policy: Foreground 註解新增至 RootSync 或 RepoSync 物件，如下列範例所示：

# example-rootsync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: example-rootsync
  namespace: config-management-system
  annotations:
    configsync.gke.io/deletion-propagation-policy: Foreground
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

或者，您也可以執行下列指令，更新現有的 RootSync 或 RepoSync，以使用刪除傳播功能：

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

如要停用刪除傳播功能，請移除註解或將值變更為 configsync.gke.io/deletion-propagation-policy: Orphan：

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

傳播物件刪除作業

這個範例說明如何將刪除傳播套用至 RootSync 或 RepoSync 物件，然後刪除 RootSync 或 RepoSync，藉此刪除 RootSync 或 RepoSync 管理的所有物件。

防止刪除 Kubernetes 物件

從 Config Sync 管理的 Git 存放區移除 Kubernetes 物件後，當新修訂版本同步至叢集時，該物件也會從叢集刪除。

如要防止 Config Sync 在從 Git 存放區移除物件設定時刪除該物件，請按照下列步驟操作：

1. 在 Git 存放區的物件設定中新增 client.lifecycle.config.k8s.io/deletion: detach 註解。

2. 在 Git 存放區中修訂並推送變更。

3. 等待變更同步至叢集。

完成這些步驟後，當物件的設定從 Git 存放區中移除時，Config Sync 不會從叢集中刪除該物件，但其他用戶端仍可刪除該物件。

忽略可靠資料來源中的物件

您可能希望 Config Sync 忽略可靠資料來源中的物件。舉例來說，kpt 函式設定絕不應套用至叢集。

如要讓 Config Sync 忽略物件，請在物件中加入 config.kubernetes.io/local-config: "true" 註解。新增這項註解後，Config Sync 會忽略這個物件，就像從可靠來源中移除一樣。如果資源的 local-config 註解設為 "false" 以外的值，系統會視為設為 "true" 並忽略該資源。