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

本頁面說明如何找出並解決叢集自動調度器未在 Google Kubernetes Engine (GKE) 叢集中調度節點的問題。

本頁內容適用於應用程式開發人員 (想解決應用程式或服務的非預期或負面情況)，以及平台管理員和營運人員 (想避免產品和服務的交付作業中斷)。

瞭解叢集自動配置器何時會調度節點資源

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

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

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

檢查是否有無法排程的 Pod

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

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

   前往「Workloads」(工作負載)

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

   如果列出任何 Pod，表示您有無法排程的 Pod。如要排解無法排程的 Pod 問題，請參閱「錯誤：Pod 無法排程」。解決 Pod 無法排程的根本原因，通常可以讓叢集自動調度器向上擴充。如要找出並解決叢集自動調度器專屬的錯誤，請參閱下列各節。

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

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

如要調查過去導致叢集自動調度資源失敗的原因，請檢查先前無法排程的 Pod：

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

   前往記錄檔探索工具

2. 指定要查看的記錄項目時間範圍。

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

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

   將 PROJECT_ID 替換為您的專案 ID。

4. 點選「執行查詢」

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

檢查問題是否由限制所致

確認有未排程的 Pod 後，請檢查叢集自動調度資源功能的問題是否是由叢集自動調度資源功能的限制所導致。

查看錯誤

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

• 如果已看到錯誤訊息，請參閱錯誤訊息表，瞭解如何解決錯誤。

• 如果尚未收到訊息，請使用下列任一選項：

  • 發生不到 72 小時的問題：在 Google Cloud 控制台中查看錯誤通知。
  • 超過 72 小時的問題：在 Cloud Logging 中查看事件中的錯誤。

在通知中查看錯誤

如果觀察到的問題發生時間未滿 72 小時，請在 Google Cloud 控制台中查看錯誤通知。這些通知可提供實用的洞察資訊，協助您瞭解叢集自動調度資源無法向上擴充的原因，並提供解決錯誤的建議，以及查看相關記錄以進行深入調查。

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

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

   前往 Kubernetes 叢集

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

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

3. 按一下相關通知，即可查看窗格，瞭解造成問題的原因，以及解決問題的建議做法。

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

如果按照通知中的建議操作後仍遇到問題，請參閱錯誤訊息表格，取得進一步協助。

查看活動中的錯誤

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

如要在 Google Cloud 控制台中查看叢集自動調度器記錄，請完成下列步驟：

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

   前往 Kubernetes 叢集

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

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

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 都有相同的原因訊息 ID "no.scale.up.mig.failing.predicate"，並包含兩個參數："NodeAffinity" 和 "node(s) did not match node selector"。

解決方法：

查閱錯誤訊息清單後，您發現叢集自動配置器無法向上擴充節點集區，因為擱置中的 Pod 無法排定述語。這些參數是失敗述詞的名稱，以及失敗原因。

如要解決這個問題，請檢查 Pod 的資訊清單，並找出與叢集中任何 MIG 不符的節點選取器。從 Pod 的資訊清單中刪除選取器，然後重新建立 Pod。叢集自動調度器會新增節點，並排定 Pod。

解決擴充錯誤

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

ScaleUp 錯誤

您可以在對應的 eventResult 事件中，於 resultInfo.results[].errorMsg 欄位查看 scaleUp 事件的錯誤訊息。

noScaleUp 事件的原因

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

NoScaleUp 頂層原因

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

NoScaleUp 頂層節點自動佈建原因

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

NoScaleUp MIG 層級原因

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

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

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

進行進一步調查

下列各節提供指引，說明如何使用記錄檔探索工具和 gcpdiag，進一步瞭解錯誤。

在記錄檔探索工具中調查錯誤

如要進一步調查錯誤訊息，請查看與錯誤相關的記錄：

1. 前往 Google Cloud 控制台的「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 是由技術工程師協助打造的開放原始碼工具。 Google Cloud這並非正式支援的 Google Cloud 產品。

如果遇到下列任一則錯誤訊息，請使用 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 不適合節點

只有在節點有足夠的 GPU、記憶體和儲存空間等資源，可滿足 Pod 的需求時，叢集自動調度器才會將 Pod 排程到節點上。如要判斷這是否為叢集自動配置器未向上擴充的原因，請比較資源要求與提供的資源。

下列範例說明如何檢查 CPU 資源，但同樣的步驟也適用於 GPU、記憶體和儲存空間資源。如要比較 CPU 要求與已佈建的 CPU，請完成下列步驟：

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

   前往「Workloads」(工作負載)

2. 按一下 PodUnschedulable 錯誤訊息。

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

4. 在「Pod 詳細資料」頁面中，前往「事件」分頁。

5. 從「Events」(事件) 分頁前往「YAML」分頁。

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

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

7. 從具有未排程 Pod 的叢集查看節點集區詳細資料：

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

      前往 Kubernetes 叢集

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

   3. 在「叢集詳細資料」頁面中，前往「節點」分頁。

8. 在「節點集區」區段中，記下「機器類型」欄中的值。例如：n1-standard-1。

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

另請注意，節點的可分配資源少於總資源，因為系統元件需要部分資源才能運作。如要進一步瞭解計算方式，請參閱「節點可分配資源」。

如要解決這個問題，請判斷為工作負載定義的資源要求是否符合您的需求。如果不需要變更機器類型，請建立節點集區，並使用可支援 Pod 要求的機器類型。如果 Pod 資源要求不準確，請更新 Pod 的定義，讓 Pod 能在節點上運作。

問題：叢集健康狀態不良，導致無法向上擴充

如果叢集自動配置器認為叢集狀況不佳，可能就不會執行向上擴充作業。叢集健康狀態不佳並非因為控制層健康狀態良好，而是因為健康和就緒節點的比例。如果叢集中有 45% 的節點狀況不佳或未準備就緒，叢集自動調度器就會停止所有作業。

如果這是叢集自動配置器無法向上擴充的原因，叢集自動配置器 ConfigMap 中會有類型為 Warning 的事件，且 ClusterUnhealthy 會列為原因。

如要查看 ConfigMap，請執行下列指令：

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

如要解決這個問題，請減少狀況不良的節點數量。

部分節點可能已準備就緒，但叢集自動配置器不會將其視為就緒。如果節點上存在前置字串為 ignore-taint.cluster-autoscaler.kubernetes.io/ 的汙點，就會發生這種情況。只要存在該 taint，叢集自動調度器就會將節點視為 NotReady。

如果行為是由 ignore-taint.cluster-autoscaler.kubernetes.io/.* 汙染所致，請移除該汙染。

後續步驟

• 請參閱 Kubernetes 叢集自動調整功能常見問題。

• 觀看 YouTube 影片，瞭解如何排解及解決縮放問題。

• 如果無法在說明文件中找到問題的解決方法，請參閱「取得支援」一文，尋求進一步的協助， 包括下列主題的建議：

  • 與 Cloud 客戶服務聯絡，建立支援案件。
  • 在 StackOverflow 上提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。你也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
  • 使用公開問題追蹤工具回報錯誤或提出功能要求。