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 はオブジェクトの管理を停止します。
- リポジトリに保管されているオブジェクトの構成を編集し、アノテーション
- オブジェクトの管理を停止してオブジェクトを削除する必要があります。
- リポからオブジェクトの構成を削除します。以前に管理されていたオブジェクトの構成ファイルを削除すると、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 での管理を開始します。
myrole
Role をgamestore
Namespace 内に作成します。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]
このロールには、
get
Pod の権限のみが含まれています。この時点で、ロールはクラスタ内に存在しますが、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 します。
ConfigManagement 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-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 の構成を削除していないことを前提としています。
前回の commit でリポジトリから
gamestore-webstore-admin
RoleBinding を削除した場合は、次の手順を実行します。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 内のすべての構成に追加します。このアノテーションは、Namespace 内のすべてのオブジェクトに付ける必要があります。変更をリポジトリに commit して push します。演算子がリポジトリと同期するまで待ちます。
リポジトリから管理対象外のリソースを削除します。
マネージド オブジェクトの構成ファイルが非マネージド Namespace ディレクトリ内にあると、Reconciler はエラーをログに記録しますが、他の構成ファイルは引き続き正常に同期されます。
マネージド リソースを削除する
信頼できる情報源から個々のリソースを削除すると、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 オブジェクトで削除の伝播を有効にしてそのオブジェクトを削除すると、Config Sync はその RootSync または RepoSync で管理されていたオブジェクトをすべて自動的に削除します。
削除の伝播を使用すると、新しい Namespace やクラスタに移行する場合、デモやテストの後にクリーンアップする場合、アプリケーションをアンインストールする場合などに、リソースを簡単にクリーンアップできます。
削除の伝播のオプション
削除の伝播はデフォルトで無効になっています。削除の伝播を有効にするには、次の例のように 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: init
dir: config-sync-quickstart/multirepo/root
auth: none
period: 30s
また、次のコマンドを実行して、削除の伝播を使用するように既存の RootSync または RepoSync を更新することもできます。
RootSync
kubectl patch RootSync ROOTSYNC_NAME \
--namespace config-management-system \
--type merge \
--patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
ROOTSYNC_NAME
は、更新する RootSync の名前に置き換えます。
RepoSync
kubectl patch RepoSync REPOSYNC_NAME \
--namespace config-management-system \
--type merge \
--patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
REPOSYNC_NAME
は、更新する RepoSync の名前に置き換えます。
削除の伝播を無効にするには、アノテーションを削除するか、値を configsync.gke.io/deletion-propagation-policy: Orphan
に変更します。
RootSync
kubectl patch RootSync ROOTSYNC_NAME \
--namespace config-management-system \
--type merge \
--patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'
ROOTSYNC_NAME
は、更新する RootSync の名前に置き換えます。
RepoSync
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 で管理されていたオブジェクトをすべて削除する方法を示します。
RootSync
アノテーションを RootSync オブジェクトに適用して削除の伝播を有効にします。
kubectl patch RootSync example-rootsync \ --namespace config-management-system \ --type merge \ --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
RootSync オブジェクトを削除し、Config Sync によってオブジェクトが削除されるのを待ちます。
kubectl delete RootSync example-rootsync --namespace config-management-system --wait
RootSync の削除が完了するまで数分かかることがあります。
RepoSync
アノテーションを RepoSync オブジェクトに適用して削除の伝播を有効にします。
kubectl patch RepoSync example-reposync \ --namespace example-namespace \ --type merge \ --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
RepoSync オブジェクトを削除し、Config Sync によってオブジェクトが削除されるのを待ちます。
kubectl delete RepoSync example-reposync --namespace example-namespace --wait
RepoSync の削除が完了するまで数分かかることがあります。
Kubernetes オブジェクトの削除を防止する
Config Sync によって管理されている Git リポジトリから Kubernetes オブジェクトを削除すると、新しい commit がクラスタに同期される際に、このオブジェクトはクラスタからも削除されます。
Git リポジトリから構成が削除される際に Config Sync によってクラスタ オブジェクトが削除されないようにする場合は、次の手順を行います。
Git リポジトリのオブジェクト構成にアノテーション
client.lifecycle.config.k8s.io/deletion: detach
を追加します。Git リポジトリの変更を commit して push します。
変更がクラスタに同期されるまで待ちます。
これらの手順を完了した後、Git リポジトリから構成が削除されても、Config Sync はクラスタからこのオブジェクトを削除しませんが、他のクライアントによって削除される可能性はあります。
信頼できる情報源のオブジェクトを無視する
Config Sync で信頼できる情報源のオブジェクトを無視することが必要になる場合もあります。たとえば、kpt 関数の構成はクラスタには適用すべきではありません。
Config Sync で無視する必要があるオブジェクトについては、config.kubernetes.io/local-config: "true"
アノテーションをそのオブジェクトに追加します。このアノテーションを追加すると、Config Sync はこのオブジェクトが信頼できる情報源から削除されたかのように無視します。local-config
アノテーションが "false"
以外の値に設定されているリソースは、"true"
に設定されているものとして扱われ、無視されます。