Webhook 使用時のコントロール プレーンの安定性を確保する

Autopilot Standard

アドミッション Webhook（Kubernetes の Webhook）はアドミッション コントローラの一種で、Kubernetes クラスタでこれを使用して、リクエストが永続化される前に、コントロール プレーンへのリクエストを検証または変更できます。サードパーティ アプリケーションでは、システムに不可欠なリソースと名前空間で動作する Webhook を使用するのが一般的です。Webhook が正しく構成されていなければ、コントロール プレーンのパフォーマンスと信頼性に影響する可能性があります。たとえば、サードパーティ アプリケーションによって作成された Webhook が正しく構成されていなければ、GKE でマネージド kube-system Namespace でのリソースの作成や変更ができなくなり、クラスタの機能が低下する可能性があります。

Google Kubernetes Engine（GKE）はクラスタをモニタリングし、Recommender サービスを利用して、プラットフォームの使用を最適化できるようにガイダンスを提供します。クラスタの安定性とパフォーマンスを維持するために、次のシナリオに関する GKE の推奨事項をご覧ください。

• 動作しているが利用可能なエンドポイントがない Webhook。
• システムの重要なリソースと Namespace で動作するため、安全でないとみなされている Webhook。

このガイダンスを使用すると、構成ミスの可能性がある Webhook を確認し、必要に応じて更新する手順を確認できます。

Recommender から取得した分析情報と推奨事項を管理する方法については、分析情報と推奨事項で GKE の使用を最適化するをご覧ください。

クラスタに影響を与える可能性のある Webhook の構成ミスを特定する

クラスタのパフォーマンスと安定性に影響する可能性がある Webhook を識別する分析情報を取得するには、分析情報と推奨事項を表示するの手順に沿って操作します。分析情報は次の方法で取得できます。

• Google Cloud コンソールを使用する。
• Google Cloud CLI または Recommender API を使用して、サブタイプ K8S_ADMISSION_WEBHOOK_UNSAFE と K8S_ADMISSION_WEBHOOK_UNAVAILABLE でフィルタリングする。

分析情報で Webhook を特定したら、検出された Webhook のトラブルシューティングの手順に沿って操作します。

GKE が構成ミスのある Webhook を検出した場合

クラスタが次のいずれかの条件に該当する場合、GKE は分析情報と推奨事項を生成します。

• K8S_ADMISSION_WEBHOOK_UNAVAILABLE: GKE クラスタに利用可能なエンドポイントがないことを報告する Webhook が 1 つ以上あります。手順に沿って、利用可能なエンドポイントがないことを報告している Webhook を確認します。

• K8S_ADMISSION_WEBHOOK_UNSAFE: GKE クラスタにインターセプトするリソースに基づいて安全でないと判断された Webhook が 1 つ以上あります。手順に沿って、安全でないと判断された Webhook を確認します。次の Webhook は安全でないとみなされます。

  • kube-system Namespace の Pod やリースなどのリソースをインターセプトする Webhook。
  • kube-node-lease Namespace のリースをインターセプトする Webhook。
  • Nodes、TokenReviews、SubjectAccessReviews、CertificateSigningRequests など、クラスタ スコープのシステム リソースをインターセプトする Webhook。

検出された Webhook のトラブルシューティング

以下の各セクションでは、構成ミスの可能性があるとして GKE によって検出された Webhook のトラブルシューティングの手順について説明します。

指示に従って Webhook を正しく構成すると、推奨事項は 24 時間以内に解決され、コンソールに表示されなくなります。

推奨事項を実施しない場合は、拒否することができます。

利用可能なエンドポイントがないと Webhook が報告する

Webhook が使用可能なエンドポイントがないと報告している場合、Webhook エンドポイントの背後にある Service には、実行されていない 1 つ以上の Pod があります。Webhook エンドポイントを利用できるようにするには、この Webhook エンドポイントの背後にある Service の Pod を見つけてトラブルシューティングを行います。

1. 分析情報と推奨事項を表示し、トラブルシューティングする分析情報を一度に 1 つ選択します。GKE はクラスタごとに 1 つの分析情報を生成します。この分析情報には、調査が必要な損傷したエンドポイントがある Webhook が 1 つ以上表示されます。これらの Webhook のそれぞれについて、Service の名前、損傷したエンドポイント、最後にエンドポイントが呼び出された時刻も表示されます。

2. Webhook に関連する Service の処理元の Pod を見つけます。

   コンソール

   分析情報のサイドバー パネルから、正しく構成されていない Webhook の表が表示されます。Service の名前をクリックします。

   kubectl

   次のコマンドを実行して Service の説明を取得します。

   kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
   

   SERVICE_NAME と SERVICE_NAMESPACE をそれぞれサービスの名前と名前空間に置き換えます。

   Webhook に Service 名が表示されない場合は、構成にリストされている名前と Service の実際の名前の不一致が原因で、エンドポイントが使用できない可能性があります。エンドポイントの可用性を修正するには、正しい Service オブジェクトと一致するように Webhook 構成の Service 名を更新します。

3. この Service の処理元の Pod を検査します。

   コンソール

   [Service の詳細] の [処理元の Pod] で、この Service の背後にある Pod のリストを確認します。

   kubectl

   Deployment または Pod を一覧表示して、実行されていない Pod を特定します。

   kubectl get deployment -n SERVICE_NAMESPACE
   

   または、次のコマンドを実行します。

   kubectl get pods -n SERVICE_NAMESPACE -o wide
   

   実行されていない Pod がある場合は、Pod のログを調べて、その Pod が実行されていない理由を確認します。Pod に関する一般的な問題に対する手順については、デプロイされたワークロードに関する問題のトラブルシューティングをご覧ください。

安全でないとみなされる Webhook

Webhook がシステム管理の名前空間内のリソース、または特定のタイプのリソースをインターセプトしている場合、GKE はこれを安全でないものとみなし、これらのリソースのインターセプトを避けるために Webhook を更新することをおすすめします。

1. 分析情報と推奨事項を表示する手順に沿って、トラブルシューティングする分析情報を 1 つずつ選択します。GKE はクラスタごとに 1 つの分析情報のみを生成します。この分析情報には、1 つ以上の Webhook 構成が一覧表示されます。各構成には 1 つ以上の Webhook が含まれます。表示された Webhook 構成ごとに、構成にフラグが付けられた理由が分析情報に表示されます。

2. Webhook の構成を確認します。

   コンソール

   分析情報のサイドバー パネルから、表が表示されます。各行には、Webhook 構成の名前と、この構成にフラグが付けられた理由が表示されます。

   各構成を調べるには、名前をクリックして GKE のオブジェクト ブラウザ ダッシュボードでこの構成に移動します。

   kubectl

   次の kubectl コマンドを実行して Webhook 構成を取得します。CONFIGURATION_NAME は、Webhook 構成の名前に置き換えます。

   kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
   

   このコマンドが何も返さない場合は、validatingwebhookconfigurations を mutatingwebhookconfigurations に置き換えてコマンドを再実行します。

   webhooks セクションに 1 つ以上の Webhook が表示されます。

3. Webhook にフラグが付けられた理由に応じて、構成を編集します。

   kube-system Namespace と kube-node-lease Namespace を除外する

   scope が * の場合、Webhook にフラグが付けられます。または、スコープが Namespaced で、次のいずれかの条件に当てはまる場合、Webhook にフラグが付けられます。

   • 次の例のように、operator 条件は NotIn であり、values は kube-system と kube-node-lease を省略している場合:

     webhooks:
     - admissionReviewVersions:
       ...
       namespaceSelector:
         matchExpressions:
         - key: kubernetes.io/metadata.name
           operator: NotIn
           values:
           - blue-system
       objectSelector: {}
       rules:
       - apiGroups:
         ...
         scope: '*'
       sideEffects: None
       timeoutSeconds: 3
     

     Webhook が特定の名前空間でのみ動作するように、scope が * ではなく Namespaced に設定されていることを確認します。また、operator が NotIn の場合は、kube-system と kube-node-lease を values に含めます（この例では、blue-system を使用）。

   • 次の例のように、operator 条件は In であり、values には kube-system と kube-node-lease が含まれている場合:

     namespaceSelector:
         matchExpressions:
         - key: kubernetes.io/metadata.name
           operator: In
           values:
           - blue-system
           - kube-system
           - kube-node-lease
     

     Webhook が特定の名前空間でのみ動作するように、scope が * ではなく Namespaced に設定されていることを確認します。operator が In の場合は、values に kube-system と kube-node-lease を含めないでください。この例では、operator が In であるため、values には blue-system のみを含める必要があります。

   一致したリソースを除外する

   次の例のように、nodes、tokenreviews、subjectaccessreviews、または certificatesigningrequests がリソースの下に表示されている場合も、Webhook にフラグが付けられます。

   - admissionReviewVersions:
   ...
     resources:
     - 'pods'
     - 'nodes'
     - 'tokenreviews'
     - 'subjectaccessreviews'
     - 'certificatesigningrequests'
     scope: '*'
   sideEffects: None
   timeoutSeconds: 3
   

   リソース セクションから nodes、tokenreviews、subjectaccessreviews、certificatesigningrequests を削除します。pods は resources に保持できます。

次のステップ

• 分析情報と推奨事項で GKE の使用を最適化する。
• 一般的な問題のトラブルシューティング
• GKE ワークロードから Google Cloud API に対する認証を行う
• 機能と API のサポート終了について確認する