Config Sync を使用すると、構成のずれを防止して、クラスタ リソースを一元管理された信頼できる情報源に合わせることができます。デフォルトでは、Config Sync の組み込みの自己修復機能により、クラスタのパフォーマンスへの影響を最小限に抑えながら、ドリフトが自動的に検出され、元に戻されます。
クラスタが競合する変更を適用する前に、環境で競合する変更をブロックする必要がある場合は、ドリフト防止のために Config Sync アドミッション Webhook を有効にできます。この Webhook はメモリ オーバーヘッドを増加させ、メモリ不足(OOM)エラーを引き起こす可能性があるため、ほとんどのユースケースでは組み込みの自己修復機能を使用してください。
ドリフト防止が推奨されない理由
アドミッション Webhook では、Config Sync が Kubernetes OpenAPI スキーマを読み込んでリクエストを検証する必要があります。リソースや CustomResourceDefinition が多数あるクラスタでは、このスキーマ処理がメモリ上限を超え、コンポーネントの障害につながる可能性があります。ほとんどのユースケースでは、Config Sync に組み込まれた自己修復機能により、Webhook の安定性リスクなしでドリフト保護が提供されます。組み込みのセルフヒーリングを無効にすることはできません。
有効にすると、ドリフト防止はデフォルトで RootSync オブジェクトを保護します。RepoSync オブジェクトを保護するように機能を構成できます。ドリフト防止を使用するには、RootSync API と RepoSync API を有効にする必要があります。詳細については、RootSync フィールドと RepoSync フィールドをご覧ください。
始める前に
Google Cloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新バージョンを取得します。
ドリフト防止を有効にする
ドリフト防止は、gcloud CLI を使用して有効にできます。 Google Cloud コンソールで、ドリフト防止を有効にすることはできません。
ドリフト防止を有効にするには、次の操作を行います。
適用仕様マニフェストを更新して、
spec.configSync.preventDriftフィールドをtrueに設定します。applySpecVersion: 1 spec: configSync: enabled: true ... existing content ... preventDrift: true更新されたマニフェストを適用します。
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。
ConfigManagement Operator によって Config Sync
ValidateWebhookConfigurationオブジェクトが作成されるまで待ちます。kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io出力は次の例のようになります。
NAME WEBHOOKS AGE admission-webhook.configsync.gke.io 0 2m15sroot-reconcilerDeployment が Config Sync ValidatingWebhookConfiguration オブジェクトに Webhook を追加できるように、同期される信頼できる情報源の新しい変更を commit します。または、root-reconcilierDeployment を削除して調整をトリガーすることもできます。新しいroot-reconcilerDeployment により、Config Sync ValidatingWebhookConfiguration オブジェクトが更新されます。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 構成ファイルを生成しません。
ドリフト防止を無効にするには、次の操作を行います。
適用仕様マニフェストを更新して、
spec.configSync.preventDriftフィールドをfalseに設定します。applySpecVersion: 1 spec: configSync: enabled: false ... existing content ... preventDrift: false更新されたマニフェストを適用します。
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 がすでに存在する場合、この操作を行う必要はありません。
ルートの信頼できる情報源で、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"]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.ioNAMESPACEは、Namespace スコープのソースを作成した Namespace に置き換えます。Git リポジトリから同期する場合など、信頼できる情報源のルートに変更を commit します。
git add . git commit -m 'Providing namespace repository the permission to update the admission webhook.' git pushkubectl getを使用して ClusterRole と ClusterRoleBinding が作成されていることを確認します。kubectl get clusterrole admission-webhook-role kubectl get clusterrolebindings syncs-webhook
次のステップ
- Webhook のトラブルシューティングを行う方法を学習する。