關於 GKE 叢集自動調度資源

Autopilot Standard

本頁面說明 Google Kubernetes Engine (GKE) 如何依據工作負載需求，自動調整 Standard 叢集的節點集區大小。當需求過高時，叢集自動配置器會在節點集區中新增節點。如要瞭解如何設定叢集自動配置器，請參閱「自動調度叢集資源」。

這個頁面適用於管理員、架構師和營運人員，他們負責規劃容量和基礎架構需求，並最佳化系統架構和資源，為公司或業務單位爭取最低的總持有成本。如要進一步瞭解 Google Cloud 內容中提及的常見角色和工作範例，請參閱「常見的 GKE 使用者角色和工作」。

使用 Autopilot 叢集時，您不必擔心佈建節點或管理節點集區的問題，因為節點集區會透過自動佈建節點功能自動佈建，並自動調度資源，以滿足工作負載的需求。

閱讀本頁內容前，請務必熟悉基本 Kubernetes 概念，以及資源要求和限制的運作方式。

最佳做法：

與貴組織的管理員和架構師、開發人員或其他負責實作及維護應用程式的團隊，共同規劃及設計叢集設定。

使用叢集自動配置器的原因

GKE 的叢集自動配置器會依據工作負載需求，自動調整指定節點集區中的節點數量。當需求較低時，叢集自動配置器會縮減叢集資源，直到您指定的大小下限。這樣一來，您就能在需要時提高工作負載的可用性，同時控制成本。您不需要手動新增或移除節點，也不必過度佈建節點集區。您只需要指定節點集區的大小上下限，其餘部分會由系統自動處理。

如果叢集自動調度資源時刪除或移動資源，工作負載可能會暫時中斷。舉例來說，如果工作負載包含一個具有單一副本的控制器，則當該副本目前的節點遭到刪除時，該副本的 Pod 可能會重新排程到其他節點。啟用叢集自動配置器之前，請先設計工作負載，使其能容忍潛在的中斷，或確保重要 Pod 不會中斷。

最佳做法：

如要提高工作負載的容錯能力，請使用具有多個副本的控制器 (例如 Deployment) 部署工作負載。

您可以使用映像檔串流功能，從符合資格的容器映像檔遠端串流必要的映像檔資料，同時在本機快取映像檔，讓新節點上的工作負載更快啟動，進而提升叢集自動配置器的效能。

叢集自動配置器的運作方式

叢集自動配置器會針對每個節點集區運作。使用叢集自動配置器設定節點集區時，您必須指定節點集區的大小上下限。

叢集自動配置器會透過在節點集區的基礎 Compute Engine 代管執行個體群組 (MIG) 中新增或移除虛擬機器 (VM) 執行個體，自動增加或減少節點集區的大小。叢集自動配置器會根據在該節點集區節點上執行的 Pod 的資源要求 (而非實際資源用量)，做出這些調度決策。這項服務會定期檢查 Pod 和節點的狀態，並採取行動：

• 如果 Pod 無法在任何現有節點上排程，叢集自動配置器就會新增節點，直到節點集區達到大小上限。如要進一步瞭解叢集自動配置器何時會變更叢集大小，請參閱「叢集自動配置器何時會變更叢集大小？」一文。
• 如果 GKE 決定在節點集區中新增節點，叢集自動配置器會視需要新增節點，但不得超過每個節點集區或每個叢集的限制。
• 叢集自動配置器不會等待一個節點啟動，再建立下一個節點。GKE 決定要建立的節點數量後，就會同時建立節點。目標是盡可能縮短無法排程的 Pod 成為 Active 的時間。
• 如果配額用盡而無法建立部分節點，叢集自動配置器會等到資源可順利調度為止。
• 如果節點未充分運用，且即使節點集區中的節點數量較少，所有 Pod 仍可排程，叢集自動配置器就會移除節點，直到節點集區達到最小大小為止。
• 如果節點上的 Pod 無法移至叢集中的其他節點，叢集自動配置器就不會嘗試縮減該節點。
• 如果 Pod 可以移至其他節點，但節點在逾時後無法正常排空，則會強制終止節點。GKE 1.32.7-gke.1079000 以上版本的逾時時間為一小時，較早版本則為 10 分鐘。GKE 叢集無法設定最大寬限期。如要進一步瞭解縮減作業的運作方式，請參閱開放原始碼說明文件中的叢集自動配置器常見問題，瞭解縮減作業的運作方式。

叢集自動配置器檢查叢集內無法排程的 Pod 頻率，主要取決於叢集大小。在小型叢集中，檢查可能每隔幾秒就會進行一次。這項檢查所需的時間範圍無法精確定義。

如果 Pod 要求的資源不足，或預設資源不足，導致節點資源短缺，叢集自動配置器不會修正這種情況。您可以為所有工作負載做出明確的資源要求，協助確保叢集自動配置器盡可能準確地運作。

請勿為叢集節點啟用 Compute Engine 代管執行個體群組的自動調度資源功能。GKE 的叢集自動配置器與 Compute Engine 自動調度資源功能不同。這可能導致節點集區無法擴充或縮減，因為 Compute Engine 自動配置器會與 GKE 的叢集自動配置器發生衝突。

作業條件

調整節點集區大小時，叢集自動調度器會做出下列假設：

• 所有複製的 Pod 都可以在其他節點上重新啟動，這可能會造成短暫中斷。
• 使用者或管理員不會手動管理節點。叢集自動配置器可以覆寫您執行的任何手動節點管理作業。
• 單一節點集區中的所有節點具有一組相同的標籤。
• 叢集自動配置器會考量各個集區中執行個體類型的相對成本，並嘗試擴充最便宜的節點集區。不過，叢集自動配置器的這項行為適用下列條件：
  • 叢集自動配置器會考量含有 Spot VM (可先占) 的節點集區，降低成本。不過，叢集自動配置器也會考量每個區域的資源可用性，因此可能會選擇較昂貴但可用的資源。
  • 如果有多個節點集區使用 Spot VM，叢集自動配置器不會自動選取成本最低的選項。為盡可能提高 Spot VM 的成本效益，並避免上述情況，建議您使用自訂運算類別。
• 叢集自動配置器會在排定 Pod 前，先考量 init 容器要求。初始化容器要求可以使用節點上任何未分配的資源，這可能會導致 Pod 無法排程。叢集自動調度器會遵循 Kubernetes 使用的相同要求計算規則。詳情請參閱 Kubernetes 說明文件中有關使用 init 容器的部分。
• 系統不會追蹤在初始叢集或節點集區建立後手動新增的標籤。叢集自動配置器建立的節點，會指派建立節點集區時以 --node-labels 指定的標籤。
• 在 GKE 1.21 版或更早版本中，叢集自動配置器會考量節點集區中現有節點的汙點資訊，代表整個節點集區。從 GKE 1.22 版開始，叢集自動配置器會結合叢集和節點集區中現有節點的資訊。叢集自動配置器也會偵測您對節點和節點集區進行的手動變更。

最佳做法：

如果應用程式無法容許中斷，請勿啟用叢集自動配置器。

跨區域平衡

如果節點集區包含多個具有相同執行個體類型的代管執行個體群組，叢集自動配置器會在擴充時嘗試保持這些代管執行個體群組大小平衡。這有助於避免節點集區中多個可用區的代管執行個體群組，出現節點分布不均的情況。GKE 縮減資源時，不會考量自動調度資源政策。

叢集自動配置器只會在擴充事件期間平衡各可用區的資源。叢集自動配置器會縮減使用率偏低的節點，無論節點集區中基礎代管執行個體群組的相對大小為何，這可能會導致節點在各可用區的分佈不均。

位置政策

從 GKE 1.24.1-gke.800 版開始，您可以變更叢集自動配置器的位置政策。您可以指定 location_policy 旗標，並使用下列任一值，控管叢集自動調度資源分配政策：

• BALANCED：這項政策會指示叢集自動配置器，在考量 Pod 需求 (例如相似度) 和資源可用性的同時，盡可能將節點集區資源平均分配到所選可用區。這項政策是使用預留項目或隨選節點的節點集區預設位置政策，但您也可以將其用於 Spot VM。彈性啟動佈建模式節點集區不支援 BALANCED。
• ANY：這項政策會指示叢集自動配置器，在所有指定可用區中搜尋要求的容量。叢集自動配置器會優先使用未使用的預留項目和容量充足的可用區，這可能會導致節點集區資源集中。這是彈性啟動佈建模式和使用 Spot VM 的節點集區的預設位置政策，但您也可以將其用於使用預留項目或隨選節點的節點集區。如要啟用這項政策，必須啟用自動調度資源功能，並將初始節點數量設為 0，讓自動配置器負責佈建所有節點。

最佳做法：

如果工作負載只使用現成的加速器資源，且分散在多個可用區可帶來好處 (例如提高容錯能力)，請使用 BALANCED 政策。使用 ANY 政策，優先使用未使用的預留項目，並提高稀缺運算資源 (例如加速器) 的運算容量彈性、效率和可用性。

預留項目

從 GKE 1.27 版開始，叢集自動調度器在決定擴充時，一律會考量預留項目。選擇要向上擴充的節點集區時，系統會優先選擇具有相符未使用預留項目的節點集區，即使該節點集區並非最有效率的節點集區也一樣。此外，在平衡多區域擴充時，系統一律會優先使用未使用的預留項目。

不過，叢集自動配置器只會檢查自身專案中的預留項目。因此，如果叢集自己的專案中有更便宜的節點選項，自動配置器可能會選擇該選項，而不是「共用」預留項目。如需跨專案共用預留項目，建議使用自訂運算類別，設定叢集自動配置器用於調度節點資源的優先順序，包括共用預留項目。

預設值

如果是 Spot VM 節點集區，預設叢集自動配置器分配政策為 ANY。在這項政策中，Spot VM 遭先占的風險較低。

對於不可搶占的節點集區，預設的叢集自動配置器分配政策為 BALANCED。

節點集區大小的上限與下限

建立新的節點集區時，您可以指定叢集中各個節點集區的大小上下限，叢集自動配置器會根據這些資源調度限制，決定是否要重新調度資源。如要更新最小值，請在指定新最小值後，手動將叢集大小調整至新限制範圍內。叢集自動配置器接著會根據新限制做出重新調度決策。

目前的節點集區大小	叢集自動配置器動作	調度限制
低於您指定的最低值	叢集自動調度器會向上擴充，以佈建擱置中的 Pod。縮減功能已停用。	節點集區不會縮減至低於您指定的值。
在您指定的大小範圍內	叢集自動配置器會視需求擴充或縮減資源。	節點集區會維持在您指定的大小限制內。
大於您指定的上限	叢集自動配置器只會縮減可安全移除的節點。已停用擴充功能。	節點集區不會擴充超過您指定的值。

在 Standard 叢集上，叢集自動配置器絕不會自動將叢集縮減至零個節點。叢集中必須一律有一或多個節點可用，才能執行系統 Pod。此外，如果節點數量因手動移除節點而為零，叢集自動配置器和節點自動佈建功能可以從零節點叢集向上擴充。

如要進一步瞭解自動配置器決策，請參閱「叢集自動配置器限制」。

GKE 如何處理邊界大小限制

如果外部變更或設定更新導致節點集區大小超出限制，叢集自動配置器不會主動強制節點集區維持在下限和上限範圍內。而是根據需求和安全檢查，隨時間調整大小。

下表說明 GKE 如何處理這些邊界條件：

邊界條件	自動配置器不會執行的動作	自動配置器的功能	常見觸發情境
目前大小低於下限 (例如目前 = 1，下限 = 3)	不會自動調高至最低值。	只有在無法排程 (待處理) 的 Pod 需要資源時，才會向上擴充。	當 --min-nodes 欄位的值高於目前的節點集區大小時，啟用自動調度資源功能。
目前大小高於上限 (例如目前 = 10，上限 = 5)	不會立即終止節點，以強制達到上限。	只有在節點未充分運用且可安全排空時，才會縮減規模。	啟用自動調度資源功能，且 --max-nodes 欄位的值低於目前的節點集區大小。

如要立即強制節點集區符合新的下限或上限，請手動將節點集區大小調整為新限制內的值。

自動調度資源限制

您可以設定叢集自動配置器在調度節點集區資源時，可使用的節點數量下限和上限。使用 --min-nodes 和 --max-nodes 旗標，設定每個可用區的節點數量下限和上限。

從 GKE 1.24 版開始，您可以使用新叢集的 --total-min-nodes 和 --total-max-nodes 旗標。這些旗標會設定所有可用區中，節點集區內節點總數的下限和上限。

此外，您可以使用 CapacityQuota 自訂資源，為符合標籤選取器的資源，定義 CPU 總量、記憶體或節點數量的上限。詳情請參閱「設定精細的資源限制」。

節點數下限和上限範例

下列指令會建立自動調度資源的多可用區叢集，一開始在三個可用區中共有六個節點，每個可用區至少有一個節點，最多有四個節點：

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

在本例中，叢集的總大小介於三個和十二個節點之間，分布在三個可用區。如果其中一個可用區故障，叢集的總大小可能介於 2 到 8 個節點之間。

節點總數範例

下列指令適用於 GKE 1.24 以上版本，可建立自動調整資源配置的多區域叢集，初始狀態為三個可用區各有兩個節點，節點集區在所有可用區的節點數量最少為三個，最多為十二個：

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

在本例中，無論節點在各區域間的分布情況為何，叢集的總大小都介於 3 到 12 個節點之間。

自動調度資源設定檔

如要判斷移除節點的時間點，應綜合評估使用率的最佳化成效與資源可用性。移除使用率偏低的節點可提高叢集使用率，但新的工作負載可能需要等到資源重新佈建後才能開始處理。

您可以指定要使用何種自動調度資源設定檔來做這類決策。 可用的設定檔包括：

• balanced：預設設定檔，會優先保留更多資源，供傳入的 Pod 隨時使用，進而縮短 Standard 叢集啟用 Pod 所需的時間。balanced 設定檔不適用於 Autopilot 叢集。
• optimize-utilization：比起在叢集中保留備用資源，優先考量最佳化使用率。啟用這個設定檔後，叢集自動配置器會更積極縮減叢集資源，GKE 可以移除更多節點，而且移除速度更快。GKE 偏好在 CPU、記憶體或 GPU 分配量較高的節點中排定 Pod。不過，其他因素會影響排程，例如屬於相同 Deployment、StatefulSet 或 Service 的 Pod 在節點間的分布情形。

optimize-utilization 自動調度資源設定檔可協助叢集自動配置器識別及移除使用率偏低的節點。為達成這項最佳化目標，GKE 會將 Pod 規格中的調度器名稱設為 gke.io/optimize-utilization-scheduler。指定自訂排程器的 Pod 不受影響。

下列指令會在現有叢集中啟用 optimize-utilization 自動調度資源設定檔：

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

考慮 Pod 的排程與服務中斷

縮減資源時，叢集自動配置器會遵循 Pod 上設定的排程和淘汰規則。這些限制可能會讓自動配置器無法刪除節點。如果節點包含的 Pod 具有下述任一情況，將無法刪除節點：

• Pod 的相依性或反相依性規則會阻止重新排程。
• Pod 並非由控制器 (如 Deployment、StatefulSet、Job 或 ReplicaSet) 所管理。
• Pod 具有本機儲存空間，且 GKE 控制層版本低於 1.22。在控制層版本為 1.22 以上的 GKE 叢集中，具有本機儲存空間的 Pod 不會再阻礙縮減作業。
• Pod 具有 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" 註解。
• 刪除節點會超出設定的 PodDisruptionBudget。

如要進一步瞭解叢集自動配置器並防範中斷，請參閱叢集自動配置器常見問題中的下列問題：

• 縮減資源的運作方式為何？
• 叢集自動配置器在縮減資源時是否可使用 PodDisruptionBudget？
• 哪些類型的 Pod 可以阻止叢集自動配置器移除節點？
• 如何調整 GKE 中的叢集自動配置器？

縮減資源時的 Pod 撤除順序

在節點縮減作業期間，叢集自動調度器會根據 Pod 的 PriorityClass 值，將 Pod 分成兩個優先順序層級。GKE 會依序平行逐一層級逐一驅逐 Pod，順序如下：

1. 較低優先順序層級 (值小於 1000000000)：叢集自動配置器會先驅逐這些 Pod，並等待最多一小時，直到驅逐作業完成。
2. 優先順序較高的級別 (值大於或等於 1000000000)：叢集自動配置器會在所有優先順序較低的 Pod 終止後，才剔除這些 Pod，並等待最多 10 分鐘，直到剔除作業完成。在 GKE 中，1000000000是您可以指派給自訂 PriorityClass 的最高值。大於 1000000000 的值會保留給內建系統優先順序類別。

由於每個級別內的淘汰作業會同時執行，因此您無法調整同一級別內 Pod 的淘汰順序。如果您有重要工作負載 (例如系統 Proxy 或自訂 DaemonSet)，必須在所有其他應用程式 Pod 終止前持續執行，請將其 PriorityClass 的優先順序 value 設為 1000000000。

使用節點註解延遲刪除節點

根據預設，叢集自動配置器會在縮減期間，從節點中剔除 Pod，然後刪除節點。您可能需要延遲刪除作業，才能完成額外的清理、連線排除或狀態同步處理。

如要暫時停止刪除節點，請在節點中新增一或多個前置字串為 delay-deletion.cluster-autoscaler.kubernetes.io/ 的註解。當叢集自動配置器指定要縮減節點時，會對節點加上污點，並啟動排空程序。如果叢集自動配置器在節點上偵測到帶有 delay-deletion.cluster-autoscaler.kubernetes.io/ 前置字元的註解，就會暫停最後的 VM 刪除步驟。在您從節點中移除所有含有此前置字元的註解之前，刪除作業會保持暫停狀態。

這個方法有下列規定和限制：

• 鍵：註解鍵必須以 delay-deletion.cluster-autoscaler.kubernetes.io/ 前置字元開頭。您可以附加任何字串，定義專屬的描述性鍵，例如 delay-deletion.cluster-autoscaler.kubernetes.io/ingress。
• 值：叢集自動配置器不會評估註解值。不過，這個值通常代表套用註解的特定執行者 (例如控制器)。這種做法與 Kubernetes 終結器類似，多個獨立執行者可以套用註解，而叢集自動配置器會等待所有註解移除。
• 逾時：為避免無限期阻擋資源調度，叢集自動配置器最多只會暫停刪除節點 2 分鐘 (120 秒)。這項逾時設定無法調整。

在 GKE 中自動調度 TPU 資源

GKE 支援 Tensor Processing Unit (TPU)，可加快機器學習工作負載的處理速度。單一主機 TPU 配量節點集區和多主機 TPU 配量節點集區都支援自動調度資源和自動佈建功能。

在 GKE 叢集上使用 --enable-autoprovisioning 旗標，GKE 會建立或刪除單一主機或多主機 TPU 配量節點集區，並使用符合待處理工作負載需求的 TPU 版本和拓撲。

使用 --enable-autoscaling 時，GKE 會根據節點集區類型，按照下列方式調度資源：

• 單主機 TPU 配量節點集區：GKE 會在現有節點集區中新增或移除 TPU 節點。節點集區可包含任意數量的 TPU 節點，範圍介於零和節點集區的大小上限之間，具體取決於 --max-nodes 和 --total-max-nodes 旗標。節點集區擴充時，節點集區中的所有 TPU 節點都會採用相同的機型和拓撲。如要進一步瞭解如何建立單一主機 TPU 切片節點集區，請參閱「建立節點集區」。

• 多主機 TPU 配量節點集區：GKE 會將節點集區從零擴充至滿足 TPU 拓撲所需的節點數量。舉例來說，如果 TPU 節點集區的機器類型為 ct5lp-hightpu-4t，拓撲為 16x16，則節點集區會包含 64 個節點。GKE 自動配置器可確保這個節點集區有 0 或 64 個節點。縮減時，GKE 會逐一排空所有已排定的 Pod，並將整個節點集區排空至零。如要進一步瞭解如何建立多主機 TPU Slice 節點集區，請參閱「建立節點集區」。

Spot VM 和叢集自動配置器

由於叢集自動配置器會優先擴充最便宜的節點集區，因此在工作負載和資源可用性允許的情況下，叢集自動配置器會在擴充時新增 Spot VM。

不過，即使叢集自動配置器偏好新增 Spot VM，這項偏好設定也不保證大多數 Pod 會在這些類型的 VM 上執行。Spot VM 可能遭到先占，由於這種先占機制，Spot VM 上的 Pod 較容易遭到淘汰。遭驅逐時，這些程序只有 15 秒的終止時間。

舉例來說，假設您有 10 個 Pod，以及隨選和 Spot VM 的混合：

• 一開始，您有 10 個 Pod 在隨選 VM 上運作，因為 Spot VM 無法使用。
• 您不需要全部 10 個 Pod，因此叢集自動配置器會移除兩個 Pod，並關閉額外的隨選 VM。
• 當您再次需要 10 個 Pod 時，叢集自動配置器會新增 Spot VM (因為價格較低)，並在其中排定兩個 Pod。其餘八個 Pod 則保留在隨選 VM。
• 如果叢集自動配置器需要再次縮減資源，Spot VM 可能會優先遭到先占，讓大多數 Pod 繼續在隨選 VM 上執行。

如要優先使用 Spot VM，並避免上述情況，建議您使用自訂運算類別。自訂運算類別可讓您建立優先順序規則，在擴充期間優先使用 Spot VM，因為這類 VM 的優先順序高於隨選節點。如要進一步提高 Pod 在 Spot VM 支援節點上執行的機率，請設定主動遷移。

以下範例說明如何使用自訂運算類別，優先使用 Spot VM。如要進一步瞭解 ComputeClass 參數，請參閱 ComputeClass CRD 說明文件：

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  # Defines a prioritized list of machine types and configurations for node provisioning.
  priorities:
  - machineType: g2-standard-24
    # Specifically requests Spot VMs for this configuration. GKE will try to provision these VMs first.
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  # If GKE can't satisfy the preceding rule, request on-demand nodes with the same configuration
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  # Configures active migration behavior for workloads using this ComputeClass.
  activeMigration:
    optimizeRulePriority: true
    # Enables Cluster Autoscaler to attempt to migrate workloads to Spot VMs
    # if Spot capacity becomes available and the workload is currently
    # running on an on-demand VM (based on the priority rules in this example).

在上述範例中，優先順序規則會宣告偏好使用 g2-standard-24 機型和 Spot VM 建立節點。如果沒有 Spot VM，GKE 會改用隨選 VM。這個運算級別也會啟用 activeMigration，讓叢集自動配置器在容量可用時，將工作負載遷移至 Spot VM。

如果無法使用自訂運算類別，請新增節點親和性、污點或容忍度。舉例來說，下列節點親和性規則會聲明偏好在以 Spot VM 為基礎的節點上排程 Pod (GKE 會自動將 cloud.google.com/gke-spot=true 標籤新增至這類節點)：

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        # set to "true". GKE automatically applies this label to Spot VMs.
        - key: cloud.google.com/gke-spot
          operator: Equal
          values:
          - true

如要進一步瞭解如何使用節點親和性、污點和容忍度來排定 Spot VM，請參閱這篇網誌文章，瞭解如何在 Spot 節點上執行 GKE 應用程式，並以隨選節點做為備用節點。

ProvisioningRequest CRD

ProvisioningRequest 是命名空間自訂資源，可讓使用者向叢集自動配置器要求一組 Pod 的容量。如果應用程式的 Pod 相互連結，必須以單一單位排定，這項功能就特別實用。

支援的佈建類別

系統支援三種 ProvisioningClass：

• queued-provisioning.gke.io：這個 GKE 專屬類別與 Dynamic Workload Scheduler 整合，可讓您將要求排入佇列，並在資源可用時執行。非常適合批次工作或可容許延遲的工作負載。如要瞭解如何在 GKE 中使用佇列式佈建，請參閱「使用 Dynamic Workload Scheduler 部署 GPU，用於批次和 AI 工作負載」。Standard 叢集支援 GKE 1.28.3-gke.1098000 以上版本，Autopilot 叢集支援 GKE 1.30.3-gke.1451000 以上版本。

• check-capacity.autoscaling.x-k8s.io：這個開放原始碼類別會先驗證資源可用性，再嘗試排定 Pod。支援 GKE 1.30.2-gke.1468000 以上版本。

• best-effort-atomic.autoscaling.x-k8s.io：這個開放原始碼類別會嘗試一併為要求中的所有 Pod 佈建資源。如果無法為所有 Pod 佈建足夠的資源，系統就不會佈建任何資源，整個要求也會失敗。自 GKE 1.31.27 版起支援。

如要進一步瞭解 CheckCapacity 和 BestEffortAtomicScaleUp 類別，請參閱開放原始碼說明文件。

使用 ProvisioningRequest 的限制

• GKE 叢集自動調度器僅支援每個 ProvisioningRequest 1 個 PodTemplate。
• GKE 叢集自動配置器一次只能擴充 1 個節點集區。如果 ProvisioningRequest 需要多個節點集區的資源，您必須為每個節點集區建立個別的 ProvisioningRequest。

使用 ProvisioningRequest 的最佳做法

• 使用 total-max-nodes：與其限制節點數量上限 (--max-nodes)，不如使用 --total-max-nodes 限制應用程式消耗的總資源。
• 使用 location-policy=ANY：這項設定可讓 Pod 排定在任何可用位置，加快佈建速度並充分運用資源。
• (選用) 整合 Kueue：Kueue 可自動建立 ProvisioningRequests，簡化工作流程。詳情請參閱 Kueue 說明文件。

輪詢週期

如果發生節點建立錯誤 (例如配額不足或 IP 位址用盡)，向上擴充作業可能會失敗。發生這類錯誤時，基礎代管執行個體群組 (MIG) 會在初始五分鐘輪詢後重試作業。如果錯誤持續發生，這個輪詢間隔時間會以指數方式增加，最長可達 30 分鐘。在這段期間，叢集自動配置器仍可擴充叢集中未發生錯誤的其他節點集區。

其他資訊

如要進一步瞭解叢集自動配置器，請參閱開放原始碼 Kubernetes 專案中的自動調度資源常見問題。

觀察叢集自動配置器

如要瞭解叢集自動配置器的行為和決策，GKE 提供多種觀測能力工具：

• 可見度事件：叢集自動配置器會發出事件，詳細說明擴充、縮減和其他重大決策。這些事件會以記錄項目的形式顯示在 Cloud Logging 中。詳情請參閱「查看叢集自動調度資源事件」。

• Kubernetes 事件：叢集自動配置器會在 Pod (例如 TriggeredScaleUp 或 NotTriggeredScaleUp) 和節點 (例如 ScaleDown) 上產生標準 Kubernetes 事件。叢集自動配置器也會在 kube-system 命名空間的 cluster-autoscaler-status ConfigMap 上產生狀態更新。您可以使用 kubectl get events -n kube-system 指令或檢查特定資源，查看這些事件。

• 待處理 Pod 指標：Cloud Monitoring 的 kubernetes.io/autoscaler/cluster_pending_pods_per_ccc 指標適用於 GKE 1.37 以上版本，可即時顯示叢集自動配置器正在處理的 Pod 數量。這項指標有助於評估資源調度需求及診斷問題。具體來說，這項指標與 k8s_entity 資源相關聯，可依 ComputeClass、Pod 待處理原因 (從叢集自動配置器的角度來看) 和 Pod 類型細分。resource.labels.entity_name 標籤代表 ComputeClass 名稱，空字串 ("") 表示沒有關聯的特定 ComputeClass。詳情請參閱「使用 Cloud Monitoring 監控待處理的 Pod 狀態」。

限制

叢集自動配置器有下列限制：

• 叢集自動配置器不支援本機 PersistentVolume。
• 在 1.24.5-gke.600 之前的 GKE 控制層版本中，當 Pod 要求臨時儲存空間時，叢集自動配置器不支援擴充使用本機 SSD 做為臨時儲存空間且節點數量為零的節點集區。
• 叢集大小限制：最多 15,000 個節點。執行這種規模的叢集時，請考量其他叢集限制和我們的最佳做法。
• 縮減資源時，叢集自動配置器會遵守一小時的優雅終止期，將節點的 Pod 重新排程至其他節點，然後強制終止節點。
• 有時，叢集自動配置器無法完全縮減資源，縮減後會留下額外的節點。當所需的系統 Pod 被安排到不同節點時會發生這種情況，因為沒有任何觸發條件可以將任何這些 Pod 移動到不同的節點。請參閱我有幾個利用率低的節點，但它們並沒有縮減，為什麼會這樣？如要避開這項限制，可以設定 Pod disruption budget。
• 系統不支援使用變更後的篩選條件自訂時間表。
• 叢集自動配置器決定為待處理的 Pod 佈建新節點時，會考量 kube-scheduler 的預設行為。不支援使用自訂排程器，這可能會導致非預期的調度資源行為。
• 如果 Pod 的 PriorityClass 值低於 -10，節點就不會擴大。詳情請參閱「叢集自動調度器如何搭配 Pod 優先順序和搶占功能運作？」一文。
• 叢集自動配置器可能沒有足夠的未分配 IP 位址空間，無法用於新增節點或 Pod，導致向上擴充失敗，並顯示 eventResult 事件，原因為 scale.up.error.ip.space.exhausted。您可以擴充主要子網路，為節點新增更多 IP 位址，也可以使用不連續的多 Pod CIDR，為 Pod 新增 IP 位址。詳情請參閱「Pod 的可用 IP 空間不足」。
• GKE 叢集自動配置器與開放原始碼 Kubernetes 專案的叢集自動配置器不同。GKE 叢集自動調度資源的參數取決於叢集設定，且可能會變更。如要進一步控管自動調度資源行為，請停用 GKE 叢集自動配置器，並執行開放原始碼 Kubernetes 的叢集自動配置器。不過，開放原始碼 Kubernetes 沒有 Google Cloud 支援。
• 刪除已啟用自動調度資源功能的 GKE 節點集區時，節點會設定 NoSchedule 旗標，且這些節點上的所有 Pod 都會立即遭到剔除。為減緩可用資源突然減少的情況，節點集區的自動配置器可能會在同一個節點集區中佈建新節點。這些新建立的節點可用於排程，遭撤銷的 Pod 則會重新排定至這些節點。最後，整個節點集區 (包括新佈建的節點及其 Pod) 都會刪除，這可能會導致服務中斷。如要解決這個問題，請在刪除節點集區前停用自動調度資源功能，防止自動配置器在刪除期間佈建新節點。
• 叢集自動配置器需要預測新節點上的可用資源量，才能做出調整大小的決策。包括 DaemonSet Pod，這會減少可用資源。 預測結果並非百分百準確，而且可用資源量可能會因 GKE 版本而異。因此，我們不建議調整工作負載大小和限制，以配合特定執行個體類型。建議改用自訂運算級別。如果工作負載需要指定特定執行個體類型，請務必調整大小，在節點上保留可分配資源的緩衝區。在這種情況下，您也必須確保所有相關的 DaemonSet Pod 都能與工作負載 Pod 一起容納在節點上。
• 如果 whenUnsatisfiable 欄位設為 DoNotSchedule 值，叢集自動配置器不支援嚴格的 Pod 拓撲分散限制。您可以將 whenUnsatisfiable 欄位設為 ScheduleAnyway 值，放寬分散要求。

已知問題

• 在 1.22 之前的 GKE 控制層版本中，GKE 叢集自動配置器會停止在空白 (零節點) 叢集上擴充所有節點集區。GKE 1.22 以上版本不會發生這種情況。

疑難排解

如需疑難排解建議，請參閱下列頁面：

• 排解叢集自動配置器未縮減的問題。
• 排解叢集自動配置器未向上擴充的問題。

後續步驟

• 瞭解如何自動調整節點規模。
• 瞭解如何使用容量緩衝區，盡量縮短排程延遲時間。
• 瞭解如何自動升級節點。
• 瞭解如何自動修復節點。
• 瞭解如何縮短新節點的映像檔提取時間。