本頁面說明如何管理 A5X、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 是做為較大工作負載 (例如工作或部署作業) 的一部分部署，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 叢集本身中斷的情況：
- 主機維護：如要管理基礎運算執行個體的主機維護作業，請參閱「管理 GPU 和 TPU 的 GKE 節點中斷情形」。(先前章節也曾說明)。
- 叢集升級：如要管理叢集升級造成的中斷情形，可以使用下列工具：
建議您將叢集註冊至發布管道。根據預設，GKE 叢集會註冊至一般發布管道。如要進一步瞭解發布管道的優點，請參閱「已註冊和未註冊發布管道的叢集比較」。
透過發布管道，您可以存取更多功能，包括額外的維護作業排除範圍。建議您為 AI 工作負載選取「不執行子版本或節點升級作業」範圍。
透過 GKE 回報故障主機
本節概述如何透過 GKE 回報故障的主機，這些主機具有使用標準、彈性啟動或預留繫結佈建模式佈建的運算執行個體。如要回報透過 Spot 佈建模式佈建的節點，或使用一般 GPU 的節點主機故障，請改為聯絡帳戶團隊。
如果您在節點上發現 GPU 記憶體或 Xid 錯誤，並想確認手動復原措施 (例如觸發客體 OS 重新啟動 (kubectl label
nodes <NODE_NAME> cloud.google.com/perform-reboot=true)) 是否能解決問題，再回報主機故障，請參閱「查看 Xid 訊息」。
主機是資料中心內的單一實體伺服器機器，執行託管 GKE 節點的運算執行個體。如要回報故障的主機，請將 fault-behavior 節點標籤套用至受影響的 GKE 節點。將節點標籤套用至特定 GKE 節點後，GKE 會執行下列步驟：
- 按程序從節點中撤出工作負載。
- 防止新的 Pod 排定在節點上。
- 在運算執行個體上呼叫 API，將主機標示為故障。
- 等待運算執行個體在健康的主機上重新啟動。如果預留項目使用所有容量預留項目作業模式，Compute Engine 會在修復作業完成後，將運算執行個體帶回同一個節點。
- 從節點中移除污點和
fault-behavior標籤。
完成後，節點就能再次處理工作負載。
需求條件
如要回報出錯的主機，GKE 節點必須符合下列條件：
- 必須執行 GKE 修補程式 1.32.3-gke.1057001 以上版本。
- 您必須執行下列其中一種 GPU 機型：A5X、A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High (8 個 GPU)。
- 您必須在預留繫結的運算執行個體上執行 GKE 節點。
- GKE 節點必須處於
RUNNING狀態。如果您在刪除運算執行個體後嘗試回報故障主機，系統會傳回錯誤訊息，且不會將主機標示為故障。 - 系統會評估區塊的健康狀態，並據此限制每項預訂每月呼叫這個 API 的次數。如果預留項目採用「all capacity」(所有容量) 預留項目作業模式，則不適用頻率限制。
回報出錯的主機
如要回報出錯的主機，請按照下列步驟操作：
使用 GKE 觀測能力工具、您自己的監控工具或記錄，找出有效能問題的 GKE 節點。儲存
NODE_NAME。使用下列指令回報節點故障。您可以提供原因，並在後續版本中提供說明：
kubectl patch node NODE_NAME --type merge -p '{ "metadata": { "labels": { "cloud.google.com/fault-behavior": "FAULT_REASON" }, "annotations": { "cloud.google.com/fault-description": "FAULT_DESCRIPTION" } } }'請按照下列方式修改指令：
- 將
NODE_NAME替換為故障節點的名稱。 - 請使用下列一或多個值，將
FAULT_REASON替換為適當的錯誤原因：PERFORMANCE：如果運算執行個體上的 GPU 執行速度比叢集中的其他 GPU 慢，且記錄中未顯示任何 XID 錯誤，也未偵測到任何其他常見的故障模式 (例如無訊息資料損毀)，請使用這個值。SDC：如果發現資料毀損，但系統未當機，請使用這個值表示無訊息資料毀損。這類資料損毀可能是由 CPU 缺陷、軟體錯誤 (例如 UAF 或記憶體踩踏)、核心問題或其他缺陷造成。這個詞通常是指硬體引起的瑕疵。XID：如果發現運算執行個體有 XID 且 GPU 發生無法復原的錯誤，請使用這個值。unspecified：如果不確定是哪種行為導致運算執行個體發生問題，請使用這個值。這是預設值。不過，建議您視情況指定其他值。
- 根據 GKE 叢集的控制層版本調整
annotations區塊：- 1.35.6-gke.1017000 以上版本，或 1.36.0-gke.3251000 以上版本：保留註解區塊，並將
FAULT_DESCRIPTION替換為觀察到的錯誤文字說明。包括 XID 錯誤代碼、症狀或時間戳記。這項說明會轉送至 Compute Engine，協助進行修復診斷，並在作業完成後自動從節點中移除。例如：GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z。 - 舊版：從指令中移除整個
annotations區塊。在這些版本中，fault-description欄位不會轉送至 Compute Engine，也不會自動從節點中移除。請改為聯絡帳戶團隊或 Cloud Customer Care，提供故障詳細資料。
- 1.35.6-gke.1017000 以上版本，或 1.36.0-gke.3251000 以上版本：保留註解區塊，並將
- 將
reservationOperationalMode 欄位。下表摘要說明兩種可用預留作業模式 (所有容量模式和代管模式) 的故障主機程序。所有容量模式 (ALL_CAPACITY) |
受管理模式 (HIGHLY_AVAILABLE_CAPACITY) |
|
|---|---|---|
| 支援的機型 | A4X Max 和 A4X | A4、A3 Ultra、A3 Mega 和 A3 High (8 個 GPU) |
| 故障主機回報 API 頻率限制 | 沒有頻率限制。 | API 呼叫可能受到頻率限制。 |
| 回報故障主機的程序 |
如果回報在所有容量模式下執行的節點主機故障，會發生下列情況：
|
如果回報在代管模式下執行的節點主機故障，會發生下列情況：
|
監控作業進度
您可以使用 GKE 節點上的 cloud.google.com/report-and-replace-status 節點標籤，監控 GKE 作業的進度，該標籤的值如下：
PodsEvicted：GKE 已完成從受影響節點剔除 Pod 的作業。OperationRUNNING：正在執行回報故障主機的作業。OperationDONE：基礎主機已回報為故障，GKE 節點已準備好移至新主機。OperationFAILED：運算執行個體上的 API 因配額限制或其他基礎架構問題而失敗。如要瞭解錯誤，請參閱「排解回報錯誤主機 API 錯誤」。如要瞭解如何復原，請參閱「處理回報和取代失敗」。Error：API 呼叫失敗，因為要求不符合上一節所述的其中一項規定。
您也可以查看 node.gke.io/report-and-replace-operation 節點標籤，瞭解 Compute Engine 作業 ID，以便監控作業狀態。
您可以使用下列指令查看這兩個節點標籤：
kubectl get nodes NODE_NAME \
-L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation
如果發生 API 錯誤，GKE 會將 cloud.google.com/report-and-replace-status 節點標籤設為 Error。如果作業失敗，GKE 會將標籤設為 OperationFAILED。無論是哪一種情況，GKE 都會移除 cloud.google.com/fault-behavior 節點標籤。此外，在 GKE 1.35.6-gke.1256000 以上版本或 1.36.0-gke.4060000 以上版本中，GKE 會對節點套用 cloud.google.com/report-and-replace-failed:NoSchedule 污點。這項 taint 可防止系統將新的 Pod 排定至節點，確保工作負載不會放在主機可能故障的節點上。詳情請參閱「處理回報和取代失敗」。
如要瞭解如何追蹤回報故障主機作業的詳細狀態，請參閱「查看回報故障主機作業」。
處理回報並替換失敗
如果回報並替換作業失敗，GKE 會對受影響的節點套用 cloud.google.com/report-and-replace-failed:NoSchedule 污點。這個污點會讓節點保持封鎖狀態，因此在基礎主機可能仍有故障的情況下，不會在節點上排定新的工作負載。
檢查失敗污點
如要檢查節點是否具有 report-and-replace 故障污點，請執行下列指令：
kubectl describe node NODE_NAME | grep "report-and-replace-failed"
從回報並取代失敗中復原
如要從回報並取代失敗中復原，請執行下列任一操作：
重新將
cloud.google.com/fault-behavior標籤套用至節點，重試作業。如果重試成功，GKE 會自動移除cloud.google.com/report-and-replace-failed:NoSchedule污點：kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON如果您判定節點健康狀態良好，或想讓節點恢復運作，請手動移除污點：
kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-
後續步驟
瞭解如何排解回報出錯主機 API 錯誤。