關於 GKE 叢集自動調度資源

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

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

使用 Autopilot 叢集時，您不必擔心佈建節點或管理節點集區，因為系統會透過節點自動佈建自動佈建節點集區，並自動調整節點集區大小，以符合工作負載需求。

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

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

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

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

您可以透過映像檔串流提升叢集自動調度資源效能。這項功能會從符合資格的容器映像檔遠端串流處理所需的映像檔資料，同時在本機快取映像檔，讓新節點上的工作負載更快啟動。

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

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

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

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

叢集自動調度器檢查叢集內無法排程的 Pod 的頻率，主要取決於叢集大小。在小型叢集中，檢查作業可能每隔幾秒就會執行一次。無法確切指出這項檢查需要多少時間。

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

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

作業條件

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

• 所有複製的 Pod 都可以在其他節點上重新啟動，可能會造成短暫中斷。
• 使用者或管理員不會手動管理節點。 叢集自動調度器可以覆寫您執行的任何手動節點管理作業。
• 單一節點集區中的所有節點具有一組相同的標籤。
• 叢集自動配置器會考量各集區中執行個體類型的相對成本，並嘗試擴充最便宜的節點集區。不過，叢集自動調度器必須符合下列條件：
  • 叢集自動調度器會考量含有 Spot VM (先占 VM) 的節點集區成本較低，不過，叢集自動配置器也會考量每個區域的資源可用性，因此可能會選擇較昂貴但可用的資源。
  • 如果多個節點集區使用 Spot VM，叢集自動配置器不會自動選取最低成本的選項。為盡量減少這類情況，並以經濟實惠的價格使用 Spot VM，建議您使用自訂運算類別。
• 叢集自動調度器會在排定 Pod 前，考量初始容器要求。初始化容器要求可以使用節點上任何未分配的資源，這可能會導致 Pod 無法排程。叢集自動調度器會遵循 Kubernetes 使用的相同要求計算規則。詳情請參閱使用 Init 容器的 Kubernetes 說明文件。
• 系統不會追蹤在初始叢集或節點集區建立後手動新增的標籤。叢集自動配置器建立的節點會指派標籤，這些標籤是在建立節點集區時，使用 --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，這樣自動調度器就會負責佈建所有節點。

預留項目

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

不過，叢集自動調度器只會檢查自身專案中的預留項目。因此，如果叢集自有專案中提供較便宜的節點選項，自動調度器可能會選取該選項，而非共用預留空間。如要在多個專案之間共用預留項目，請考慮使用自訂運算類別，設定叢集自動調度器用於調度節點的優先順序，包括共用的預留項目。

預設值

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

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

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

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

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

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

GKE 如何處理邊界大小限制

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

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

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

自動調度資源限制

您可以設定叢集自動調度器在調度節點集區時使用的節點數量下限和上限。使用 --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 的驅逐順序。如果重要工作負載必須執行到所有其他應用程式 Pod 終止為止 (例如系統 Proxy 或自訂 DaemonSet)，請為其 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 配量節點集區，請參閱「建立節點集區」。

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 (因為比較便宜)，並在這些 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。

如果無法使用自訂運算類別，請新增節點親和性、taint 或容許條件。舉例來說，下列節點親和性規則會聲明偏好在以 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 的應用程式來說，這項功能特別實用，因為這些 Pod 必須以單一單元的形式一起排程。

支援的佈建類別

系統支援三種 ProvisioningClass：

• queued-provisioning.gke.io：這個 GKE 專屬類別會與動態工作負載排程器整合，讓您將要求加入佇列，並在資源可用時完成要求。非常適合批次工作或可容許延遲的工作負載。如要瞭解如何在 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 可自動建立 ProvisioningRequest，簡化工作流程。詳情請參閱 Kueue 說明文件。

輪詢時間

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

其他資訊

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

限制

叢集自動調整功能有下列限制：

• 叢集自動調度器不支援本機 PersistentVolume。
• 在 GKE 控制層版本 1.24.5-gke.600 之前的版本中，當 Pod 要求臨時儲存空間時，叢集自動調度器不支援擴充節點數為零的節點集區，該節點集區使用本機 SSD 做為臨時儲存空間。
• 叢集大小限制：最多 15,000 個節點。 執行這類大小的叢集時，請考量其他叢集限制和最佳做法。
• 縮減規模時，叢集自動配置器會先預留一小時的正常終止時間，將節點的 Pod 重新排程至其他節點，然後再強制終止節點。
• 有時叢集自動調度器無法完全縮減，縮減後會多出一個節點。當所需的系統 Pod 被安排到不同節點時會發生這種情況，因為沒有任何觸發條件可以將任何這些 Pod 移動到不同的節點。請參閱我有幾個利用率低的節點，但它們並沒有縮減，為什麼會這樣？如要避開這項限制，可以設定 Pod 中斷預算。
• 系統不支援使用變更後的篩選條件自訂時間表。
• 叢集自動配置器決定為待處理的 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 以上版本不會發生這種情況。

疑難排解

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

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

後續步驟

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