本頁面由 Cloud Translation API 翻譯而成。

管理 GPU 和 TPU 的 GKE 節點中斷

自動駕駛標準

在長期執行的 GKE 叢集生命週期中，基礎架構中斷會導致Google Cloud 問題，進而造成工作負載定期中斷。發生這些自動事件的原因可能是排程決策 (搶占事件)、控制層或節點更新 (包括 GKE 節點自動升級 (維護事件))，或是偵測到的問題獲得修正 (終止事件)。

本頁面說明 GKE 中的節點中斷情形，並協助您監控維護通知，以及盡量減少附加 GPU 和 TPU 的 GKE 節點中斷情形。

本文件適用於管理基礎技術架構生命週期的平台管理員和作業人員。如要進一步瞭解內容中提及的常見角色和範例工作，請參閱「常見的 GKE Enterprise 使用者角色和工作」。 Google Cloud

GKE 中的基礎架構中斷是什麼意思？

GKE 叢集會管理 GKE 節點的生命週期。這些節點是在 Compute Engine VM 上佈建，因此會定期發生下列中斷情形：

偵測到的問題獲得修正 (TerminationEvent)：發生這類事件的原因是 Google Cloud 偵測到問題，並中斷叢集基礎架構。TerminationEvent 事件不支援正常關機。下列問題會觸發 TerminationEvent 事件：
- 自動修復：如果節點持續未通過健康狀態檢查，GKE 就會修復該節點。
- 如果實體機器的硬體或軟體發生錯誤，導致 VM 停止運作，就會發生 HostError。
注意： 基礎 Compute Engine 的維護事件視為自動維護事件。這類事件會略過 GKE 維護政策和排除項目。
維護或升級事件 (MaintenanceEvent)：當 Google Cloud 需要中斷 VM 執行維護作業時，就會發生這類事件。下列維護工作會觸發 MaintenanceEvent 事件：
- 維護事件： Google Cloud 升級基礎主機時會發生。
- 節點更新 (包括節點自動升級) 會在 GKE 更新節點上執行的 Kubernetes 版本時發生。
如要進一步瞭解您和 GKE 如何在叢集生命週期內管理變更，請參閱「變更類型」。
排程決策的回應 (PreemptionEvent)：當Google Cloud 需要搶占 VM，為優先順序較高的資源提供容量時，就會發生這種情況。PreemptionEvent 事件可以是下列任一項：
- 逐出：當可搶占或Spot 基礎架構遭到搶占，以容納優先順序較高的 VM 時，就會發生逐出情況。
- 重整：GKE 預先終止較小的 TPU 配量，以容納較大的 TPU 配量時，就會發生重整。只有在 TPU 節點上才會發生重組。

在長期執行的 GKE 叢集生命週期中，節點可能會定期中斷，導致訓練或服務工作負載受到影響。如果這些中斷事件影響執行 AI/機器學習工作負載的 GKE 節點，GKE 就必須重新啟動執行中的工作負載和基礎節點。

為什麼 GPU 和 TPU 需要中斷管理

大多數 Compute Engine VM 的主機維護政策都設為即時遷移，因此執行中的工作負載通常不會受到影響。不過，特定類別的 VM 不支援即時遷移，包括已連結 GPU 和 TPU 的 VM。如果主機事件發生在 TPU 區塊內的 VM 中，整個區塊就會中斷，然後重新排定時間，因為所有維護事件都是在區塊層級協調。因此，如果您建立含有數百個 VM 的 TPU 節點，所有這些 VM 都會收到相同的維護事件排程。

發生主機事件時，GKE 會終止節點及其 Pod。如果 Pod 是以較大型工作負載 (例如 Job 或 Deployment) 的一部分部署，GKE 會在受影響的節點上重新啟動 Pod。

您或使用的架構必須處理工作負載設定，才能適當回應維護事件。舉例來說，您可以儲存 AI 訓練作業的狀態，減少資料遺失。

如要管理 AI/機器學習工作負載的中斷情形，請採取下列做法：

監控節點和節點集區中斷情形
監控維護通知
將服務中斷的影響降至最低

監控節點中斷情形

下列 GKE 系統指標會回報自上次取樣以來，GKE 節點的中斷次數 (指標每 60 秒取樣一次)：

kubernetes.io/node/interruption_count

interruption_type (例如 TerminationEvent、MaintenanceEvent 或 PreemptionEvent) 和 interruption_reason (例如 HostError、Eviction 或 AutoRepair) 欄位可協助提供節點中斷的原因。

如要取得專案中叢集內 TPU 節點的中斷情形和原因明細，請使用下列 PromQL 查詢：

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

如要只查看主機維護事件，請更新查詢，篩選 interruption_reason 的 HW/SW Maintenance 值。使用下列 PromQL 查詢：

```promql
sum by (interruption_type,interruption_reason)(
  sum_over_time(
kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))
```

如要查看依節點集區匯總的中斷次數，請使用下列 PromQL 查詢：

```promql
sum by (node_pool_name,interruption_type,interruption_reason)(
  sum_over_time(
    kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))
```

監控維護通知

當節點及其基礎 VM 預計發生中斷性主機事件，以及這些事件開始生效時，Compute Engine 會發出通知。通知內容包括預計開始時間、活動類型和其他詳細資料。

在 GKE 1.31.1-gke.2008000 以上版本中，您可以監控即將進行的維護作業，包括本節所述的事件。

已排定近期維護作業，但尚未開始

在附加 GPU 或 TPU 的 VM 發生排定的維護事件前，Compute Engine 會將通知推送至所有 VM。這些通知會回報維護期間的開始時間。如果 VM 排定即將進行維護作業，但作業尚未啟動，GKE 會在節點標籤中加入 scheduled-maintenance-time。

如要在節點層級查詢這些通知，請執行下列指令：

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

輸出結果會與下列內容相似：

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

SCHEDULED-MAINTENANCE-TIME 欄代表秒數，以 Unix 紀元時間格式顯示。

如要在節點中繼資料層級查詢這些通知，請檢查執行個體是否有維護事件通知。

排定的維護作業開始

對於支援進階維護的加速器最佳化機器系列，您可以存取 upcoming-maintenance 端點，取得排定和已啟動的維護事件相關資訊。

排定維護作業開始時，Compute Engine 會更新 http://metadata.google.internal/computeMetadata/v1/instance/attributes/ 目錄中的中繼資料。Compute Engine 會更新中繼資料標籤，如下所示：

將 maintenance-event 設為 TERMINATE_ON_HOST_MAINTENANCE。
在 upcoming-maintenance 中，將 maintenance_status 設為 ONGOING。

GKE 會在維護通知期限內，以有限的預先定義最長時間，從容撤銷 Pod 並終止工作負載。

將服務中斷的影響降至最低

如要盡量減少節點中斷造成的影響，可以手動啟動主機維護事件。

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

手動啟動主機維護事件

當 Compute Engine 發出有關排定維護事件的通知時，您可以手動啟動維護作業，時間可配合您的作業排程，例如在活動減少的期間。

在節點集區的節點上，將節點標籤 cloud.google.com/perform-maintenance 設為 true。例如：

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

在維護事件開始前，GKE 會先正常終止 Pod 和工作負載，然後使用 perform-maintenance action 執行維護作業。標籤申請和維護開始之間的時間長度不一。

設定 GKE，以便正常終止工作負載

在本節中，您將設定 GKE 來管理應用程式生命週期，並盡量減少工作負載中斷情形。如未設定寬限期，寬限期預設為 30 秒。

GKE 會盡量正常終止這些 Pod，並執行您定義的終止動作，例如儲存訓練狀態。GKE 會在寬限期開始時，將 SIGTERM 信號傳送至 Pod。如果 Pod 在寬限期結束前未結束，GKE 會向 Pod 中任何容器內仍在執行的程序傳送後續 SIGKILL 信號。

如要設定正常終止期，請在 Pod 資訊清單的 spec.terminationGracePeriodSeconds 欄位中，設定終止寬限期 (秒)。舉例來說，如要將通知時間設為 10 分鐘，請在 Pod 資訊清單中將 spec.terminationGracePeriodSeconds 欄位設為 600 秒，如下所示：

    spec:
      terminationGracePeriodSeconds: 600

建議您設定足夠長的終止寬限期，讓所有進行中的工作都能在通知時間範圍內完成。如果您的工作負載使用 MaxText、Pax 或 JAX 等機器學習架構搭配 Orbax，工作負載可以擷取關機 SIGTERM 信號，並啟動檢查點程序。詳情請參閱 TPU 自動檢查點。

安全終止程序

當中斷事件開始時 (無論是手動或由 VM 自動觸發)，Compute Engine 會更新 maintenance-event 中繼資料鍵，發出即將關閉機器的信號。無論是哪種情況，GKE 都會在節點即將關閉時啟動正常終止程序。

下列工作流程說明 GKE 如何在節點即將關機時，執行正常節點終止作業：

60 秒內會發生以下情況：
1. 系統元件會套用 cloud.google.com/active-node-maintenance 節點標籤集，指出工作負載正在停止。ONGOING
2. GKE 會套用節點 taint，避免將新的 Pod 排程到節點上。taint 具有 cloud.google.com/impending-node-termination:NoSchedule 鍵。由於已知會發生終止作業，因此建議您不要修改工作負載，以容許這項汙點。
維護處理常式元件會先逐一驅逐工作負載 Pod，然後驅逐系統 Pod (例如 kube-system)，藉此開始驅逐 Pod。
GKE 會將 SIGTERM 關機信號傳送至節點上執行的工作負載 Pod，提醒這些 Pod 即將關機。廣告連播可以使用這項快訊完成任何進行中的工作。GKE 會盡量正常終止這些 Pod。
驅逐作業完成後，GKE 會將 cloud.google.com/active-node-maintenance 標籤的值更新為 terminating，表示節點已準備好終止。

之後，節點會終止，並分配替代節點。程序完成後，GKE 會清除標籤和汙點。如要使用 GPU 或 TPU 延長工作負載的終止時間，請完成「手動啟動主機維護事件」一節中的步驟。

監控進行中安全終止作業的進度

您可以依下列正常終止事件篩選 GKE 記錄：

當 VM 偵測到因節點即將終止 (例如 Compute Engine 主機維護事件) 而導致的中斷時，GKE 會在停止工作負載時將 cloud.google.com/active-node-maintenance 設為 ONGOING，並在工作負載完成且節點準備終止時設為 terminating。
禁止排定新工作負載時，GKE 會套用 cloud.google.com/impending-node-termination:NoSchedule 汙點。