既存のクラスタ オブジェクトの管理

Config Sync はクラスタ オブジェクトを管理する際に、オブジェクトとそのオブジェクトに適用されるリポジトリ内の一連の構成を監視し、オブジェクトと構成が同期していることを確認します。このトピックでは、既存のオブジェクトの管理を開始する方法と、現在管理対象となっているオブジェクトを削除せずに管理を停止する方法を説明します。

概要

クラスタ内のオブジェクトに configmanagement.gke.io/managed: enabled アノテーションと、オブジェクトのグループ、種類、Namespace、名前情報を追跡する configsync.gke.io/resource-id アノテーションがある場合、このオブジェクトは Config Sync によって管理されます。

Namespace スコープ オブジェクトの場合、configsync.gke.io/resource-id アノテーションの形式は GROUP_KIND_NAMESPACE_NAME です。クラスタ スコープ オブジェクトの場合は GROUP_KIND_NAME です。

次のフローチャートは、オブジェクトがマネージドまたは非マネージドになるいくつかの状況を示しています。

Kubernetes オブジェクトを Config Sync の管理対象または管理対象外にする方法

このチャートには、3 つの異なるフローが示されています。具体的には、オブジェクトの管理を開始するフロー、オブジェクトの管理を停止するフロー、管理対象のオブジェクトを削除するフローです。

  1. オブジェクトを管理する必要があります。オブジェクトの構成はリポジトリ内にありますか?
    • いいえ: オブジェクトの構成を作成します。Config Sync が configmanagement.gke.io/managed: enabled アノテーションを設定し、オブジェクトと一致する configsync.gke.io/resource-id アノテーションを設定して、オブジェクトの管理を開始します。
    • はい: 構成ファイルでアノテーション configmanagement.gke.io/managed: disabled を設定していますか?
      • いいえ: オブジェクトはデフォルトで管理されます。
      • はい: 構成ファイルを編集して configmanagement.gke.io/managed: disabled アノテーションを削除します。変更がソース リポジトリに push されると、Config Sync は変更に関する通知を行い、configmanagement.gke.io/managed: enabled アノテーションと configsync.gke.io/resource-id アノテーションを適用して構成を適用します。
  2. オブジェクトの管理を停止する必要がありますが、オブジェクトは削除せずに維持する必要があります。
    • リポジトリに保管されているオブジェクトの構成を編集し、アノテーション configmanagement.gke.io/managed: disabled を設定します。構成の変更が検出されると、Config Sync はオブジェクトの管理を停止します。
  3. オブジェクトの管理を停止してオブジェクトを削除する必要があります。
    • リポからオブジェクトの構成を削除します。以前に管理されていたオブジェクトの構成ファイルを削除すると、構成ファイルが適用されるすべてのクラスタまたは Namespace から構成が削除されます。

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 は手動でリポジトリの内容をオーバーライドします。

始める前に

次の例は、クイックスタートに基づいています。次の手順を開始する前に、クラスタとリポジトリを調べる前にすべての手順を完了してください。

すべての管理対象オブジェクトを一覧表示する

特定のクラスタまたは Namespace で 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"

たとえば、次のコマンドは、Config Sync の管理対象となっている gamestore Namespace 内の RoleBinding を一覧表示します。

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

出力例: `none 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


This command lists RoleBindings in the `kube-system` namespace that are **not**
managed by Config Sync:

<pre class="devsite-click-to-copy">
kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"
</pre>

Example output:
```none
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 をインストールする前に、クラスタにすでに存在している Namespace など、既存の Kubernetes オブジェクトの構成ファイルを作成できます。ただし、オブジェクトに configmanagement.gke.io/managed: enabled アノテーションと正しい configsync.gke.io/resource-id アノテーションが付加されていない限り、この構成ファイルは無視されます。既存のオブジェクトについては、このアノテーションを手動で適用する必要があります。

特に Namespace については、Config Sync はアノテーションが付加されていない Namespace に新しいオブジェクトを作成する構成ファイルを適用し、作成されたオブジェクトに configmanagement.gke.io/managed: enabledconfigsync.gke.io/resource-id のアノテーションを適用します。ただし、アノテーションが付いていないクラスタ スコープ オブジェクトが Config Sync によって変更またはクラスタから削除されることはありません。これは、運用中の構成ファイルの操作の図で示されています。

次の例は、既存の Role オブジェクトを管理する方法を示しています。まず、Role を手動で作成してから、Config Sync での管理を開始します。

  1. myrole Role を gamestore Namespace 内に作成します。

    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 キーの下にある、namenamespace を除くすべてのフィールドを削除します。
      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. リポジトリに変更を commit します。

    5. Config Management Operator が commit を認識するまで待ちます。myrole ロールが Config Sync によって管理されていることを確認するには、kubectl describe を再度実行します。

      kubectl describe role myrole -n gamestore
      

configmanagement.gke.io/managed: enabled アノテーションは、オブジェクトが Config Sync で管理されることを示します。configsync.gke.io/resource-id アノテーションはグループ、種類、Namespace、名前の情報を追跡します。このアノテーションには、オブジェクトに最新の構成変更を加えた、リポジトリ内のパスとファイル名が示されています。さらに、commit を表す 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: 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 ロールなど)の管理を停止する方法を説明します。

  1. リポのローカル クローンに含まれる 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 commit を作成し、その commit をリポジトリに push します。

  3. Config Sync が新しい commit を認識して適用するまで待ちます。

  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. 前回の commit でリポジトリから gamestore-webstore-admin RoleBinding を削除した場合は、次の手順を実行します。

    1. git revert を使用して、最後の commit を元に戻します。

      git revert HEAD~1
      

      元に戻す操作の確認を求められます。

    2. 元に戻す commit をリポジトリに push します。

      git push
      
  2. リポジトリのローカル クローンに含まれる quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml ファイルを編集し、configmanagement.gke.io/managed: disabled アノテーションを削除します。ファイルを保存します。

  3. 変更を commit して push します。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
    ...
    

Namespace の管理を停止する

Namespace の管理は、あらゆるタイプのオブジェクトの管理を停止する場合と同じ方法で停止できます。Namespace 内の他のリソースの管理を停止するには、次の手順を行います。

  1. configmanagement.gke.io/managed:disabled アノテーションを Namespace コンフィグと同じ Namespace 内のすべての構成ファイルに追加します。

  2. 変更をリポジトリに commit して push します。演算子がリポジトリと同期するまで待ちます。

  3. リポジトリから管理対象外のリソースを削除します。

マネージド オブジェクトの構成ファイルが非マネージド Namespace ディレクトリ内にあると、リコンサイラはエラーをログに記録しますが、他の構成ファイルは引き続き正常に同期されます。

Kubernetes オブジェクトの削除を防止する

Config Sync によって管理されている Git リポジトリから Kubernetes オブジェクトを削除すると、新しい commit がクラスタに同期される際に、このオブジェクトはクラスタからも削除されます。

Git リポジトリから構成が削除される際にクラスタ オブジェクトが削除されないようにする場合は、次の手順を行います。

  1. Git リポジトリのオブジェクト構成にアノテーション client.lifecycle.config.k8s.io/deletion: detach を追加します。

  2. Git リポジトリの変更を commit して push します。

  3. 変更がクラスタに同期されるまで待ちます。

Git リポジトリ内のオブジェクトの無視

場合によっては、Config Sync による Git リポジトリ内のオブジェクトの無視が必要になることもあります。たとえば、kpt 関数の構成はクラスタには適用すべきではありません。このタイプのオブジェクトでは、config.kubernetes.io/local-config: "true" アノテーションをオブジェクトに追加できます。このアノテーションを追加すると、Config Sync は Git リポジトリから削除された場合と同様に、このオブジェクトを無視します。

次のステップ