このページでは、Google Distributed Cloud Virtual for Bare Metal の Kubernetes API サーバー（kube-apiserver）の問題を解決する方法について説明します。
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 エフェメラル コンテナを使用して、既存の名前空間にデバッグ コンテナを挿入できます。
問題のあるクライアントが実行されている場所から、
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 がリクエストをそれ自体にループバックするか、それが処理するよりも多くのリクエストを作成して、負荷を増幅します。