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

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

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

クラスター内のデフォルトのアドミッション・コントローラーは何ですか?

kube-apiserver コンポーネント参照情報内のクラスター・バージョン別のデフォルトのアドミッション・コントローラーの順序を確認します。

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

はい、詳しくは Kubernetesのドキュメントをご覧ください。

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 秒に減らすことを検討してください。
  • Web フックに適切な CPU とメモリーのリソース要求と制限を設定します。
  • Web フック・コンテナーが実行されていて、要求を処理する準備ができていることを確認できるように、Liveness Probe と Readiness Probe を追加します。
  • 可能な場合は、ポッドのアンチアフィニティー・スケジューリング・ルールを設定して、Web フック・ポッドが異なるワーカー・ノードおよびゾーンで実行されることを優先します。 代わりに ポッド・トポロジー を使用することもできます。 しかし、taints や強制的なアフィニティは、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 やメモリーを要求するポッドは、スケジュールされません。

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

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

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

クラスタのバージョン 1.21 以降では、Konnectivity が OpenVPN ソリューションに取って代わりました。 クラスター・バージョン 1.21 以降があり、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 フックの問題について支援が必要です。 どうすればよいですか?

Webhook のトラブルシューティングについては、 Webhook のデバッグ または Web フックが破損しているためクラスターを更新できない を参照してください。