このページでは、Config Sync Admission Webhook に関する問題を解決する方法について説明します。Webhook の詳細については、構成ファイルのドリフトを防止するをご覧ください。
KNV 2009 エラーのトラブルシューティング
以下の各セクションでは、KNV2009 エラーの解決方法について説明します。
Admission Webhook 接続の拒否
ドリフト保護を有効にしている場合は、Reconciler が構成ファイルのクラスタに適用しようとしたときに、次のエラーが表示される可能性があります。
KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused
このエラーは、Admission Webhook の準備がまだできていないか、異常になったこと表しています。これは通常、Config Sync のブートストラップ時に発生する可能性がある一時的なエラーです。
この問題が繰り返し発生する場合は、Admission Webhook Deployment を記述し、Pod がスケジュール可能かつ正常な状態であるかどうかを確認します。
kubectl describe deploy admission-webhook -n config-management-system
kubectl get pods -n config-management-system -l app=admission-webhook
Pod が正常な Deployment の出力は次のようになります。
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
...
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
...
Admission Webhook リクエストの I/O タイムアウト
Reconciler がクラスタに構成を適用しようとしたときに、次のようなエラーが表示された場合は、Admission Webhook ポート 8676 で、ファイアウォールによってコントロール プレーン ネットワークへの通信がブロックされる可能性があります。
KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout
この問題を解決するには、ポート 8676 を許可するファイアウォール ルールを追加します。これは、Config Sync Admission Webhook がドリフト防止に使用するポートです。コントロール プレーンがクラスタノード上の Webhook バックエンドに到達できるようにするため、コントロール プレーンからノードへのポート 8676 を開く必要があります。
Admission Webhook によりリクエストが拒否された
Config Sync で管理されているフィールドに変更を適用しようとして次のエラーが発生した場合は、競合が生じる変更を行った可能性があります。
error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified
ドリフト保護を有効にしている場合、構成ファイルでフィールドを宣言し、リポジトリがクラスタに同期されると、対象のフィールドは Config Sync が管理します。対象フィールドを変更しようとすることは、競合する変更に該当します。
たとえば、リポジトリに environment:prod のラベルが付いた Deployment 構成ファイルがあり、クラスタ内でそのラベルを environment:dev に変更しようとすると、それは競合する変更となり、このエラー メッセージが表示されます。ただし、新しいラベル（tier:frontend など）を Deployment に追加しても競合は発生しません。
Config Sync でオブジェクトへの変更が無視されるようにするには、オブジェクトのミューテーションを無視するで説明されているアノテーションを追加します。
すべてのリソースタイプの削除ができなかった
Terminating フェーズで Namespace がスタックする際の条件は次のとおりです。
message: 'Failed to delete all resource types, 1 remaining: admission webhook
"v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
is not authorized to delete managed resource "_configmap_bookstore_cm1"'
reason: ContentDeletionFailed
status: "True"
type: NamespaceDeletionContentFailure
このエラーは、ルート リポジトリから Namespace オブジェクトを削除しようとしたときに、Namespace の下にある一部のオブジェクトが Namespace の Reconciler によってアクティブに管理されている場合に発生します。Namespace が削除されると、Namespace コントローラ（サービス アカウントが system:serviceaccount:kube-system:namespace-controller）は、対象の Namespace にあるすべてのオブジェクトを削除しようとします。ただし、Config Sync Admission Webhook は、ルートまたは Namespace の Reconciler にのみこれらのオブジェクトの削除を許可し、Namespace コントローラによる削除を拒否します。
この問題を回避するには、Config Sync Admission Webhook を削除します。
kubectl delete deployment.apps/admission-webhook -n config-management-system
ConfigManagement Operator が Config Sync Admission Webhook を再作成します。
この回避策で問題が解決しない場合は、Config Sync の再インストールが必要になることがあります。
エラーの再発を防ぐため、Namespace を削除する前にNamespace リポジトリを削除してください。
次のステップ
- まだ問題が解決しない場合は、既知の問題かどうかを確認してください。