9.3. Webhook 受付プラグイン
OpenShift Container Platform のデフォルト受付プラグインのほかに、受付チェーンの機能を拡張するために Webhook サーバーを呼び出す Webhook 受付プラグインを使用して動的な受付を実装できます。Webhook サーバーは、定義されたエンドポイントにて HTTP で呼び出されます。
OpenShift Container Platform には、2 種類の Webhook 受付プラグインがあります。
- 受付プロセスで、変更用の受付プラグイン は、アフィニティーラベルの挿入などのタスクを実行できます。
- 受付プロセスの最後に、検証用の受付プラグイン を使用して、アフィニティーラベルが予想通りにされているかどうかの確認など、オブジェクトが適切に設定されていることを確認できます。検証にパスすると、OpenShift Container Platform はオブジェクトを設定済みとしてスケジュールします。
API 要求が送信されると、変更用または検証用の受付コントローラーは設定内の外部 Webhook の一覧を使用し、それらを並行して呼び出します。
- すべての Webhook が要求を承認すると、受付チェーンは継続します。
- Webhook のいずれかが要求を拒否する場合、受付要求は拒否され、これは、初回の拒否理由に基づいて実行されます。
- 複数の Webhook が受付要求を拒否する場合は、初回の拒否理由のみがユーザーに返されます。
-
Webhook の呼び出し時にエラーが発生した場合、要求は拒否されるか、Webhook はエラーポリシーセットに応じて無視されます。エラーポリシーが
Ignoreに設定されている場合、要求は失敗すると無条件で受け入れられます。ポリシーがFailに設定される場合、失敗した要求は拒否されます。Ignoreを使用すると、すべてのクライアントの予測できない動作が生じる可能性があります。
Webhook の受付プラグインと Webhook サーバー間の通信は TLS を使用する必要があります。CA 証明書を生成し、その証明書を使用して Webhook 受付サーバーで使用されるサーバー証明書に署名します。PEM 形式の CA 証明書は、サービス提供証明書のシークレットなどのメカニズムを使用して Webhook 受付プラグインに提供されます。
以下の図は、複数の Webhook サーバーが呼び出される連続した受付チェーンのプロセスを示しています。
図9.1 変更用および検証用の受付プラグインを含む API 受付チェーン
Webhook 受付プラグインのユースケースの例として使用できるケースでは、すべての Pod に共通のラベルのセットがなければなりません。この例では、変更用の受付プラグインはラベルを挿入でき、検証用の受付プラグインではラベルが予想通りであることを確認できます。OpenShift Container Platform は引き続いて必要なラベルが含まれる Pod をスケジュールし、それらのラベルが含まれない Pod を拒否します。
一般的な Webhook 受付プラグインのユースケースとして、以下が含まれます。
- namespace の予約。
- SR-IOV ネットワークデバイスプラグインによって管理されるカスタムネットワークリソースの制限。
- テイントでノードにスケジュールする必要のある Pod を特定できるようにする容認の定義。
- Pod 優先順位クラスの検証。
OpenShift Container Platform の最大デフォルトの webhook タイムアウト値は 13 秒であり、変更することはできません。
