アドミッション 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-systemNamespace の Pod やリースなどのリソースをインターセプトする Webhook。kube-node-leaseNamespace のリースをインターセプトする Webhook。Nodes、TokenReviews、SubjectAccessReviews、CertificateSigningRequestsなど、クラスタ スコープのシステム リソースをインターセプトする Webhook。
検出された Webhook のトラブルシューティング
以下の各セクションでは、構成ミスの可能性があるとして GKE によって検出された Webhook のトラブルシューティングの手順について説明します。
手順を実施して Webhook が正しく構成されると、推奨事項は 24 時間以内に解決され、コンソールに表示されなくなります。推奨事項のガイダンスを実施してから 24 時間未満の場合は、推奨事項に解決済みのマークを付けることができます。推奨事項を実施しない場合は、拒否することができます。
利用可能なエンドポイントがないと Webhook が報告する
Webhook が使用可能なエンドポイントがないと報告している場合、Webhook エンドポイントの背後にある Service には、実行されていない 1 つ以上の Pod があります。Webhook エンドポイントを利用できるようにするには、この Webhook エンドポイントの背後にある Service の Pod を見つけてトラブルシューティングを行います。
分析情報と推奨事項を表示し、トラブルシューティングする分析情報を一度に 1 つ選択します。GKE はクラスタごとに 1 つの分析情報を生成します。この分析情報には、調査が必要な損傷したエンドポイントがある Webhook が 1 つ以上表示されます。これらの Webhook のそれぞれについて、Service の名前、損傷したエンドポイント、最後にエンドポイントが呼び出された時刻も表示されます。
Webhook に関連する Service の処理元の Pod を見つけます。
コンソール
分析情報のサイドバー パネルから、正しく構成されていない Webhook の表が表示されます。Service の名前をクリックします。
kubectl
次のコマンドを実行して Service の説明を取得します。
kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACESERVICE_NAME と SERVICE_NAMESPACE をそれぞれサービスの名前と名前空間に置き換えます。
Webhook に Service 名が表示されない場合は、構成にリストされている名前と Service の実際の名前の不一致が原因で、エンドポイントが使用できない可能性があります。エンドポイントの可用性を修正するには、正しい Service オブジェクトと一致するように Webhook 構成の Service 名を更新します。
この 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 つずつ選択します。GKE はクラスタごとに 1 つの分析情報のみを生成します。この分析情報には、1 つ以上の Webhook 構成が一覧表示されます。各構成には 1 つ以上の Webhook が含まれます。表示された Webhook 構成ごとに、構成にフラグが付けられた理由が分析情報に表示されます。
Webhook の構成を確認します。
コンソール
分析情報のサイドバー パネルから、表が表示されます。各行には、Webhook 構成の名前と、この構成にフラグが付けられた理由が表示されます。
各構成を調べるには、名前をクリックして GKE のオブジェクト ブラウザ ダッシュボードでこの構成に移動します。
kubectl
次の
kubectlコマンドを実行して Webhook 構成を取得します。CONFIGURATION_NAME は、Webhook 構成の名前に置き換えます。kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yamlこのコマンドが何も返さない場合は、
validatingwebhookconfigurationsをmutatingwebhookconfigurationsに置き換えてコマンドを再実行します。webhooksセクションに 1 つ以上の Webhook が表示されます。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: 3Webhook が特定の名前空間でのみ動作するように、
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-leaseWebhook が特定の名前空間でのみ動作するように、
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' - 'subjectacessreviews' - 'certificatesigningrequests' scope: '*' sideEffects: None timeoutSeconds: 3リソース セクションから
nodes、tokenreviews、subjectaccessreviews、certificatesigningrequestsを削除します。podsはresourcesに保持できます。