既存のクラスタ オブジェクトを管理する
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 です。
次のフローチャートは、オブジェクトがマネージドまたは非マネージドになるいくつかの状況を示しています。
このチャートには、1）オブジェクトの管理を開始するフロー、2）オブジェクトの管理を停止するフロー、3）マネージド オブジェクトを削除するフロー、の 3 つの異なるフローが示されています。
- オブジェクトの管理を開始します。オブジェクトにマニフェストはありますか。つまり、リポジトリ内にオブジェクトの構成ファイルはありますか。
- いいえ: オブジェクトの構成を作成します。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アノテーションを適用して構成を適用します。
- いいえ: オブジェクトの構成を作成します。Config Sync が
- オブジェクトの管理を停止する必要がありますが、オブジェクトは削除せずに維持する必要があります。
- リポジトリに保管されているオブジェクトの構成を編集し、アノテーション
configmanagement.gke.io/managed: disabledを設定します。構成の変更が検出されると、Config Sync はオブジェクトの管理を停止します。
- リポジトリに保管されているオブジェクトの構成を編集し、アノテーション
- オブジェクトの管理を停止してオブジェクトを削除する必要があります。
- リポからオブジェクトの構成を削除します。以前に管理されていたオブジェクトの構成ファイルを削除すると、構成ファイルが適用されるすべてのクラスタまたは 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 での管理を開始します。
myroleRole をgamestoreNamespace 内に作成します。kubectl create role -n gamestore myrole --verb=get --resource=pods
myroleロールによって付与される権限を表示します。kubectl describe role -n gamestore myrole
Name: myrole Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get]このロールには、
getPod の権限のみが含まれています。この時点で、ロールはクラスタ内に存在しますが、Config Sync には認識されていません。
- ターミナルで、リポジトリのローカル クローンに移動します。
次のコマンドを使用して、
myroleの YAML マニフェストを作成し、そのマニフェストをgamestore-myrole.yamlという名前の新しいファイルに保存します。kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
gamestore-myrole.yamlファイルを編集します。metadataキーの下にある、nameとnamespaceを除くすべてのフィールドを削除します。rules.verbsリスト フィールド内のgetの後にlist動詞を追加します。
変更を保存します。編集後のファイルの内容は次のようになっています。
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: myrole namespace: gamestore rules: - apiGroups: - "" resources: - pods verbs: - get - listリポジトリに変更を commit します。
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 ロールなど）の管理を停止する方法を説明します。
リポのローカル クローンに含まれる
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ファイルを保存します。
変更を含む Git commit を作成し、その commit をリポジトリに push します。
Config Sync が新しい commit を認識して適用するまで待ちます。
次のコマンドを使用して、
gamestore-webstore-adminRoleBinding のアノテーションとラベルが空であることを確認します。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 の構成を削除していないことを前提としています。
前回の commit でリポジトリから
gamestore-webstore-adminRoleBinding を削除した場合は、次の手順を実行します。git revertを使用して、最後の commit を元に戻します。git revert HEAD~1元に戻す操作の確認を求められます。
元に戻す commit をリポジトリに push します。
git push
リポジトリのローカル クローンに含まれる
config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yamlファイルを編集し、configmanagement.gke.io/managed: disabledアノテーションを削除します。ファイルを保存します。変更を commit して push します。Config Sync は次の処理を行います。
- 変更を認識する
configmanagement.gke.io/managed: enabledアノテーションとconfigsync.gke.io/resource-idアノテーションを適用します。これでオブジェクトが管理対象になります。- あらゆる管理対象オブジェクトと同じく、構成を適用します。
オブジェクトが管理対象になったことを確認するには、オブジェクトのアノテーションを一覧表示します。
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 内の他のリソースの管理を停止するには、次の手順を行います。
configmanagement.gke.io/managed:disabledアノテーションを Namespace コンフィグと同じ Namespace 内のすべての構成ファイルに追加します。変更をリポジトリに commit して push します。演算子がリポジトリと同期するまで待ちます。
リポジトリから管理対象外のリソースを削除します。
マネージド オブジェクトの構成ファイルが非マネージド Namespace ディレクトリ内にあると、リコンサイラはエラーをログに記録しますが、他の構成ファイルは引き続き正常に同期されます。
Kubernetes オブジェクトの削除を防止する
Config Sync によって管理されている Git リポジトリから Kubernetes オブジェクトを削除すると、新しい commit がクラスタに同期される際に、このオブジェクトはクラスタからも削除されます。
Git リポジトリから構成が削除される際に Config Sync によってクラスタ オブジェクトが削除されないようにする場合は、次の手順を行います。
Git リポジトリのオブジェクト構成にアノテーション
client.lifecycle.config.k8s.io/deletion: detachを追加します。Git リポジトリの変更を commit して push します。
変更がクラスタに同期されるまで待ちます。
これらの手順を完了した後、Git リポジトリから構成が削除されても、Config Sync はクラスタからこのオブジェクトを削除しませんが、他のクライアントによって削除される可能性はあります。
Git リポジトリ内のオブジェクトを無視する
場合によっては、Config Sync による Git リポジトリ内のオブジェクトの無視が必要になることもあります。たとえば、kpt 関数の構成はクラスタには適用すべきではありません。このタイプのオブジェクトでは、config.kubernetes.io/local-config: "true" アノテーションをオブジェクトに追加できます。このアノテーションを追加すると、Config Sync は Git リポジトリから削除された場合と同様に、このオブジェクトを無視します。