本頁面說明如何管理 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 叢集本身的中斷：
- 主機維護：如要管理基礎運算執行個體的主機維護作業，請參閱「管理 GPU 和 TPU 的 GKE 節點中斷」。先前的章節也說明瞭這一點。
- 叢集升級：如要管理叢集升級造成的服務中斷，可以使用下列工具：
建議您讓叢集註冊發布管道。根據預設，GKE 叢集會註冊一般發布管道。如要進一步瞭解發布版本的優點，請參閱「已註冊和未註冊發布版本的叢集比較」。
使用發布管道可存取更多功能，包括其他維護排除範圍。建議您為 AI 工作負載選擇「不執行子版本或節點升級作業」範圍。
透過 GKE 回報出錯的主機
本節說明如何透過 GKE 報告有問題的主機，該主機已使用預訂繫結佈建模型佈建運算執行個體。如要回報使用「彈性啟動」佈建模式 (搶先版) 佈建的節點主機故障，請改為與帳戶團隊聯絡。
如果在節點上發現 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 機型：A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High (8 個 GPU)。
- 您必須在受預訂限制的運算執行個體上執行 GKE 節點。
- GKE 節點必須處於
RUNNING狀態。如果您在刪除運算執行個體後嘗試回報主體機器故障，系統會傳回錯誤訊息，且不會將主體機器標示為故障。 - 根據對區塊健康狀態的評估結果，您每月對每個預訂的 API 呼叫次數可能會受到速率限制。如果預留項目使用全容量預留項目運作模式，則不適用速率限制。
回報出錯的主機
如要回報出錯的主機：
使用 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 瑕疵、軟體錯誤 (例如使用已釋放記憶體或記憶體踩踏)、核心問題或其他瑕疵，都可能導致資料損毀。這個詞彙最常指稱硬體造成的瑕疵。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 |
| Faulty host report 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-