構成ファイルのドリフトを防ぐ

Config Sync では、自動自己修復、定期的な再同期、オプションのドリフト防止により、「シャドウ オペレーション」のリスクを軽減できます。Config Sync がクラスタと信頼できる情報源間のドリフトを検出した場合は、許可して迅速に元に戻す、または完全に拒否できます。

自己修復は、マネージド リソースを監視して、信頼できる情報源のドリフトを検出し、検出したドリフトを元に戻します。セルフヒーリングは常に有効です。

定期的な再同期は、信頼できる情報源に変更が加えられていなくても、前回の同期が成功してから 1 時間後に自動的に同期を実施します。定期的な再同期は常に有効です。

自己修復と定期的な再同期は、ドリフトを修正するのに役立ちますが、ドリフト防止は管理対象オブジェクトの変更リクエストをインターセプトし、変更を許可する必要があるかどうかを検証します。変更が信頼できる情報源と一致しない場合、変更は拒否されます。ドリフト防止はデフォルトで無効になっています。有効にすると、ドリフト防止はデフォルトで RootSync オブジェクトを保護します。また、RepoSync オブジェクトを保護するように構成することもできます。

ドリフト防止を使用するには、RootSync API と RepoSync API を有効にする必要があります。

ドリフト防止を有効にする

  1. 構成ファイルの preventDrift フィールドを true に設定し、構成ファイルを適用します。

    gcloud

    Google Cloud コンソールまたは gcloud CLI を使用して Config Sync をインストールした場合は、gcloud CLI を使用してドリフト防止を有効にします。gcloud CLI を最新バージョンに更新してください。gcloud 構成ファイルの spec.configSync.preventDrift フィールドを true に設定し、gcloud 構成ファイルを適用します。

    kubectl

    kubectl を使用して Config Sync を手動でインストールした場合は、kubectl を使用してドリフト防止を有効にします。ConfigManagement オブジェクトの spec.preventDrift フィールドを true に設定し、ConfigManagement オブジェクトを適用します。

  2. ConfigManagement Operator によって Config Sync ValidateWebhookConfiguration オブジェクトが作成されるまで待ちます。

    kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io

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

    NAME                                  WEBHOOKS   AGE
admission-webhook.configsync.gke.io   0          2m15s

  3. root-reconciler Deployment が Config Sync ValidatingWebhookConfiguration オブジェクトに Webhook を追加できるように、同期される信頼できる情報源の新しい変更を commit します。または、root-reconcilier Deployment を削除して調整をトリガーすることもできます。新しい root-reconciler Deployment により、Config Sync ValidatingWebhookConfiguration オブジェクトが更新されます。

  4. Webhook サーバーの準備が整うまで待ちます。Config Sync アドミッション Webhook デプロイログに serving webhook server が含まれているはずです。これには数分かかることがあります。

    kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"

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

    I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250

ドリフト防止を無効にする

gcloud

Google Cloud コンソールまたは gcloud CLI を使用して Config Sync をインストールした場合は、gcloud CLI を使用してドリフト防止を無効にします。gcloud CLI を最新バージョンに更新してください。gcloud 構成ファイルの spec.configSync.preventDrift フィールドを false に設定するか、フィールドを削除してから、gcloud 構成ファイルを適用します。

kubectl

kubectl を使用して Config Sync を手動でインストールした場合、kubectl を使用してドリフト防止を無効にします。ConfigManagement オブジェクトの spec.preventDrift フィールドを false に設定するか、フィールドを削除してから、ConfigManagement オブジェクトを適用します。

これによって、Config Sync アドミッション Webhook リソースがすべて削除されます。Config Sync ValidatingWebhookConfiguration オブジェクトが存在しないため、Config Sync Reconciler はマネージド リソースの Webhook 構成ファイルを生成しません。

Namespace スコープの情報源で Admission Webhook を有効にする

Namespace スコープの信頼できる情報源は、Webhook で完全には保護されていません。各 Namespace ソースの Config Sync Reconciler には、クラスタレベルで ValidatingWebhookConfiguration オブジェクトの読み取りまたは更新を行う権限がありません。

この権限がないと、Namespace Reconciler のログに次のようなエラーが記録されます。

Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope

Namespace スコープの信頼できる情報源に Webhook 保護を使用しない場合は、このエラーを無視して問題ありません。ただし、Webhook を使用する場合は、複数の信頼できる情報源からの同期を構成した後に、Namespace スコープの信頼できる各情報源の Reconciler に権限を付与します。ClusterRole cluster-admin 権限を持つ ns-reconciler-NAMESPACE の RoleBinding がすでに存在する場合、この操作を行う必要はありません。

  1. ルートの信頼できる情報源で、Config Sync Admission Webhook に対する権限を付与する新しい ClusterRole 構成を宣言します。この ClusterRole は、クラスタごとに 1 回だけ定義する必要があります。

    # ROOT_SOURCE/cluster-roles/webhook-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admission-webhook-role
rules:
- apiGroups: ["admissionregistration.k8s.io"]
  resources: ["validatingwebhookconfigurations"]
  resourceNames: ["admission-webhook.configsync.gke.io"]
  verbs: ["get", "update"]

  2. Admission Webhook 権限を付与する必要がある Namespace スコープのソースごとに ClusterRoleBinding 構成を宣言して、Admission Webhook へのアクセス権を付与します。

    # ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-webhook
subjects:
- kind: ServiceAccount
  name: ns-reconciler-NAMESPACE
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: admission-webhook-role
  apiGroup: rbac.authorization.k8s.io

    NAMESPACE は、Namespace スコープのソースを作成した Namespace に置き換えます。

  3. Git リポジトリから同期する場合など、信頼できる情報源のルートに変更を commit します。

    git add .
git commit -m 'Providing namespace repository the permission to update the admission webhook.'
git push

  4. kubectl get を使用して ClusterRole と ClusterRoleBinding が作成されていることを確認します。

    kubectl get clusterrole admission-webhook-role
kubectl get clusterrolebindings syncs-webhook

放棄されたリソースのドリフト防止を無効にする

デフォルトでは、RootSync オブジェクトまたは RepoSync オブジェクトを削除しても、Config Sync は以前に RootSync オブジェクトまたは RepoSync オブジェクトによって管理されていたリソースを変更しません。これにより、Config Sync がこれらのリソース オブジェクトの追跡に使用するラベルとアノテーションが残存する場合があります。この結果、ドリフト保護が有効になっている場合は、以前に管理されていたリソースへの変更が拒否される可能性があります。

削除の伝播を使用していない場合は、残存するリソース オブジェクトに Config Sync によって追加されたラベルとアノテーションが保持される可能性があります。

これらのマネージド リソースを保持する場合は、信頼できる情報源で宣言されているすべてのマネージド リソースで configmanagement.gke.io/managed アノテーションを disabled に設定して RootSync オブジェクトまたは RepoSync オブジェクトを削除する前に、これらのリソースを管理対象外にします。これにより、これらのリソースを削除することなく、マネージド リソースからラベルとアノテーションを削除するよう Config Sync に指示されます。同期の完了後、RootSync オブジェクトまたは RepoSync オブジェクトを削除できます。

これらのマネージド リソースを削除するには、次の 2 つの方法があります。

  • 信頼できる情報源からマネージド リソースを削除します。その後、Config Sync はクラスタからマネージド オブジェクトを削除します。同期の完了後、RootSync オブジェクトまたは RepoSync オブジェクトを削除できます。
  • 削除する前に、RootSync オブジェクトまたは RepoSync オブジェクトの削除の伝播を有効にします。その後、Config Sync はクラスタからマネージド オブジェクトを削除します。

マネージド リソースを管理対象外にする前または削除する前に RootSync オブジェクトまたは RepoSync オブジェクトを削除した場合は、RootSync オブジェクトまたは RepoSync オブジェクトを再作成すると信頼できる情報源に一致するクラスタのリソースが採用されます。その後、リソースを管理対象外にする、または削除し、変更が同期されるのを待ってから、RootSync オブジェクトまたは RepoSync オブジェクトを再度削除できます。

次のステップ