Webhook のデバッグ

kubectl コマンドを実行すると、以下の例のようなエラー・メッセージが表示されます。

Error from server (InternalError): error when creating "testjob.yaml": Internal error occurred: failed calling webhook "mywebhook.test.io": Post https://admission-webhook.default.svc:443/validate?timeout=30s: dial tcp 172.21.189.228:443: connect: connection timed out

error creating namespace "test": Internal error occurred: admission plugin "MutatingAdmissionWebhook" failed to complete mutation in 13s

Webhook が失敗すると、以下のような問題が発生する可能性もあります。

ポッド、シークレット、または名前空間を作成したり変更したりすることはできません。
クラスターにワーカー・ノードを追加したり、LUKS 暗号鍵を保持するシークレットを作成したりすることはできません。
パッチ、更新、またはアップグレードを行うことはできません。根本的な障害は、クラスター内のリソースの作成に関連しています。

呼び出されたサービスまたはセキュア・トンネルに問題があると、タイムアウトが原因で要求が失敗する可能性があります。これが発生するまでは、アドミッション制御 Webhook がインストールされていることに気付かない場合があります。

アドミッション制御 Webhook は、 Kubernetes API 要求を検証、変更、または変更する機能を提供します。これらの Webhook は、クラスター apiserver または openshift-apiserver から呼び出され、通常はクラスター内で実行されているサービスを呼び出します。アドミッション制御 Webhook には、ポッド、名前空間などのリソースの種類と、呼び出される操作 (作成、更新、削除 (CRUD) など) を定義するルールがあります。

Web フックには、Web フックの呼び出し時に Kubernetes が接続エラーを無視できるかどうか、または接続エラーで操作を失敗させる必要があるかどうかを示す障害ポリシーがあります。 ValidatingWebhookConfiguration リソースは要求を検査し、 MutatingWebhookConfiguration リソースは要求データを処理前に変更します。

Webhook は、通常の操作の一部として要求を拒否することもできます。Webhook は、セキュリティー・ポリシーに違反する要求を拒否したり、他のデータ検証を実行したりする可能性があります。このような場合、障害情報には、問題を示す理由付きの denied the request 応答が含まれます。

admission webhook "mutate.configuration.upsert.appconnect.ibm.com" denied the request: version is not supported

IBM Cloud Kubernetes Serviceでは、クラスターで実行されるサービスを呼び出す Webhook は、 IBM Cloud アカウントのクラスター・コントロール・プレーンをカスタマー・アカウントのクラスター・ワーカー・ノードに接続するセキュア・トンネルを使用してこれを行います。

問題の原因となっている Web フックを特定するには、以下の手順を実行します。次に、関連するサービスをデバッグし、必要に応じて Webhook を削除または再作成します。

以下のコマンドを実行して、VPN ポッドのログを取得します。 VPN ログを取得できない場合は、一般的な CLI 問題のデバッグの手順に従って、ログを取得できるようになった時点でこのページに戻ります。コマンドが正常に実行され、ログを取得できる場合は、VPN トンネルが機能しており、次のステップに進むことができます。
```
kubectl get pods -n kube-system -l app=vpn
```
```
kubectl logs -n kube-system -l app=vpn
```
アドミッション・コントロール Webhook を記述し、出力を webhooks.txt というファイルに保存します。
```
kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
```
webhooks.txt ファイルでエラー・メッセージを確認します。 kubectl など、アプリケーションからの Webhook 関連のエラー・メッセージは、Webhook の識別に役立ちます。
拒否タイプ、カウント、および拒否コードの API サーバー・メトリックを確認します。以下のコマンドを使用すると、メトリクスのスナップショットを取得できます。
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_rejection_count
```
```
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="check-ignore-label.gatekeeper.sh",operation="UPDATE",rejection_code="0",type="validating"} 16
```
rejection_code 値 0 は、Webhook の呼び出し時にエラーが発生したことを示します。ゼロ以外の rejection_code 値は、Webhook が要求を拒否したことを示します。

3 つの API サーバー・インスタンスがあります。 kubectl コマンドは、それらのいずれかからメトリックを取得し、そこでのアクティビティーを反映します。各 apiserver は異なるデータを返します。失敗した要求を処理していないインスタンスは、このメトリックを返さない可能性があります。
前のステップのコマンド出力を確認し、Web フックの説明を探して、特定の MutatingWebhookConfiguration 値または ValidatingWebhookConfiguration 値を識別します。エラー、ログ、またはメトリックが役に立たない場合は、前に取得した Webhook の説明を確認してください。各 Webhook 構成には、Webhook が呼び出される対象のリソースとアクションの種類を指定する一連のルールがあります。この情報は、関連する可能性のある Web フックを識別するために使用できます。
- Webhook の呼び出し中にエラーが発生した場合は、そのサービスの資料を参照して、製品固有のデバッグ・ステップを確認してください。
- Webhook が要求を拒否する場合は、Webhook のポリシーと構成オプションを確認します。要求を許可するようにそれらを調整することが可能な場合があります。あるいは、要求がポリシーに違反している可能性があり、要求または要求を作成するアプリケーションを変更する必要があります。詳しくは、 Webhook の使用に関するベスト・プラクティスを参照してください。

Webhook が呼び出しているサービスの確認

サービスとそのエンドポイントの詳細を取得します。
```
kubectl get svc NAME -n NAMESPACE
```
```
kubectl get ep NAME -n NAMESPACE
```
- Web フックが、存在しないサービスを呼び出している場合、Web フックは、アプリケーションの不完全または不適切な削除から残される可能性があります。この場合は、サービス固有の資料を探して、サービスをアンインストールする手順に従ってください。
- サービスをアンインストールできない場合は、Webhook 構成を削除します。
```
kubectl delete validatingwebhookconfiguration NAME
```
```
kubectl delete mutatingwebhookconfiguration NAME
```
サービスは存在するが、エンドポイントがない場合は、ポッドの正常性を確認します。最初に、サービスからポッド・ラベルを取得します。
```
kubectl describe svc NAME -n NAMESPACE
```
出力例
```
Selector:          app=my-webhook
```
ラベルを使用しているポッドをリストアップする。例えば、以下のコマンドのラベルは app=mywebhook です。
```
kubectl get pods -n NAMESPACE -l app=my-webhook
```
コマンドの出力を確認します。ポッドが健全でない場合は、ポッドのイベント、ログ、ワーカー・ノードの健全性、その他のコンポーネントをチェックしてトラブルシューティングを行う。詳しくは、アプリ・デプロイメントのデバッグを参照してください。

Webhook の無効化または削除

障害ポリシーを Ignore に設定して、接続とタイムアウトを一時的に無視します。以下のコマンドを実行して、ウェブフックを編集する。
```
kubectl edit validatingwebhookconfiguration NAME
```
```
kubectl edit mutatingwebhookconfiguration NAME
```
failurePolicy を検索し、値を Ignore に変更します。
設定を保存してエディタを終了します。障害ポリシーを調整しても問題が解決しない場合は、前のステップを繰り返し、値を Fail に戻します。

一時的に Webhook を削除します。削除する前に、既存の Webhook 構成をファイルに保存してください。

kubectl get validatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

kubectl get mutatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

Webhook 構成を削除します。

kubectl delete validatingwebhookconfiguration NAME

kubectl delete mutatingwebhookconfiguration NAME

数分待ってから、失敗した kubectl コマンドを再試行して、問題が解決されたかどうかを確認します。
Webhook を再作成します。
```
kubectl apply -f webhook-config.yaml
```
問題が解決しない場合は、サポートにお問い合わせください。サポート Case を開きます。ケースの詳細には、関連するログ・ファイル、エラー・メッセージ、またはコマンド出力を必ず含めてください。