關於 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 (先占 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 使用，因此可縮短標準叢集啟動這些 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 的混合：

• 您一開始在隨選 VM 上執行 10 個 Pod，因為 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，請參閱「Running a GKE application on spot nodes with on-demand nodes as fallback」網誌。

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

• 節點佈建失敗指標：適用於 GKE 1.37 以上版本，kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc 指標會追蹤節點新增失敗的嘗試，並依特定原因分類。這項指標有助於找出叢集未如預期擴充的原因。 詳情請參閱「監控節點佈建失敗情形」。

• 節點佈建嘗試指標：適用於 GKE 1.37 以上版本，kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc 指標會提供自動配置器每次啟動擴充作業的次數。這項指標可協助您確認自動配置器是否會因應需求做出回應。詳情請參閱「監控節點佈建嘗試」。

限制

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

• 叢集自動配置器不支援本機 PersistentVolume。
• 在 GKE 控制層版本低於 1.24.5-gke.600 的情況下，當 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 以上版本不會發生這種情況。

疑難排解

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

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

後續步驟

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