全部產品
Search
文件中心

Container Service for Kubernetes:開啟節點自愈

更新時間:Dec 23, 2025

節點池開啟託管能力後,支援啟用節點自愈功能,即由ACK自動監控節點狀態,並在節點發生異常時自動執行自愈任務,以簡化節點營運工作。但由於故障的複雜性,自愈任務無法修複所有的故障情境,部分複雜故障可能仍需人工修複。

執行流程

一個完整的故障發現、故障通知與節點自愈流程如下。

image
  1. 故障診斷與發現

    ACK通過ack-node-problem-detector(NPD)組件檢查節點的異常情況。節點運行狀態發生變化並持續一段時間後,ACK判定該節點存在故障。

  2. 故障通知

    發現故障後,ACK會產生Node Condition和Kubernetes Event。您可以通過事件中心警示配置接收通知。

  3. 獨佔GPU情境)故障隔離

    檢測到GPU異常後,ACK對故障GPU卡進行隔離。

    關於GPU卡故障檢測和自動隔離的詳細資料請參見GPU異常檢測與自動隔離
  4. 執行節點自愈流程

    系統與K8s組件異常

    節點執行個體異常

    1. ACK對異常的系統與K8s組件進行修複,例如重啟kubelet、重啟運行時等。

    2. 如果開啟了系統與 K8s 組件異常時允許重啟節點,當修複動作無效時,ACK繼續執行以下操作:

      1. ACK自動將故障節點設定為不可調度。

      2. ACK針對需要重啟的故障節點執行排水。

      3. ACK重啟節點。

      4. 檢測節點狀態恢複正常時,ACK將故障節點恢複為可調度。

    詳細流程說明請參見下文的系統與K8s組件異常
    1. ACK自動為故障節點添加汙點。

    2. 如果開啟了節點執行個體異常時等待授權後修複,ACK會等待您授權同意後再執行後續操作。

    3. ACK針對需要重啟或更換裝置的故障節點執行排水。

    4. ACK執行自愈行為,例如節點重啟、節點維修等,節點狀態為修複中。

    5. 獨佔GPU情境)檢測GPU卡恢複正常時,ACK解除對GPU卡的隔離。

    6. 檢測節點狀態恢複正常時,ACK刪除此前添加的節點汙點。

    詳細流程說明請參見下文的節點執行個體異常
  • 如果叢集中存在多個節點池,各節點池的自愈任務將串列執行。

  • 如果一個節點池存在多個異常節點,自愈任務會以串列的方式逐個恢複。一旦某個節點自愈失敗,ACK會停止對該節點池中其他故障節點的自愈。

使用說明

  • 本功能需搭配事件中心使用,以接收節點池的警示事件,並安裝ack-node-problem-detector,以檢測節點的異常情況。詳情請參見事件監控

  • 本功能僅支援在ACK託管叢集中使用,支援開啟了託管配置的節點池和靈駿節點池。

  • 以下處於灰階發布中的功能,灰階進度可能不同。如需使用,請提交工單一併申請。

    • 節點執行個體異常的自愈:白名單功能。

    • 靈駿節點池的節點自愈:白名單功能。

    • 警示規則集:開啟節點自愈後,推薦開啟警示管理功能,啟用叢集節點自愈警示規則集叢集GPU監控警示規則集,在異常情況發生時自動接收警示通知。相應規則集處於灰階發布中。

      規則集啟用操作,請參見Container Service警示管理
    • NPD版本:節點執行個體異常的自愈依賴NPD組件為1.2.26及以上。1.2.26版本處於灰階中。

配置節點自愈

您可以在新增或存量節點池中通過託管配置開啟節點自愈功能並定義其行為。

節點池和靈駿節點池的開啟步驟類似。以下步驟以節點池為例。

建立節點池時開啟

  1. 登入Container Service管理主控台,在左側導覽列選擇叢集列表

  2. 叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇節點管理 > 節點池

  3. 節點池頁面,單擊建立節點池,在託管配置地區選取項目託管節點池,開啟節點自愈功能,選擇修複系統與K8s組件異常時是否重啟節點,並按照頁面提示完成節點池的建立。

    image

    關於配置項的完整說明,請參見建立和管理節點池。關於重啟節點和等待授權相關的注意事項,請參見下文說明。

存量節點池中開啟

  1. 登入Container Service管理主控台,在左側導覽列選擇叢集列表

  2. 叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇節點管理 > 節點池

  3. 在節點池列表的操作列,單擊目標節點池對應的image > 開啟託管(節點池)或託管配置(託管節點池),選擇託管配置模式為託管節點池,開啟節點自愈功能,選擇修複系統與K8s組件異常時是否重啟節點,並按照頁面提示完成配置的提交。

    image

    關於配置項的完整說明,請參見建立和管理節點池。關於重啟節點和等待授權相關的注意事項,請參見下文說明。

系統與K8s組件異常

自愈流程

ACK會根據節點的運行狀態condition等資訊判斷是否發起自愈任務。您可以執行kubectl describe node命令,在condition欄位查看節點的運行狀態。

檢測到系統與K8s組件異常時,且異常期間超過閾值時間(即故障發生多長時間後會觸發節點自愈)時,ACK將自動執行自愈任務。系統與K8s組件異常情境下,一個完整的節點自愈流程如下。

  1. ACK對異常系統和K8s組件進行維修,例如重啟kubelet、重啟運行時等。

  2. 如果開啟了系統與 K8s 組件異常時允許重啟節點,當修複動作無效時,ACK繼續執行以下操作。

    1. ACK自動將故障節點設定為不可調度。

    2. ACK針對需要重啟的故障節點執行排水。排水逾時時間為30分鐘。

      ACK執行節點排水操作時,會在遵循Pod Disruption Budget(PDB)的前提下將節點上的Pod驅逐至其他可用節點。為確保服務高可用性,建議您採用多副本部署策略,將工作負載分散在多個節點上,同時為關鍵業務配置PDB,控制同時中斷的Pod數量。

      如排水失敗,ACK仍會執行後續操作。

    3. ACK重啟節點。

    4. 檢測節點狀態恢複正常時,ACK將故障節點恢複為可調度。

      如果某節點在執行節點自愈前已被設定為不可調度,那麼在自愈任務完成後,該節點不會自動回復為可調度。

觸發自愈的Node Condition

Node Condition

描述

風險等級

閾值時間

自愈行為

KubeletNotReady(KubeletHung)

kubelet意外停止工作,導致節點NotReady。

180s

  1. 重啟kubelet。

  2. 如果開啟了系統與 K8s 組件異常時允許重啟節點,則重啟ECS執行個體。

KubeletNotReady(PLEG)

PLEG健全狀態檢查失敗,導致節點NotReady。

180s

  1. 重啟containerd或Docker。

  2. 重啟kubelet。

  3. 如果開啟了系統與 K8s 組件異常時允許重啟節點,則重啟ECS執行個體。

KubeletNotReady(SandboxError)

PodSandbox not found,導致kubelet無法正常啟動。

180s

  1. 刪除對應的Sandbox容器。

  2. 重啟kubelet。

RuntimeOffline

containerd或Docker停止工作,節點不可用。

90s

  1. 重啟containerd或Docker。

  2. 如果開啟了系統與 K8s 組件異常時允許重啟節點,則重啟ECS執行個體。

NTPProblem

時間同步服務(ntpd或chronyd)異常。

10s

重啟ntpd或chronyd。

SystemdOffline

Systemd狀態異常,無法啟動、銷毀容器。

90s

如果開啟了系統與 K8s 組件異常時允許重啟節點,則重啟ECS執行個體。

ReadonlyFilesystem

節點檔案系統變為唯讀。

90s

如果開啟了系統與 K8s 組件異常時允許重啟節點,則重啟ECS執行個體。

節點執行個體異常

請確保已參見前文的使用說明完成準備工作。

自愈流程

重要

當靈駿節點發生故障需要硬體維修時,維修過程將重新部署靈駿節點並清空本地碟所有資料。在此情境下,推薦您為節點池開啟節點執行個體異常時等待授權後修複,在授權維修前完成資料備份。

節點執行個體異常情境下,一個完整的節點自愈流程如下。

ACK會在節點執行個體異常發生5分鐘後自動觸發下方的節點自愈流程。
  1. 發現異常後,ACK為故障節點添加如下汙點:

    • Key: alibabacloud.com/node-needrepair

    • Value: Unschedulable

    • Effect: NoSchedule

  2. 如果開啟了節點執行個體異常時等待授權後修複,ACK會等待您授權同意後再執行後續操作。

    如需先對異常節點啟動並執行業務進行處理,建議開啟節點執行個體異常時等待授權後修複。ACK會在您授權同意後再開始修複。
    1. ACK自動為故障節點添加Label alibabacloud.com/node-needrepair=Inquiring

    2. 您可以先對異常節點上啟動並執行業務Pod進行處理或提前備份業務資料。處理完成後,您可以通過刪除Label alibabacloud.com/node-needrepair或將Label的Value設定為Approvedalibabacloud.com/node-needrepair=Approved)來進行授權。

    3. ACK接收您的授權同意後,繼續執行後續操作。

  3. 如未開啟節點執行個體異常時等待授權後修複,ACK會在發現異常後自動執行後續操作。

  4. ACK執行節點排水。排水逾時時間為30分鐘。

    ACK執行節點排水操作時,會在遵循Pod Disruption Budget(PDB)的前提下將節點上的Pod驅逐至其他可用節點。為確保服務高可用性,建議您採用多副本部署策略,將工作負載分散在多個節點上,同時為關鍵業務配置PDB,控制同時中斷的Pod數量。

    如排水失敗,ACK仍會執行後續操作。

  5. ACK執行自愈行為,例如節點重啟、硬體維修等。

  6. ACK檢測節點狀態是否恢複正常。

    • 如故障狀態解除,則刪除此前添加的汙點。節點狀態恢複正常。

    • 如故障狀態未解除或自愈異常,此前添加的節點汙點不會刪除。ACK會定期發送Event通知。可查看Event處理, 或提交工單

  7.  (獨佔GPU情境)檢測GPU卡恢複正常時,ACK解除對GPU卡的隔離。

觸發自愈的Node Condition

重要

如自愈行為中涉及靈駿節點的硬體維修。維修成功後,您需手動將節點從節點池移除,再通過添加已有節點的方式將維修後的裝置重新加入節點池。相關操作及注意事項,請參見移除節點添加已有靈駿節點

Node Condition

描述

自愈行為

NvidiaXID74Error

  • Fatal NVLINK Error.

  • NVLink硬體錯誤產生的Xid,收到此事件說明GPU已經出現嚴重硬體故障,需要下線維修。

硬體維修。

NvidiaXID79Error

  • GPU has fallen off the bus.

  • GPU硬體檢測到掉卡,無法從匯流排上檢測到。收到此事件說明GPU已經出現嚴重硬體故障,需要下線維修。

硬體維修。

NvidiaRemappingRowsFailed

GPU存在行重新對應失敗。

硬體維修。

NvidiaDeviceLost

  • The GPU has fallen off the bus or has otherwise become inaccessible.

  • GPU已從匯流排上脫落或變得不可訪問。

硬體維修。

NvidiaInfoRomCorrupted

  • infoROM is corrupted.

  • infoROM已損壞。

硬體維修。

NvidiaPowerCableErr

  • A device's external power cables are not properly attached.

  • 裝置的外部電源線串連不當。

硬體維修。

NvidiaXID95Error

  • Uncontained ECC error.

  • Xid95代表抑制失敗,此時表明運行在該GPU上的所有應用程式都已受到影響,受影響的GPU必須重設後,應用程式才能重新啟動。

重啟節點。

NvidiaXID48Error

  • Double Bit ECC Error(DBE).

  • 當GPU檢測到不可糾正的錯誤發生時,會記錄此事件。這一情況也會反饋給應用程式。需要GPU重設或重啟節點才能清除此錯誤。

重啟節點。

NvidiaXID119Error

  • GSP RPC Timeout.

  • 在等待GSP核心響應RPC訊息時發生逾時。

重啟節點。

NvidiaXID140Error

  • Unrecovered ECC Error.

  • 當GPU驅動程式在GPU記憶體中檢測到不可糾正的錯誤,這些錯誤影響了驅動程式標記頁面以進行動態網頁面下線或行重新對應的能力時,可能會發生此事件。需要重設GPU。

重啟節點。

NvidiaXID120Error

  • GSP Error.

  • 在GPU的GSP核心上啟動並執行代碼出錯。

重啟節點。

NvidiaPendingRetiredPages

  • GPU存在處於pending狀態的Retired Pages。

  • 需要重設GPU才能使這些Retired Pages生效。

重啟節點。

NvidiaRemappingRowsRequireReset

GPU遇到了無法糾正的、未包含的錯誤,需要通過重設GPU進行恢複。為了恢複操作,應該儘快重設GPU。

重啟節點。

NvidiaXID44Error

  • Graphics Engine fault during context switch

  • 通常意味著在GPU上發生了不可糾正的錯誤,並且該錯誤也會報告給使用者應用程式。需要進行GPU重設或節點重啟以清除此錯誤。

重啟節點。

NvidiaXID61Error

  • Internal micro-controller breakpoint/warning (newer drivers)

  • 通常意味著在GPU上發生了不可糾正的錯誤,並且該錯誤也會報告給使用者應用程式。需要進行GPU重設或節點重啟以清除此錯誤。

重啟節點。

NvidiaXID62Error

  • Internal micro-controller halt (newer drivers)

  • 這些異常意味著在GPU上發生了不可糾正的錯誤,並且該錯誤也會報告給使用者應用程式。需要進行GPU重設或節點重啟以清除此錯誤。

重啟節點。

NvidiaXID69Error

  • Graphics Engine class error

  • 這些異常意味著在GPU上發生了不可糾正的錯誤,並且該錯誤也會報告給使用者應用程式。需要進行GPU重設或節點重啟以清除此錯誤。

重啟節點。

關於上述專案的更多資訊,例如產生的Node Condition、是否產生Event等,請參見GPU異常檢測與自動隔離

自愈過程中的節點狀態

  • 自愈任務執行中,節點狀態為修複中。

  • 自愈任務完成後,故障狀態解除,節點恢複正常狀態。

  • 自愈任務完成後,故障狀態依然存在,節點會被置為恢複失敗狀態。

    節點處於自愈失敗狀態時,不會再觸發自愈操作。相應的故障解除後,該節點才能再次進行自愈操作。

查看節點自愈事件

ACK觸發節點自愈時,會將相關事件寫入事件中心。您可以在叢集資訊頁面選擇營運管理 > 事件中心,查看自動回復的記錄和具體操作。您可以參見事件監控訂閱相關事件。

內容

層級

說明

NodeRepairStart

Normal

節點開始自愈。

NodeRepairAction

Normal

節點自愈操作,例如重啟kubelet。

NodeRepairSucceed

Normal

節點自愈成功。

NodeRepairFailed

Warning

節點自愈失敗。請參見下文的常見問題解決。

NodeRepairIgnore

Normal

節點自愈跳過,當ECS處於非運行狀態時,不對節點進行操作。

常見問題

節點自愈失敗怎麼辦?

由於故障的複雜性,自愈任務無法修複所有的故障情境。當節點自愈任務執行失敗,或者自愈執行完畢後故障並未解除,ACK會將節點標記為自愈失敗狀態。

如果某個節點自愈失敗,在損毀修復前,該節點池不會再觸發自愈操作。您可以提交工單聯絡支援人員。

相關文檔