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

Config Sync には、ドリフトを管理する次の 2 つの方法があります。

  • Config Sync の組み込みの自己修復を使用する（推奨、構成は不要）: Config Sync は、ドリフトを自動的に検出して元に戻します。 Config Sync の自己修復を無効にすることはできません。自己修復がパフォーマンスに与える影響は最小限です。
  • ドリフト防止機能を有効にする（このページ）: ドリフト防止は、アドミッション Webhook を使用して競合する変更をブロックします。この機能は、特に多くの CustomResourceDefinitions（CRD）があるクラスタで、メモリ使用量が多くなり、メモリ不足（OOM）エラーが発生する可能性があります。

アドミッション Webhook では、リクエストを検証するために Config Sync が Kubernetes OpenAPI スキーマを読み込む必要があります。リソースや CRD が多いクラスタでは、このスキーマ処理でメモリ上限を超える可能性があり、コンポーネントの障害につながります。ほとんどのユースケースでは、Config Sync の組み込みの自己修復機能により、Webhook の安定性のリスクなしにドリフト防止を実現できます。

有効にすると、ドリフト防止はデフォルトで RootSync オブジェクトを保護します。この機能を構成して、RepoSync オブジェクトを保護することもできます。ドリフト防止を使用するには、 RootSync API と RepoSync API を有効にする必要があります。

始める前に

Google Cloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新バージョンを取得します。

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

ドリフト防止は、gcloud CLI を使用して有効にできます。 Cloud de Confiance コンソールで、ドリフト防止を有効にすることはできません。

ドリフト防止を有効にするには、次の操作を行います。

  1. 適用仕様マニフェストを更新して、spec.configSync.preventDrift フィールドを true に設定します。

    applySpecVersion: 1
spec:
  configSync:
    enabled: true
    ... existing content ...
    preventDrift: true

  2. 更新されたマニフェストを適用します。

    gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID

    次のように置き換えます。

    • MEMBERSHIP_NAME: クラスタの登録時に選択したフリートのメンバーシップ名。gcloud container fleet memberships list コマンドを使用して名前を取得します。
    • MANIFEST_NAME: 適用仕様マニフェストの名前（通常は apply-spec.yaml）。
    • PROJECT_ID: プロジェクト ID。

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

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

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

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

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

  5. 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

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

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

ドリフト防止を無効にするには、次の操作を行います。

  1. 適用仕様マニフェストを更新して、spec.configSync.preventDrift フィールドを false に設定します。

    applySpecVersion: 1
spec:
  configSync:
    enabled: false
    ... existing content ...
    preventDrift: false

  2. 更新されたマニフェストを適用します。

    gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID

    次のように置き換えます。

    • MEMBERSHIP_NAME: クラスタの登録時に選択したフリートのメンバーシップ名。gcloud container fleet memberships list コマンドを使用して名前を取得します。
    • MANIFEST_NAME: 適用仕様マニフェストの名前（通常は apply-spec.yaml）。
    • PROJECT_ID: プロジェクト ID。

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

Namespace スコープの信頼できる情報源は、Webhook で完全には保護されていません。各名前空間ソースの 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

次のステップ