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

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 です。

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

このチャートには、3 つの異なるフローが示されています。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 アノテーションを削除します。変更がソース リポジトリに 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 は手動でリポジトリの内容をオーバーライドします。

始める前に

次の例は、Config Sync のスタートガイドに基づいています。次の手順を行う前に、クイックスタートに従い、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"

出力は次のようになります。

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

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

特に Namespace については、Config Sync はアノテーションが付加されていない Namespace に新しいオブジェクトを作成する構成ファイルを適用し、作成されたオブジェクトに configmanagement.gke.io/managed: enabled と configsync.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 キーの下にある、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. リポジトリに変更を 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: 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 ロールなど）の管理を停止する方法を説明します。

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 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. リポジトリのローカル クローンに含まれる config-sync-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 内のすべての構成ファイルに追加します。 このアノテーションは、Namespace 内のすべてのオブジェクトに付ける必要があります。

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

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

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

マネージド リソースを削除する

信頼できる情報源から個々のリソースを削除すると、Config Sync が信頼できる情報源から次に同期するときにそのオブジェクトがクラスタから削除されます。または、削除の伝播を有効にして、オブジェクトを一括削除することもできます。

個々のオブジェクトを削除する

Config Sync のデフォルトの動作では、信頼できる情報源からオブジェクトを削除すると、Config Sync が信頼できる情報源から同期するときにそのオブジェクトがクラスタから削除されます。

Config Sync のステータスや特定のオブジェクトのステータスを確認するにはさまざまな方法があります。

• nomos status を使用します。
• kubectl を使用してリソースを調べる。
• gcloud alpha anthos config sync resources コマンドを使用する。
• Config Sync ダッシュボードを使用する

オブジェクトを一括削除する

デフォルトでは、RootSync または RepoSync を削除すると、Config Sync は信頼できる情報源から以前に適用されたオブジェクトを破棄します。または、削除の伝播を有効にして、以前に適用されたすべてのオブジェクトを削除することもできます。

RootSync オブジェクトまたは RepoSync オブジェクトで削除の伝播を有効にしてそのオブジェクトを削除すると、ConfigSync はその RootSync または RepoSync で管理されていたオブジェクトをすべて自動的に削除します。

削除の伝播を使用すると、新しい名前空間やクラスタに移行する場合、デモやテストの後にクリーンアップする場合、アプリケーションのアンインストールを行う場合などに、リソースを容易にクリーンアップできます。

削除の伝播オプション

削除の伝播はデフォルトで無効になっています。削除の伝播を有効にするには、次の例のように RootSync または RepoSync のオブジェクトに configsync.gke.io/deletion-propagation-policy: Foreground アノテーションを追加します。

# 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: init
    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 オブジェクトを削除すると、新しい commit がクラスタに同期される際に、このオブジェクトはクラスタからも削除されます。

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

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

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

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

これらの手順を完了した後、Git リポジトリから構成が削除されても、Config Sync はクラスタからこのオブジェクトを削除しませんが、他のクライアントによって削除される可能性はあります。

信頼できる情報源のオブジェクトを無視する

Config Sync による信頼できる情報源のオブジェクトの無視が必要になることもあります。たとえば、kpt 関数の構成はクラスタには適用すべきではありません。

Config Sync で無視するオブジェクトの場合は、config.kubernetes.io/local-config: "true" アノテーションをオブジェクトに追加します。このアノテーションを追加すると、Config Sync はこのオブジェクトが信頼できる情報源から削除されたかのように無視します。local-config アノテーションが "false" 以外の値に設定されているリソースは、"true" に設定されているものとして扱われ、無視されます。