このページでは、Google Distributed Cloud の Kubernetes API サーバー（kube-apiserver）の問題を解決する方法について説明します。
このページは、基盤となるテクノロジー インフラストラクチャのライフサイクルを管理し、サービスレベル目標（SLO）が達成されていない場合やアプリケーションで障害が発生した場合にアラートやページに対応する IT 管理者とオペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。Webhook のタイムアウトと失敗した Webhook の呼び出し
これらのエラーは、いくつかの異なる方法で発生する場合があります。次のいずれかの症状が発生した場合、Webhook 呼び出しが失敗する可能性があります。
接続の拒否:
kube-apiserverが Webhook を呼び出しのタイムアウト エラーを報告する場合、次のエラーがログに報告されます。failed calling webhook "server.system.private.gdc.goog": failed to call webhook: Post "https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s": dial tcp 10.202.1.18:443: connect: connection refusedコンテキストの期限を超過している: ログに次のエラーも報告されることがあります。
failed calling webhook "namespaces.hnc.x-k8s.io": failed to call webhook: Post "https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\": context deadline exceeded"
Webhook のタイムアウトまたは Webhook 呼び出しの失敗が発生していると思われる場合は、次のいずれかの方法で問題を確認します。
API サーバーのログを調べて、ネットワークの問題があるかどうかを確認します。
TLS handshake errorのようなネットワーク関連のエラーについてログを確認します。- IP / ポートが、API サーバーが応答するように構成されているものと一致するかどうかを確認します。
次の手順で Webhook レイテンシをモニタリングします。
コンソールで、[Cloud Monitoring] ページに移動します。
[Metrics Explorer] を選択します。
apiserver_admission_webhook_admission_duration_seconds指標を選択します。
この問題を解決するには、次のことを確認してください。
Webhook に追加のファイアウォール ルールが必要になる場合があります。詳細については、特定のユースケースに対するファイアウォール ルールを追加する方法をご覧ください。
Webhook を完了するのにさらに時間がかかる場合は、カスタム タイムアウト値を構成できます。Webhook のレイテンシは API リクエストのレイテンシに追加されるため、できるだけ迅速に評価する必要があります。
Webhook エラーによってクラスタの可用性が妨げられる場合、または Webhook を削除しても害はなく問題が軽減される場合は、一時的に
failurePolicyをIgnoreに設定するか、問題の Webhook を削除することが可能かどうかを確認してください。
API サーバー ダイヤル障害またはレイテンシ
このエラーは、次のようないくつかの方法で観測される可能性があります。
外部名前解決に関するエラー: 外部クライアントからメッセージに
lookupを含むエラーが返される場合があります。次に例を示します。dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such hostこのエラーは、クラスタ内で実行されているクライアントには適用されません。Kubernetes Service IP が挿入されるため、解決する必要はありません。
ネットワーク エラー: クライアントが次の例のように API サーバーにダイヤルしようとすると、汎用ネットワーク エラーを出力する場合があります。
dial tcp 10.96.0.1:443: connect: no route to host dial tcp 10.96.0.1:443: connect: connection refused dial tcp 10.96.0.1:443: connect: i/o timeoutAPI サーバーへの高レイテンシの接続: API サーバーへの接続は成功する場合がありますが、クライアント側でリクエストがタイムアウトします。このシナリオでは、クライアントは通常、
context deadline exceededを含むエラー メッセージを出力します。
API サーバーへの接続が完全に失敗した場合は、クライアントがエラーを報告したのと同じ環境内で接続を試みます。次のように、Kubernetes エフェメラル コンテナを使用して、既存の Namespace にデバッグ コンテナを挿入できます。
問題のあるクライアントが実行されている場所から、
kubectlを使用して詳細度の高いリクエストを実行します。たとえば、/healthzに対するGETリクエストは通常、認証を必要としません。kubectl get -v999 --raw /healthzリクエストが失敗したか、
kubectlを使用できない場合は、出力から URL を取得して、curlでリクエストを手動で実行できます。たとえば、以前の出力から取得したサービスホストがhttps://192.0.2.1:36917/の場合、次のような同様のリクエストを送信できます。# Replace "--ca-cert /path/to/ca.pem" to "--insecure" if you are accessing # a local cluster and you trust the connection cannot be tampered. # The output is always "ok" and thus contains no sensentive information. curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthzこのコマンドの出力は通常、失敗した接続の根本原因を示します。
接続に成功しても、速度が遅かったりタイムアウトになった場合は、API サーバーの負荷が過剰であることを示します。コンソールで確認するには、
API Server Request Rateを確認して、Cloud Kubernetes > Anthos > Cluster > K8s Control Planeにレイテンシ指標をリクエストします。
これらの接続障害またはレイテンシの問題を解決するには、次の修復オプションを確認してください。
クラスタ内でネットワーク エラーが発生した場合は、Container Network Interface（CNI）プラグインに問題がある場合があります。通常、この問題は一時的なものであり、Pod の再作成または再スケジューリング後に自然に解決されます。
ネットワーク エラーがクラスタ外部からのものである場合は、クライアントがクラスタにアクセスするように正しく構成されているかを確認するか、クライアント構成を再度生成します。接続がプロキシまたはゲートウェイを通過する場合は、同じメカニズムを通過する別の接続が機能するかどうかを確認します。
API サーバーが過負荷状態になる場合、通常、多数のクライアントが同時に API サーバーにアクセスしていることを意味します。スロットル機能と優先度と公平性機能により、1 つのクライアントで API サーバーが過負荷状態になることはありません。次の領域についてワークロードを確認します。
- Pod レベルで機能する。上位レベルのリソースに誤って Pod を作成して、それを忘れてしまうことがよくあります。
- 誤った計算によるレプリカの数を調整する。
- Webhook がリクエストをそれ自体にループバックするか、処理量よりも多いリクエストが作成され、負荷が増幅します。