本頁說明 Google Kubernetes Engine (GKE) 的彈性啟動佈建模式。Flex-start 採用 Dynamic Workload Scheduler，提供彈性且符合成本效益的技術，讓您在需要執行 AI/機器學習工作負載時取得 GPU 和 TPU。
彈性啟動功能可讓您視需要動態佈建 GPU 和 TPU，最多可使用七天，不受特定啟動時間限制，也不必管理長期預訂。因此，彈性啟動很適合需求量波動或時間較短的中小型工作負載。例如小型模型預先訓練、模型微調或可擴充的服務模型。
本頁面資訊可協助您執行下列操作：
- 瞭解 GKE 中的彈性啟動功能運作方式。
- 評估彈性啟動是否適合您的工作負載。
- 決定哪種彈性啟動設定適合您的工作負載。
- 管理使用彈性開始時間時的中斷情形。
- 瞭解 GKE 中彈性啟動的限制。
本頁面適用於平台管理員和營運人員，以及機器學習 (ML) 工程師，他們希望針對工作負載最佳化加速器基礎架構。
使用彈性開始時間的時機
如果工作負載符合下列所有條件，建議您使用彈性啟動：
- 工作負載需要 GPU 資源。
- 工作負載需要透過單一主機 TPU 節點集區執行的 TPU 資源。
- 您擁有的預留 GPU 或 TPU 容量有限或沒有，且需要更可靠地存取這些加速器。
- 您的工作負載時間彈性較大，且使用案例可等待系統提供所有要求的容量，例如 GKE 在尖峰時段以外分配 GPU 資源時。
彈性啟動定價
如果工作負載需要視情況動態佈建資源，且短期預訂最多七天，不需要複雜的配額管理，並希望以具成本效益的方式存取資源，建議使用彈性啟動。「彈性啟動」功能採用 Dynamic Workload Scheduler，並按照 Dynamic Workload Scheduler 定價計費：
- vCPU、GPU 和 TPU 可享折扣 (最高 53%)。
- 即付即用。
需求條件
如要在 GKE 中使用彈性啟動功能，叢集必須符合下列規定：
- 如要執行 GPU，請使用 GKE 1.32.2-gke.1652000 以上版本。
如要執行 TPU，請使用 GKE 1.33.0-gke.1712000 以上版本。彈性啟動支援下列版本和區域：
asia-northeast1-b和us-east5-a中的 TPU Trillium (v6e)。us-west4-a中的 TPU v5e。- TPU v5p。
us-east5-a
不支援 TPU v3 和 v4。
彈性啟動佈建模式的運作方式
使用彈性啟動功能時，您可以在工作負載中指定所需的 GPU 或 TPU 容量。此外，您還可以在標準叢集中的特定節點集區上設定彈性啟動。當容量可用時，GKE 會自動完成下列程序，佈建 VM：
- 工作負載要求的容量目前無法立即使用。這項要求可直接由工作負載規格提出，或透過排程工具 (例如自訂運算類別或 Kueue) 提出。
- GKE 會識別節點已啟用彈性啟動，且工作負載可等待不確定的時間量。
- 叢集自動調度器會接受您的要求，並將必要節點視為單一單位，計算節點數量。
- 叢集自動配置器會在必要節點可用時佈建這些節點。這些節點最多可執行七天，或是在
maxRunDurationSeconds參數中指定值時，執行較短的時間。這個參數適用於 GKE 1.28.5-gke.1355000 以上版本。如未指定maxRunDurationSeconds參數的值，預設值為七天。 - 在您於
maxRunDurationSeconds參數中定義的執行時間結束後，節點和 Pod 會遭到搶占。 - 如果 Pod 提早完成，且節點不再使用，叢集自動調度器會根據自動調度設定檔移除節點。
GKE 會在節點層級計算每個彈性啟動要求的持續時間。啟動期間的延遲可能會導致 Pod 的可用執行時間略為縮短。Pod 重試會共用這段時間，也就是說，Pod 重試後可用的時間會變少。GKE 會分別計算每項彈性啟動要求的時間長度。
彈性啟動設定
GKE 支援下列彈性啟動設定：
- 彈性啟動：GKE 會逐一分配節點資源。這項設定只需要在建立節點時設定
--flex-start標記。 彈性啟動搭配佈建佇列：GKE 會同時分配所有要求的資源。如要使用這項設定，您必須在建立節點集區時新增
--flex-start和enable-queued-provisioning標記。GKE 會按照本文「彈性啟動佈建模式的運作方式」一節中的程序執行，但也會套用下列條件：- 排程器會等到單一可用區中提供所有要求的資源。
- 工作負載的所有 Pod 都能在新佈建的節點上一起執行。
- 工作負載執行作業之間不會重複使用佈建的節點。
下表比較了彈性開始設定：
| 彈性啟動 | 彈性啟動搭配佈建佇列 | |
|---|---|---|
| 可用性 | 預覽 | 正式發布 (GA) flex-start 和 enable-queued-provisioning 旗標。
|
| 支援的加速器 |
|
|
| 建議的工作負載大小 | 小型到中型，也就是說，工作負載可在單一節點上執行。舉例來說，如果您執行小型訓練工作、離線推論或批次工作，這個設定就非常適合。 | 中型到大型，也就是說工作負載可在多個節點上執行。工作負載需要多項資源，且必須等到所有節點都已佈建並準備就緒，才能開始執行。舉例來說，如果您執行分散式機器學習訓練工作負載，這個設定就非常適合。 |
| 佈建類型 | 有可用資源時，GKE 會一次佈建一個節點。 | GKE 會同時分配所有要求的資源。 |
| 設定複雜度 | 較不複雜。這項設定與隨選和 Spot VM 類似。 | 更複雜。強烈建議使用配額管理工具，例如 Kueue。 |
| 支援自訂運算類別 | 是 | 否 |
| 節點回收 | 是 | 否 |
| 價格 | 彈性啟動 SKU | 彈性啟動 SKU |
| 配額 | ||
| 節點升級策略 | 短期升級 | 短期升級 |
gcloud container node pool create 旗標 |
--flex-start |
|
| 開始使用 | GPU： TPU： | 使用彈性啟動搭配佈建佇列，執行大規模工作負載 |
最佳化彈性啟動設定
如要建立穩健且經濟實惠的 AI/機器學習基礎架構，您可以將彈性啟動設定與可用的 GKE 功能結合。建議您使用運算類別，根據工作負載需求定義節點設定的優先順序清單。GKE 會根據可用性和您定義的優先順序，選取最合適的設定。
管理使用動態工作負載排程器的工作負載中斷情形
如果工作負載需要節點集區中的所有或大部分節點都可用，就很容易受到驅逐影響。此外，透過動態工作負載調度器要求佈建的節點不支援自動修復。自動修復功能會從節點中移除所有工作負載，因此工作負載無法執行。
當叢集控制層執行彈性啟動的最低版本 (1.32.2-gke.1652000 以上版本) 時，使用彈性啟動、排隊佈建或兩者的所有節點，都會使用短期升級。
短期升級會更新 Autopilot 叢集中的標準節點集區或節點群組，不會中斷執行中的節點。系統會使用新設定建立新節點，並逐漸取代使用舊設定的現有節點。舊版 GKE 不支援彈性啟動或短期升級，因此需要不同的最佳做法。
盡量減少使用短期升級的節點工作負載中斷情形的最佳做法
當叢集執行 1.32.2-gke.1652000 以上版本時，系統會自動將彈性啟動節點和使用佇列佈建的節點，設定為使用短期升級。
如要盡量減少對節點上執行的工作負載造成的干擾，請執行下列工作：
- 設定維護期間和排除時段，指定 GKE 應在何時執行更新作業 (例如節點升級)，同時確保 GKE 仍有時間執行自動維護作業。
- 停用節點自動修復功能。
如果叢集節點執行的版本早於 1.32.2-gke.1652000，因此未使用短期升級，請參閱這些節點的具體指引。
盡量減少工作負載中斷情形的最佳做法，適用於沒有短期升級的佇列佈建節點
如果叢集執行的 GKE 版本早於 1.32.2-gke.1652000，使用佇列佈建的節點不會使用短期升級。如果叢集升級至 1.32.2-gke.1652000 以上版本，且現有節點佈建作業已排入佇列，系統會自動更新叢集，改用短期升級。
如要瞭解如何處理執行這些舊版節點，請參閱下列指引：
- 視叢集的發布管道註冊狀態而定，請遵循下列最佳做法，防止節點自動升級中斷工作負載：
- 如果叢集已註冊發布版本，請使用維護時間視窗和排除項目，防止 GKE 在工作負載執行期間自動升級節點。
- 如果叢集未註冊至發布管道，請停用節點自動升級。不過，建議您使用發布版本，並透過更精細的範圍設定維護排除時段。
- 停用節點自動修復功能。
- 使用維護時間和排除項目，盡量減少執行中工作負載的中斷情形，同時確保 GKE 仍有時間執行自動維護作業。請務必排定時間，確保沒有任何工作負載正在執行。
- 為確保節點集區維持在最新狀態，請在沒有任何 Dynamic Workload Scheduler 要求處於啟用狀態，且節點集區為空時，手動升級節點集區。
叢集遷移至短期升級時的注意事項
當叢集升級至 1.32.2-gke.1652000 以上版本時，GKE 會使用排隊佈建功能更新現有節點，以使用短期升級。GKE 不會更新其他設定，例如為特定節點集區停用節點自動升級功能後，GKE 不會重新啟用這項功能。
節點集區使用短期升級後，建議您考慮導入下列最佳做法：
- 如果您使用
--no-enable-autoupgrade旗標停用節點自動升級功能，這項遷移作業不會為節點集區重新啟用節點自動升級功能。建議您啟用節點自動升級功能，因為短期升級不會中斷現有節點和其執行的工作負載。詳情請參閱「短期升級」。 - 此外，如果叢集尚未註冊加入發布管道，我們也建議您註冊叢集，以便使用更精細的維護排除範圍。
彈性啟動模式下的節點回收
為確保節點順利轉換，並避免執行中的作業發生停機情形，彈性啟動支援節點回收。節點達到期限後，GKE 會自動以新節點取代，以保留執行中的工作負載。
如要使用節點回收功能，您必須建立自訂運算類別設定檔，並在 flexStart 規格中加入 nodeRecycling 欄位和 leadTimeSeconds 參數。
leadTimeSeconds 參數可讓您兼顧資源可用性和成本效益。這個參數用於指定節點在七天期限結束前多久 (以秒為單位)，就應開始新的節點佈建程序來取代該節點。較長的準備時間會提高新節點在舊節點移除前準備就緒的機率，但可能會產生額外費用。
節點回收程序包含下列步驟：
回收階段：GKE 會驗證彈性啟動佈建的節點是否具有
nodeRecycling欄位，且已設定leadTimeSeconds參數。如果是，當目前日期大於或等於下列欄位值之間的差異時，GKE 會啟動節點回收階段：creationTimestamp加maxRunDurationSecondsleadTimeSeconds
creationTimeStamp旗標包含節點的建立時間。maxRunDurationSeconds欄位可在自訂運算類別中指定，預設為七天。節點建立：新節點的建立程序開始，並依序完成排隊和佈建階段。排隊階段的持續時間會因區域和特定加速器容量而異。
限制節點，該節點的七天期限即將到期：新節點執行後，舊節點會受到限制。這項操作可避免在該節點上排定任何新的 Pod。該節點中的現有 Pod 會繼續執行。
節點取消佈建：節點達到七天期限後，系統會在適當時間取消佈建，確保執行中的工作負載已遷移至新節點。
下列運算類別設定範例包含 leadTimeSeconds 和 maxRunDuration 欄位：
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
name: dws-model-inference-class
spec:
priorities:
- machineType: g2-standard-24
spot: true
- machineType: g2-standard-24
maxRunDurationSeconds: 72000
flexStart:
enabled: true
nodeRecycling:
leadTimeSeconds: 3600
nodePoolAutoCreation:
enabled: true
如要進一步瞭解如何使用節點回收功能，請參閱「Serve LLMs on GKE with a cost-optimized and high-availability GPU provisioning strategy」教學課程。
限制
- 不支援Pod 間反親和性。叢集自動配置器在佈建節點時不會考量 Pod 間的反親和性規則，這可能導致工作負載無法排定。如果兩個以上的 Dynamic Workload Scheduler 物件節點是在同一個節點集區中佈建，就可能發生這種情況。
- 僅支援 GPU 節點。
- 動態工作負載排程器不支援預訂。建立節點集區時，您必須指定
--reservation-affinity=none旗標。 Dynamic Workload Scheduler 僅支援叢集自動調度資源的ANY位置政策，且必須使用這項政策。 - 單一 Dynamic Workload Scheduler 要求最多可建立 1,000 個虛擬機器 (VM)，這是單一節點集區在每個區域的節點數量上限。
- GKE 會使用 Compute Engine
ACTIVE_RESIZE_REQUESTS配額，控管佇列中待處理的 Dynamic Workload Scheduler 要求數量。根據預設，這項配額的上限為每個專案 100 個要求。 Google Cloud 如果您嘗試建立大於此配額的 Dynamic Workload Scheduler 要求，新要求就會失敗。 - 使用 Dynamic Workload Scheduler 的節點集區對中斷事件很敏感，因為節點是同時佈建。詳情請參閱「管理使用 Dynamic Workload Scheduler 的工作負載中斷情形」。
- 您可能會在 Google Cloud 控制台中看到其他短期 VM。這是預期行為，因為在有足夠容量可佈建所有必要機器之前，Compute Engine 可能會建立 VM，然後立即移除。
- 不支援Spot VM。
- Dynamic Workload Scheduler 不支援臨時磁碟區。 您必須使用永久磁碟區做為儲存空間。如要選取使用永久磁碟區的最佳儲存空間類型，請參閱 GKE 叢集儲存空間總覽。
- 如果工作負載使用節點回收功能，且是由 Job 部署，請將 Job 的完成模式設為
Indexed。