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

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

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

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

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

はい。 Kubernetes ドキュメントを参照してください。

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

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

可能な限りWebhookの使用を避けてください。 代わりに と MutatingAdmissionPolicy （デフォルトで有効 ValidatingAdmissionPolicy 化されている場合）を代替手段として使用してください。

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 秒に減らすことを検討してください。

    複数の変更を伴うWebhookが同じリソースに対して動作することを避ける。 変異するウェブフックは順次実行される。 単一の変更型Webhookは、タイムアウトおよび失敗ポリシーの観点からは期待通りに動作する可能性がある。しかし、同じリソースに対して動作する追加の変更型Webhookと組み合わせた場合、変更型Webhook全体が、すべてのWebhookを実行するために割り当てられた総コンテキストタイムアウトを超過する可能性がある。

  • Web フックに適切な CPU とメモリーのリソース要求と制限を設定します。

  • Webhookコンテナが実行中で、リクエストに応答できる状態であることを確認するために、 有効性プローブと準備完了プローブを 追加します。

  • 可能な場合は、ポッドのアンチアフィニティー・スケジューリング・ルールを設定して、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 やメモリーを要求するポッドは、スケジュールされません。

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

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

アドミッション・コントローラー 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 フックが破損しているためクラスターを更新できない を参照してください。