排解叢集自動配置器無法向上擴充的問題

如果 Google Kubernetes Engine (GKE) 中的 Pod 停滯在 Pending 狀態，且系統未新增節點，通常表示叢集自動調整程式的擴充功能有問題。這個問題可能會導致應用程式無法擴充以滿足需求、延遲部署作業，並影響服務可用性。

您可以使用這個頁面診斷及解決常見問題，避免叢集自動配置器無法新增節點。修正這些問題後，Kubernetes 排程器就能及時安排工作負載，並協助叢集適應增加的負載。

這項資訊對應用程式開發人員來說非常重要，因為他們需要應用程式和服務排定及執行工作負載，而平台管理員和營運人員則負責確保叢集能動態佈建資源，以滿足工作負載需求並維持服務等級。如要進一步瞭解 Cloud de Confiance by S3NS 內容中提及的常見角色和工作範例，請參閱「常見的 GKE 使用者角色和工作」。

瞭解叢集自動配置器何時會擴充節點

繼續進行疑難排解步驟之前，建議先瞭解叢集自動配置器何時會嘗試擴大節點。只有在現有資源不足時，叢集自動配置器才會新增節點。

叢集自動配置器每 10 秒會檢查是否有無法排定的 Pod。如果 Kubernetes 排程器因資源不足、節點限制或 Pod 需求未滿足，而無法將 Pod 放在任何現有節點上，Pod 就會變成無法排程。

當叢集自動配置器發現無法指派的 Pod 時，會評估新增節點是否能讓 Pod 順利指派。如果新增節點可讓 Pod 排定，叢集自動配置器就會在代管執行個體群組 (MIG) 中新增節點。Kubernetes 排程器隨後就能在新佈建的節點上安排 Pod。

檢查是否有無法排定的 Pod

如要判斷叢集是否需要向上擴充，請檢查是否有未排定的 Pod：

  1. 前往 Cloud de Confiance 控制台的「Workloads」(工作負載) 頁面。

    前往「Workloads」(工作負載)

  2. 在 「Filter」(篩選器) 欄位中，輸入 unschedulable，然後按下 Enter 鍵。

    如果畫面上列出任何 Pod，表示有無法排定的 Pod。如要排解無法排程的 Pod 問題，請參閱「錯誤：Pod 無法排程」。解決 Pod 無法排程的根本原因，通常就能讓叢集自動配置器向上擴充。如要找出並解決叢集自動配置器特有的錯誤，請參閱下列各節。

    如果沒有列出任何 Pod，表示叢集自動配置器不需要向上擴充，且運作正常。

檢查先前是否有無法排程的 Pod

如要調查叢集自動配置器過去失敗的原因，請檢查先前無法排定的 Pod：

  1. 前往 Cloud de Confiance 控制台的「Logs Explorer」頁面。

    前往 Logs Explorer

  2. 指定要查看的記錄項目日期範圍。

  3. 在查詢窗格中，輸入下列查詢：

    logName="projects/PROJECT_ID/logs/events"
jsonPayload.source.component="default-scheduler"
jsonPayload.reason="FailedScheduling"

    將 PROJECT_ID 替換為專案 ID。

  4. 點選「執行查詢」。

    如果列出任何結果，表示您在指定日期範圍內有無法排程的 Pod。

確認問題是否由限制造成

確認有未排定的 Pod 後，請確認叢集自動配置器的問題並非由叢集自動配置器的限制所造成。

分析 Cloud Monitoring 指標，找出擴充問題

GKE 叢集自動配置器會將指標公開給 Cloud Monitoring，提供決策深入分析資料，特別是與 ComputeClass 相關的資料。這些指標適用於 GKE 1.37 以上版本，包括：

  • 待處理 Pod：kubernetes.io/autoscaler/cluster_pending_pods_per_ccc 顯示自動配置器嘗試排程的 Pod。
  • 佈建嘗試：kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc 追蹤自動配置器嘗試新增節點的頻率。
  • 佈建失敗：kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc 顯示節點建立嘗試失敗的原因。

這些指標使用 k8s_entity 資源類型，其中 resource.labels.entity_type 欄位的值為 ComputeClass。resource.labels.entity_name 欄位的值代表 ComputeClass 名稱。如果 entity_name 欄位的值為空字串 ("")，則指標適用於與 ComputeClass 無關的叢集自動配置器決策。

使用 Metrics Explorer，依 entity_name 欄位篩選及分組結果。例如，使用 resource.labels.entity_name = "" 字串查看與 ComputeClasses 無關的活動，並使用指標標籤 (例如 reason) 瞭解擴充問題是否為 ComputeClass 專屬。

如需查詢範例，請參閱「監控節點佈建」和「監控待處理的 Pod 狀態」。

查看錯誤

您通常可以透過查看錯誤訊息，診斷擴充問題的原因：

查看通知中的錯誤

如果問題發生在 72 小時內，請在 Cloud de Confiance 控制台查看錯誤通知。這些通知可提供寶貴的洞察資料，協助您瞭解叢集自動配置器無法向上擴充的原因，並提供解決錯誤的建議，以及查看相關記錄以進行深入調查。

如要在 Cloud de Confiance 控制台中查看通知，請完成下列步驟：

  1. 前往 Cloud de Confiance 控制台的「Kubernetes clusters」(Kubernetes 叢集) 頁面。

    前往「Kubernetes clusters」(Kubernetes 叢集)

  2. 查看「通知」欄。下列通知與擴充問題有關：

    • Can't scale up
    • Can't scale up pods
    • Can't scale up a node pool

  3. 按一下相關通知，即可查看窗格，瞭解問題原因和應變措施建議。

  4. 選用：如要查看這項事件的記錄，請按一下「記錄」。這項操作會將您導向 Logs Explorer，並預先填入查詢，協助您進一步調查資源調度事件。如要進一步瞭解擴充事件的運作方式，請參閱「查看叢集自動配置器事件」。

如果查看通知中的建議後仍有問題，請參閱錯誤訊息表格，取得進一步協助。

查看事件中的錯誤

如果觀察到的問題發生在 72 小時前，請在 Cloud Logging 中查看事件。發生錯誤時，系統通常會記錄在事件中。

如要在 Cloud de Confiance 控制台中查看叢集自動配置器記錄檔，請完成下列步驟：

  1. 在 Cloud de Confiance 控制台中，前往「Kubernetes clusters」(Kubernetes 叢集) 頁面。

    前往 Kubernetes 叢集

  2. 選取要調查的叢集名稱，即可查看「叢集詳細資料」頁面。

  3. 在「Cluster details」(叢集詳細資料) 頁面中，按一下「Logs」(記錄) 分頁標籤。

  4. 在「記錄」分頁中，按一下「自動配置器記錄」分頁，即可查看記錄。

  5. 選用：如要套用更進階的篩選器來縮小結果範圍，請按一下頁面右側的箭頭按鈕，在記錄檔探索工具中查看記錄。

如要進一步瞭解擴充事件的運作方式，請參閱「查看叢集自動配置器事件」。如要瞭解如何使用 Cloud Logging，請參閱下列疑難排解範例。

範例：排解 72 小時前發生的問題

以下範例說明如何調查及解決叢集無法擴充的問題。

情境：過去一小時內，某個 Pod 標示為無法指派。叢集自動調整器未佈建任何新節點來排程 Pod。

解決方法：

  1. 由於問題發生時間超過 72 小時，因此您使用 Cloud Logging 進行調查，而不是查看通知訊息。
  2. 在 Cloud Logging 中，您可以找到叢集自動配置器事件的記錄詳細資料，如「查看事件中的錯誤」一節所述。

  3. 您在 triggeringPods 欄位中搜尋包含要調查的 Pod 的 scaleUp 事件。您可以篩選記錄項目，包括依特定 JSON 欄位值篩選。詳情請參閱「進階記錄查詢」。

  4. 找不到任何擴充事件。不過，如果您這麼做，可以嘗試找出與 scaleUp 事件包含相同 eventId 的 EventResult。然後查看 errorMsg 欄位，並參閱可能的 scaleUp 錯誤訊息清單。

  5. 由於您找不到任何 scaleUp 事件，因此繼續搜尋 noScaleUp 事件，並查看下列欄位：

    • unhandledPodGroups：包含 Pod (或 Pod 控制器) 的相關資訊。
    • reason：提供全域原因，指出擴充作業可能遭到封鎖。
    • skippedMigs：說明系統可能略過部分 MIG 的原因。

  6. 您找到 Pod 的 noScaleUp 事件，且 rejectedMigs 欄位中的所有 MIG 都有相同的 "no.scale.up.mig.failing.predicate" 原因訊息 ID，並包含兩個參數："NodeAffinity" 和 "node(s) did not match node selector"。

解決方法：

查看錯誤訊息清單後，您發現叢集自動配置器無法向上擴充節點集區，因為待處理 Pod 的排程述詞失敗。參數是失敗述詞的名稱和失敗原因。

為解決這個問題，您查看 Pod 的資訊清單，發現其節點選取器與叢集中的任何 MIG 都不相符。您從 Pod 的資訊清單中刪除選取器，並重新建立 Pod。叢集自動配置器會新增節點，並排定 Pod。

解決擴充錯誤

如果您使用自訂 ComputeClass，且擴充問題與 ComputeClass 中定義的特定節點設定有關，請參閱「排解自訂 ComputeClass 問題」。

找出錯誤後，請參閱下表，瞭解錯誤原因和解決方法。

ScaleUp 錯誤

您可以在對應的 eventResult 事件中，透過 resultInfo.results[].errorMsg 欄位找到 scaleUp 事件的事件錯誤訊息。

如果擴充作業因超出配額而失敗，則會發生節點建立錯誤，觸發系統輪詢延遲期，最長可達 30 分鐘。詳情請參閱「延遲期」。

訊息 詳細資料 參數 緩解措施
"scale.up.error.out.of.resources" 當您嘗試在某個可用區要求新資源，但該可用區目前無法提供 Compute Engine 資源 (例如 GPU 或 CPU)，因而無法滿足您的要求時，就會發生資源錯誤。 失敗的 MIG ID。 請按照 Compute Engine 說明文件中的資源可用性疑難排解步驟操作。
"scale.up.error.quota.exceeded" 由於超出 Compute Engine 配額，部分 MIG 無法增加，因此 scaleUp 事件失敗。 失敗的 MIG ID。 在 Cloud de Confiance 控制台中，查看 MIG 的「Errors」(錯誤) 分頁，瞭解超出哪項配額。瞭解超出配額後，請按照操作說明要求提高配額。
"scale.up.error.waiting.for.instances.timeout" 代管執行個體群組因逾時而無法向上擴充。 失敗的 MIG ID。 如果執行個體可以啟動，但無法向控制層註冊，請按照執行個體註冊疑難排解步驟操作。這則訊息應該只是暫時出現。
"scale.up.error.ip.space.exhausted" 部分代管執行個體群組中的執行個體用盡 IP，因此無法向上擴充。這表示叢集沒有足夠的未分配 IP 位址空間，無法用於新增節點或 Pod。 失敗的 MIG ID。 請按照「Pod 的可用 IP 位址空間不足」中的疑難排解步驟操作。
"scale.up.error.service.account.deleted" 服務帳戶已刪除，因此無法向上擴充。 失敗的 MIG ID。 請嘗試取消刪除服務帳戶。

noScaleUp 事件的原因

如果叢集內有無法排定的 Pod，且叢集自動配置器無法擴充叢集來排定 Pod，系統就會定期發出 noScaleUp 事件。noScaleUp 事件會盡可能提供資訊，但無法涵蓋所有可能情況。

NoScaleUp 頂層原因

noScaleUp 事件的頂層原因訊息會顯示在 noDecisionStatus.noScaleUp.reason 欄位中。訊息會說明叢集自動配置器無法向上擴充叢集的頂層原因。

訊息 詳細資料 緩解措施
"no.scale.up.in.backoff" 不向上擴充，因為向上擴充處於輪詢延遲期間 (暫時遭到封鎖)。如果擴充事件涉及大量 Pod，就可能出現這則訊息。 這則訊息應該只是暫時出現。請過幾分鐘後再查看這項錯誤。

NoScaleUp 頂層自動佈建節點原因

noScaleUp 事件的頂層自動佈建節點原因訊息會顯示在 noDecisionStatus.noScaleUp.napFailureReason 欄位中。訊息包含叢集自動配置器無法佈建新節點集區的頂層原因。

訊息 詳細資料 緩解措施
"no.scale.up.nap.disabled"

節點自動佈建功能無法向上擴充，因為叢集層級未啟用節點自動佈建功能。

如果停用自動佈建節點功能，當待處理的 Pod 有任何現有節點集區無法滿足的需求時，系統就不會自動佈建新節點。

 檢查叢集設定，並考慮啟用自動佈建節點。

NoScaleUp MIG 層級原因

noScaleUp 事件的 MIG 層級原因訊息會顯示在 noDecisionStatus.noScaleUp.skippedMigs[].reason 和 noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason 欄位中。訊息會說明叢集自動配置器無法增加特定 MIG 大小的原因。

訊息 詳細資料 參數 緩解措施
"no.scale.up.mig.skipped" 模擬期間略過 MIG，因此無法向上擴充。 略過 MIG 的原因 (例如缺少 Pod 需求)。 查看錯誤訊息中的參數，並解決 MIG 遭略過的問題。
"no.scale.up.mig.failing.predicate" 無法排定述語，因此無法向上擴充節點集區 待處理的 Pod。 失敗述詞的名稱和失敗原因。 查看 Pod 規定，例如相依性規則、taint 或容許條件，以及資源需求。

NoScaleUp Pod 群組層級自動佈建節點原因

noScaleUp 事件的 Pod 群組層級自動佈建節點原因訊息會顯示在 noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[] 欄位中。訊息會說明叢集自動配置器無法佈建新節點集區，來排定特定 Pod 群組的原因。

訊息 詳細資料 參數 緩解措施
"no.scale.up.nap.pod.gpu.no.limit.defined" 待處理的 Pod 有 GPU 要求，但未在叢集層級定義 GPU 資源限制，因此自動佈建節點功能無法佈建任何節點群組。 要求的 GPU 類型。 查看待處理 Pod 的 GPU 要求，並更新叢集層級自動佈建節點設定的 GPU 限制。
"no.scale.up.nap.pod.gpu.type.not.supported" Pod 要求不明的 GPU 類型，因此自動佈建節點功能未佈建任何節點群組。 要求的 GPU 類型。 檢查擱置中 Pod 的 GPU 類型設定，確保與支援的 GPU 類型相符。
"no.scale.up.nap.pod.zonal.resources.exceeded" 節點自動佈建功能並未針對這個可用區內的 Pod 佈建任何節點群組，因為這麼做會違反整個叢集的資源上限、超出可用區內的可用資源，或沒有符合要求的機型。 考量區域的名稱。 查看及更新整個叢集的資源上限、Pod 資源要求，或自動佈建節點功能的可用區。
"no.scale.up.nap.pod.zonal.failing.predicates" 節點自動佈建功能並未針對這個可用區內因述語不能正常運作而擱置中的 Pod 佈建任何節點群組。 所考量的區域名稱，以及述詞失敗的原因。 查看待處理 Pod 的規定，例如相依性規則、taint、容許條件或資源需求。

進一步調查

下列各節將說明如何使用 Logs Explorer 和 gcpdiag，進一步瞭解錯誤。

在 Logs Explorer 中調查錯誤

如要進一步調查錯誤訊息，請查看錯誤專屬的記錄：

  1. 前往 Cloud de Confiance 控制台的「Logs Explorer」頁面。

    前往 Logs Explorer

  2. 在查詢窗格中，輸入下列查詢：

    resource.type="k8s_cluster"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"

    將 ERROR_MESSAGE 替換為要調查的訊息。例如：scale.up.error.out.of.resources。

  3. 點選「執行查詢」。

使用 gcpdiag 對部分錯誤進行偵錯

gcpdiag 是由 Cloud de Confiance by S3NS 技術工程師協助建立的開放原始碼工具。這項產品並未獲得官方支援。 Cloud de Confiance by S3NS

如果看到下列任一錯誤訊息，可以使用 gcpdiag 協助排解問題：

  • scale.up.error.out.of.resources
  • scale.up.error.quota.exceeded
  • scale.up.error.waiting.for.instances.timeout
  • scale.up.error.ip.space.exhausted
  • scale.up.error.service.account.deleted

如需所有 gcpdiag 工具旗標的清單和說明，請參閱 gcpdiag 使用說明。

解決複雜的擴充錯誤

以下各節有助於解決需要多個步驟的錯誤，或沒有叢集自動配置器相關聯事件訊息的錯誤。

Pod 不適合節點

問題：

Pod 仍處於 Pending 狀態並顯示 PodUnschedulable 錯誤訊息，或叢集顯示 Pods unschedulable 錯誤訊息，且叢集自動配置器不會擴充來新增節點。

原因：

只有在機型提供足夠的資源 (例如 CPU、GPU、記憶體和儲存空間) 給待處理的 Pod 時，叢集自動配置器才會將節點新增至節點集區。如果 Pod 的資源要求超過單一節點的資源，叢集自動配置器就不會向上擴充，因為 Pod 仍無法容納於新節點。

此外，節點的可分配資源少於總資源，因為系統元件會保留部分資源。如要進一步瞭解 GKE 如何計算可分配的資源，請參閱「節點可分配的資源」。

解決方法：

如要檢查 Pod 的資源要求是否超出節點提供的資源，並解決問題，請完成下列步驟。這個範例會檢查 CPU 資源，但同樣的步驟也適用於 GPU、記憶體和儲存空間資源：

  1. 前往 Cloud de Confiance 控制台的「Workloads」(工作負載) 頁面。

    前往「Workloads」(工作負載)

  2. 按一下「PodUnschedulable」錯誤訊息。

  3. 在「Details」(詳細資料) 窗格中，按一下 Pod 名稱。如有數個 Pod，請從第一個 Pod 開始，然後為每個 Pod 重複下列程序。

  4. 在「Pod details」(Pod 詳細資料) 頁面上，按一下「YAML」分頁標籤。

  5. 請記下 Pod 中每個容器的資源要求，以找出資源要求總量。舉例來說，在下列 Pod 設定中，Pod 需要 2 個 vCPU：

    resources:
  limits:
    cpu: "3"
  requests:
    cpu: "2"

  6. 查看含有未排程 Pod 的叢集節點集區詳細資料：

    1. 前往 Cloud de Confiance 控制台的「Kubernetes clusters」(Kubernetes 叢集) 頁面。

      前往「Kubernetes clusters」(Kubernetes 叢集)

    2. 按一下顯示 Pods unschedulable 錯誤訊息的叢集名稱。

    3. 在「Cluster details」(叢集詳細資料) 頁面中，按一下「Nodes」(節點) 分頁標籤。

    4. 在「節點集區」部分，記下「機型」欄中的值，例如 n1-standard-1。

  7. 比較資源要求與機器類型提供的 vCPU。舉例來說，如果 Pod 要求 2 個 vCPU，但可用節點使用 n1-standard-1 機型，則節點只有 1 個 vCPU。使用這類設定時，叢集自動調度器不會觸發向上擴充，因為 Pod 仍無法容納新節點。如要進一步瞭解可用的機型，請參閱 Compute Engine 說明文件中的「機器家族資源和比較指南」。

  8. 根據工作負載需求解決不符問題：

    • 如果 Pod 需要要求的資源：請建立節點集區，並使用可支援 Pod 資源要求的機型。
    • 如果 Pod 的資源要求不正確：請更新 Pod 的定義，讓 Pod 能容納在現有節點中。

健康狀態不良的叢集會阻礙向上擴充

症狀：

叢集自動配置器會停止所有資源調度作業，且 cluster-autoscaler-status ConfigMap 包含類型為 Warning 的事件，並列出 ClusterUnhealthy 做為原因。

如要查看 cluster-autoscaler-status ConfigMap，請執行下列指令：

kubectl describe configmap cluster-autoscaler-status -n kube-system

原因：

如果叢集自動配置器認為叢集健康狀態不良，就不會向上擴充。叢集自動配置器會根據健康且就緒的節點比例，而非控制層健康狀態，判斷叢集健康狀態。如果叢集中有 45% 的節點健康狀態不佳或未就緒，叢集自動配置器會停止所有作業。

如果節點具有 ignore-taint.cluster-autoscaler.kubernetes.io/ 前置字元的汙點，叢集自動配置器也會將該節點視為 NotReady。只要節點存在該汙點，叢集自動配置器就會將節點視為 NotReady。

解決方法：

如要解決這個問題，請採取下列其中一項或兩項行動，減少健康狀態不良的節點數量：

  • 調查並修復健康狀態不良或 NotReady 的節點，確保叢集中健康狀態不良的節點比例低於 45%。
  • 如果就緒節點含有前置字元為 ignore-taint.cluster-autoscaler.kubernetes.io/ 的污點，請移除該污點。

後續步驟