アドミッションコントローラとWebhookを使ったクラスタマスターへのアクセス

アドミッション・コントローラーは、さまざまな Kubernetes リソースからの許可された API 要求が Red Hat OpenShift on IBM Cloud クラスター・マスターで実行される API サーバーに到達する前に、その要求をインターセプトします。そのような要求を、変更アドミッション Web フックを使用して変更したり、検証アドミッション Web フックを使用して検査したりします。どちらかの Web フックで要求が拒否されると、要求全体が失敗します。拡張機能の中には (組み込み機能かアドオン機能かによらず)、API サーバーに送信される要求を制御するために、セキュリティー対策としてアドミッション・コントローラーを必要とするものが多くあります。詳細については、 Kubernetes ドキュメントの「アドミッションコントローラーと動的アドミッションコントロールの使用」を参照してください。

独自のアドミッション・コントローラーを作成できますか?

はい。詳しくは、 Kubernetes および Red Hat OpenShift の資料を参照してください。

Kubernetes の資料に記載されているように、アドミッション・コントローラーは、通常であればコントロール・プレーンで処理される操作にも使用することができます。したがって、カスタムのアドミッション・コントローラーを構成する場合は十分に注意してください。カスタムのアドミッション・コントローラーが原因でクラスターに変化が発生した場合は、お客様が責任を負うことになります。

Webhook を使用するためのベスト・プラクティスは何ですか?

Webhookを設定する際には、以下のベストプラクティスと考慮事項に留意してください。

別のコントローラやオペレータが所有するリソースを変異させるために、変異させるWebhookを使用しないでください。そうすることで、リソースオーナーとウェブフックの間で無限の和解ループが発生する可能性があります。 Webhookは、リソースデータに metadata.ownerReferences が設定されているかどうかをチェックすることで、リソースの所有者を決定することができます。たとえば、Kubernetes レプリカセット・リソースは Kubernetes デプロイ・リソースによって所有され、決して Webhook によって変更されてはいけません。
Web フックのレプリカ・ポッドを作成して、ポッドが 1 つダウンしても、リソースからの要求を Web フックで処理できるようにしてください。可能であれば、複数のゾーンにレプリカ・ポッドを分散させてください。
適切な failurePolicy オプションを設定します。例えば、Webhook が失敗するか、接続の失敗やタイムアウトを無視するかなどです。 Web フックで接続エラーとタイムアウトを無視する場合は、 failurePolicy を Ignore に設定できます。これは、Web フックが要求を拒否した場合の apiserver の動作方法を変更するものではないことに注意してください。
timeoutSeconds 間隔を確認します。 v1beta1.admissionregistration.k8s.io API を使用する古い Webhook のデフォルトのタイムアウトは 30 秒です。 v1 API は、デフォルトの 10 秒を使用します。 Webhook 障害ポリシーが「無視」で、現在の timeoutSeconds が 30 の場合は、タイムアウトを 10 秒に減らすことを検討してください。 OpenShift クラスターの場合、コントロール・プレーン・コンポーネントのタイムアウトは 13 秒であることがよくあります。
Web フックに対する CPU とメモリーのリソースの要求と制限を設定してください。
Web フック・コンテナーを、要求を処理できる稼働状態に維持するために、Liveness Probe と Readiness Probe を追加してください。
ポッドのアンチアフィニティー・スケジューリング・ルールを設定して、可能な場合には Web フック・ポッドが別々のワーカー・ノードやゾーンで実行されるようにしてください。代わりにポッド・トポロジーを使用することもできます。ただし、Webhookポッドがスケジュールできる場所を制限するような汚染や強制的なアフィニティは避けてください。
Web フック・ポッドのリソースが他のポッドに消費されないように、Web フック・ポッドの優先順位の設定を system-cluster-critical に行ってください。
Web フックのスコープを適切なプロジェクトに設定してください。 kube-system、 ibm-system、 ibm-operators、 calico-apiserver、 calico-system、 tigera-operator 、 openshift-* プロジェクトなど、デフォルトでクラスタに設定されているシステムクリティカルなプロジェクトで実行されるリソースを処理するWebhookは避けてください。
namespaceSelector オプションを確認します。特定の重要な名前空間 ( kube-system など) にラベルを追加して、このような場合に Webhook が呼び出されないようにすることができます。このセットアップは、「オプトアウト」スタイル構成と呼ばれます。あるいは、特定のラベルを持つ名前空間に対してのみ Webhook が呼び出されるように namespaceSelector オプションを構成できます。このセットアップは、「オプトイン」構成と呼ばれます。 Webhook の目的によっては、すべての名前空間に対して Webhook を呼び出すことが重要な場合があります。 Kubernetes の資料で namespaceSelector 構成オプションを確認し、Webhook 構成を調整します。
クラスタのワーカーノードが、 Webhookアプリケーションの実行に適したサイズであることを確認してください。例えば、ワーカー・ノードが提供できる以上の CPU やメモリーを要求するポッドは、スケジュールされません。

アドミッション・コントローラーを使用するアプリには他にどのようなタイプがありますか?

クラスターのアドオン、プラグイン、その他のサード・パーティーの拡張機能の多くは、アドミッション・コントローラーを使用します。よくある例を以下に挙げます。

Portieris

アドミッション・コントローラー Webhook のセットアップ

クラスタのバージョン 4.14 以降では、Konnectivity が OpenVPN ソリューションに取って代わった。クラスタのバージョンが 4.14 以降で、Webhook が ClusterIP, を使用している場合は、代わりに Kubernetes サービスを使用するように Webhook を更新する必要があります。

Webhook を構成するには、Webhook アプリを Kubernetes サービスとして参照するか、Webhook アプリを IP アドレスまたはパブリック登録 DNS 名として参照します。

Kubernetes サービスとして Webhook アプリを参照するための構成例

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

IP アドレスまたはパブリックに登録された DNS 名として Webhook アプリを参照するための構成例

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

IPアドレスまたはDNS名としてWebhookアプリを参照する場合、以下の制限に注意してください：

URL が DNS の場合、この DNS はパブリックに登録された DNS 名でなければなりません。プライベート DNS 構成はサポートされていません。
URL が外部 IP アドレスの場合、つまり Webhook サービスがクラスタの外部にある場合、制御プレーンのネットワークがサービスへの接続に使用されます。制御プレーンはIPアドレスに到達できなければならない。例えば、IPアドレスがオンプレミス・ネットワークのもので、コントロール・プレーンがそのIPアドレスに到達できない場合、ウェブフック・サービスは機能しない。
URL がクラスタ IP アドレス、つまり Webhook サービスがクラスタ内にある場合、 Kubernetes API はクラスタ・ネットワークに接続する必要がある。クラスタのバージョンが 1.21 以降で、Webhook がクラスタ IP アドレスを使用している場合は、代わりに Kubernetes サービスを使用するように Webhook を更新する必要があります。

Web フックの問題について支援が必要です。どうすればよいですか?