排解 Kubernetes API 伺服器問題

本頁說明如何解決 Google Distributed Cloud 的 Kubernetes API 伺服器 (kube-apiserver) 問題。

本文適用於 IT 管理員和營運人員，他們負責管理基礎技術架構的生命週期，並在服務等級目標 (SLO) 未達成或應用程式發生故障時，回應快訊和頁面。如要進一步瞭解內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。 Google 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

  • Context deadline exceeded：您也可能會在記錄中看到以下錯誤：

    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 伺服器設定的回應方式相符。

  • 如要監控網路鉤子延遲時間，請按照下列步驟操作：

    1. 前往控制台的 Cloud Monitoring 頁面。

      前往 Cloud Monitoring 頁面

    2. 選取「指標探索工具」。

    3. 選取 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 服務 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 timeout

  • 連線至 API 伺服器的延遲時間過長：連線至 API 伺服器可能成功，但用戶端的要求會逾時。在這種情況下，用戶端通常會列印含有 context deadline exceeded 的錯誤訊息。

如果與 API 伺服器的連線完全失敗，請在用戶端回報錯誤的相同環境中嘗試連線。Kubernetes 臨時容器可用於將偵錯容器插入現有命名空間，方法如下：

  1. 從有問題的用戶端執行位置，使用 kubectl 執行詳細程度高的要求。舉例來說，對 /healthz 的 GET 要求通常不需要驗證：

    kubectl get -v999 --raw /healthz

  2. 如果要求失敗或 kubectl 無法使用，您可以從輸出內容取得網址，然後使用 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 後就會自行解決。

  • 如果網路錯誤來自叢集外部，請檢查用戶端是否已正確設定叢集存取權，或再次產生用戶端設定。如果連線是透過 Proxy 或閘道建立，請檢查透過相同機制建立的其他連線是否正常運作。

  • 如果 API 伺服器負載過重，通常表示許多用戶端同時存取 API 伺服器。由於節流和「優先順序和公平性」功能，單一用戶端無法使 API 伺服器過載。請檢查下列領域的工作負載：

    • 適用於 Pod 層級。相較於較高層級的資源，使用者更容易誤建及忘記 Pod。
    • 透過錯誤的計算調整備用資源數量。
    • Webhook 會將要求迴圈傳回自身，或建立比處理量更多的要求，藉此放大負載。

後續步驟

如需其他協助，請與 Cloud Customer Care 團隊聯絡。

如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：