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