管理 AI 適用 GKE 叢集

本頁面說明如何管理 A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High (8 個 GPU) 機器的 AI 最佳化 Google Kubernetes Engine (GKE) 叢集，包括下列與 GKE 叢集和 AI 工作負載相關的常見事件：

  • 主機維護
  • 叢集升級
  • 回報出錯的主機

管理 AI 工作負載的主機維護作業

GKE 節點會在 Compute Engine 執行個體上執行，這些執行個體會定期發生主機事件，可能導致 AI 工作負載中斷。由於主機事件發生在底層Google Cloud 基礎架構上，因此會略過 GKE 維護期間和排除項目。雖然大多數運算執行個體的宿主維護政策都設為即時遷移，可盡量減少工作負載中斷，但 GPU 和 TPU不支援即時遷移。當這些主機事件影響執行 AI 工作負載的 GKE 節點時，GKE 必須終止節點和節點上執行的 Pod。如果 Pod 是以較大型工作負載 (例如 Job 或 Deployment) 的一部分部署，GKE 會嘗試在受影響的節點上重新啟動 Pod。

如要進一步瞭解如何管理基礎運算執行個體的主機維護作業，請參閱「管理 GPU 和 TPU 的 GKE 節點中斷」。

監控主機維護事件

如果叢集執行的是 GKE 1.31.1-gke.2008000 以上版本，您可以透過下列方式查看主機維護事件的排定開始時間。所有 GPU 和 TPU 的啟動時間，都會以對應 GKE 節點上的 Kubernetes 節點標籤表示。

詳情請參閱「監控維護通知」。

有了這些節點標籤，您就能執行下列操作：

手動啟動主機維護事件

Compute Engine 發出排定維護事件的通知後，您可以在符合排程的時間手動啟動維護作業。舉例來說，您可以選擇在活動量較少的期間執行維護作業。

如果您未手動啟動主機維護事件，Compute Engine 會自動完成定期排定的維護作業。

按照操作說明手動啟動主機維護事件。此外，請繼續閱讀本節，瞭解下列事項：

排定工作負載時，請使用主機維護資訊

您可以搭配使用透過 GKE 節點標籤顯示的維護資訊，以及節點親和性和反親和性，盡量減少工作負載中斷情形。

請參閱下列各節，瞭解如何使用這項資訊。

將 Pod 指派到沒有排定未來維護作業的節點

您可以指示 GKE 只將 Pod 排定至沒有未來排定維護事件的節點，例如使用下列程式碼片段：

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

將 Pod 排定至維護作業排定在特定日期後的節點

您可以提供 Unix 紀元時間，指示 GKE 只將 Pod 排程至在特定日期後排定維護作業的節點：

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

管理 AI 工作負載的 GKE 叢集升級

AI 工作負載容易受到中斷影響。

在 GKE 叢集的生命週期中，AI 工作負載必須準備好因應基礎運算執行個體和 GKE 叢集本身的中斷情況：

建議您讓叢集註冊發布管道。根據預設，GKE 叢集會註冊一般發布管道。如要進一步瞭解發布版本的優點，請參閱「已註冊和未註冊發布版本的叢集比較」。

透過發布管道，您可以存取更多功能，包括額外的維護排除範圍。建議您為 AI 工作負載選擇「不執行任何次要或節點升級作業」範圍。

透過 GKE 回報出錯的主機

本節說明如何透過 GKE 回報有問題的主機，該主機已使用預訂繫結佈建模型佈建運算執行個體。如果想回報使用「彈性啟動」佈建模式 (搶先版) 佈建節點時發生故障的主機，請改為與帳戶團隊聯絡。

主機是資料中心內的單一實體伺服器，執行運算執行個體，用於託管 GKE 節點。如要回報有問題的主機，請將 fault-behavior 節點標籤套用至受影響的 GKE 節點。將節點標籤套用至特定 GKE 節點後，GKE 會執行下列步驟：

  1. 按程序從節點撤出工作負載。
  2. 防止在節點上排程新的 Pod。
  3. 在運算執行個體上呼叫 API，將主機標示為有故障。
  4. 等待運算執行個體在運作正常的主機上重新啟動。如果預訂項目使用所有容量預訂作業模式，Compute Engine 會在修復作業完成後，將運算執行個體還原至同一節點。
  5. 從節點中移除汙染和 fault-behavior 標籤。

完成後，節點即可再次處理工作負載。

需求條件

如要回報出錯的主機，GKE 節點必須符合下列規定：

  • 您必須執行 GKE 修補程式版本 1.32.3-gke.1057001 以上版本。
  • 您必須執行下列其中一種 GPU 機器類型：A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High (8 個 GPU)。
  • 您必須在與預訂項目綁定的運算執行個體上執行 GKE 節點。
  • GKE 節點必須處於 RUNNING 狀態。如果您在刪除運算執行個體後嘗試回報主機故障，系統會傳回錯誤訊息，且不會將主機標示為故障。
  • 根據街區健康狀態的評估結果，系統可能會限制您每月每項預訂可呼叫此 API 的次數。如果預留項目使用全容量預留項目運作模式，則不適用速率限制。

回報出錯的主機

如要回報出錯的主機：

  1. 使用 GKE 可觀測性工具、您自己的監控工具或記錄檔，找出發生效能問題的 GKE 節點。儲存 NODE_NAME。

  2. 將節點回報為有錯誤：

      kubectl label nodes NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON

    更改下列內容：

    • NODE_NAME：故障節點的名稱。
    • FAULT_REASON：適當的錯誤原因，請使用下列一或多個值：
      • PERFORMANCE：如果運算執行個體上的 GPU 比叢集中的其他 GPU 慢，且記錄檔中沒有任何 XID 錯誤，也沒有偵測到任何其他常見的失敗模式 (例如無聲資料損毀)，請使用這個值。
      • SDC：如果發現資料損毀，但系統並未當機，請使用這個值處理無聲資料損毀問題。CPU 缺陷、軟體錯誤 (例如使用已釋放記憶體或記憶體踩踏)、核心問題或其他缺陷，都可能導致資料損毀。這個詞彙最常指稱硬體造成的瑕疵。
      • XID：如果您發現運算執行個體發生無法復原的 GPU 錯誤，且有 XID，請使用這個值。
      • unspecified：如果您不確定是哪種行為導致運算執行個體發生問題，請使用這個值。這是預設值。但如果適用，建議您指定其他值。
回報節點主機故障後，節點重新啟動的時間會因 節點使用的預留項目中指定的預留項目運作模式而異。如要驗證預留項目的運作模式，請查看預留項目中的 reservationOperationalMode 欄位。下表大致列出兩種可用的預訂作業模式 (所有容量模式和管理模式) 的主機程序錯誤。
所有容量模式 (ALL_CAPACITY) 受管理模式 (HIGHLY_AVAILABLE_CAPACITY)
支援的機型 A4X Max 和 A4X A4、A3 Ultra、A3 Mega 和 A3 High
Faulty host report API 頻率限制 沒有匯率限制。 對 API 的呼叫可能會受到速率限制。
主機故障回報程序

如果節點以所有容量模式執行，回報出錯的主機時會發生下列情況：

  1. 逐出 Pod：將標籤套用至故障節點後，GKE 會 taint 節點，以禁止排程新的 Pod。GKE 也會開始從節點上正常終止執行中的 Pod。GKE 會遵守 Pod 中斷預算 (PDB) 和 Pod 資訊清單的 spec.terminationGracePeriodSeconds 欄位。詳情請參閱「 設定 GKE，以便正常終止工作負載」。
  2. 回報並修復故障主機：GKE 會呼叫 Compute Engine API，自動回報並修復故障主機，這會導致一連串的作業。通常需要 10 到 12 分鐘才能回報故障主機，修復主機則可能需要 3 到 14 天，有時甚至更久。

  3. 重新啟動執行個體：主機維修作業完成後 (通常需要 3 到 14 天)，會發生下列其中一種情況：

    • 如果執行個體處於 REPAIRING 狀態，且資源在修復完成時可用，Compute Engine 會自動在修復後的主機上重新啟動執行個體。
    • 否則，如果執行個體處於 TERMINATED 狀態，或資源在修復完成時無法使用，執行個體狀態會維持或變更為 TERMINATED。如要執行執行個體，請手動重新啟動執行個體。不過，如果重新啟動執行個體時沒有可用資源，執行個體可能會無法重新啟動；舉例來說，如果其他執行個體已使用修復的主機，就會發生這種情況。

如果節點以代管模式執行，回報出錯的主機時會發生下列情況：

  1. 逐出 Pod：將標籤套用至故障節點後，GKE 會 taint 節點，禁止排定新的 Pod。GKE 也會開始從節點上正常終止執行中的 Pod。GKE 會遵守 Pod 中斷預算 (PDB) 和 Pod 資訊清單的 spec.terminationGracePeriodSeconds 欄位。詳情請參閱「 設定 GKE，以正常終止工作負載」。
  2. 回報並開始修復故障主機：GKE 會呼叫 Compute Engine API，自動回報並修復故障主機，這會導致一連串的作業，通常需要 10 到 12 分鐘才能回報故障主機，然後可能需要 3 到 14 天，有時甚至更久，才能修復主機。

  3. 遷移並重新啟動執行個體：主機修復作業開始後 (通常需要 10 到 12 分鐘)，Compute Engine 會嘗試預留一個主機，以取代預留容量中回報有問題的主機。如果 Compute Engine 找到正常運作的主機 (成功更換故障主機，或在預留容量中找到相符的正常主機)，就會將執行個體遷移至該主機。接著，透過下列其中一種方式重新啟動執行個體：

    • 如果執行個體處於 REPAIRING 狀態，且在修復完成前或完成時有可用資源，Compute Engine 會自動在正常運作的主機上重新啟動執行個體。
    • 否則，如果執行個體處於 TERMINATED 狀態，或在修復完成前或完成時沒有可用資源，執行個體狀態會維持或變更為 TERMINATED。如要執行執行個體，必須手動重新啟動執行個體。不過，如果重新啟動執行個體時沒有可用資源，執行個體可能會無法重新啟動；舉例來說，如果其他執行個體已使用修復的主機，就會發生這種情況。

監控作業進度

您可以使用 GKE 節點上的 cloud.google.com/report-and-replace-status 節點標籤，監控 GKE 作業的進度。這個標籤會顯示下列其中一個值：

  • PodsEvicted：GKE 已完成從受影響節點逐出 Pod 的作業。
  • OperationRUNNING：正在執行回報出錯主機的作業。
  • OperationDone：底層主機已回報為故障，且 GKE 節點已準備好移至新主機
  • Error：API 呼叫失敗，原因包括不符合上一節所述的規定。

您也可以查看 cloud.google.com/report-and-replace-operation 節點標籤，瞭解 Compute Engine 作業 ID，以便監控作業狀態。

您可以使用下列指令查看這兩個節點標籤：

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,cloud.google.com/report-and-replace-operation

如有任何 API 錯誤，GKE 會設定節點標籤 cloud.google.com/report-and-replace-status=ERROR。GKE 會清除節點汙點，並移除 cloud.google.com/fault-behavior 節點標籤。

如要瞭解如何追蹤回報出錯主機作業的詳細狀態，請參閱「查看回報出錯主機作業」。

如要針對速率限制等暫時性錯誤重試作業，請將 cloud.google.com/fault-behavior 標籤重新套用至節點。

後續步驟