系統設計面試：如何用 Kubernetes 裝置健康狀態治理 GPU 故障？

題幹與適用場景

一個多租戶 GPU 推理平台使用 Kubernetes Device Plugin 與 Dynamic Resource Allocation（DRA）。驅動發現某張卡斷線後，舊系統只能在節點日誌看到錯誤，Pod 繼續重啟並反覆取得同一裝置。請設計一套利用 Pod .status 中 allocatedResourcesStatus 的故障治理方案：讓維運與控制器看到裝置健康、隔離壞卡、安全處理 Unknown，並避免大規模誤刪。

Kubernetes v1.36 將資源健康狀態提升為 Beta。官方發布說明指出，狀態可在 Pod 中回報已分配裝置的健康，並可透過 kubectl describe pod 診斷 Unhealthy 或 Unknown；機制同時涵蓋傳統 Device Plugin 與 DRA 路徑。

面試官考察點

• 能否區分裝置分配成功、裝置健康、容器就緒與業務 SLO。
• 能否畫出驅動、kubelet、Pod status、控制器、排程器和告警系統的資料流。
• 能否對 Unhealthy 與 Unknown 使用不同處置，避免把觀測缺失當成硬故障。
• 能否設計冪等隔離、租約、重試、限流和恢復後再入場。
• 能否說明狀態是診斷訊號，不會自動取代排程策略或業務探針。

回答前需要釐清的問題

• 健康狀態由哪些驅動產生，更新延遲和心跳週期為何？
• 一個 Pod 可能分配多張卡；只壞一張卡時，工作能否部分降級，還是必須整體遷移？
• Unknown 是暫時失聯、節點下線還是驅動不支援？容忍窗口多長？
• 隔離粒度是裝置、節點、ResourceClaim 還是租戶工作負載？誰有權恢復？
• 工作是否有檢查點、冪等提交和最大重試預算？遷移會造成多少 GPU 抖動？

30 秒回答框架

「我會把裝置健康當作狀態輸入，而不是直接刪除 Pod 的命令。驅動和 kubelet 更新 allocatedResourcesStatus 後，控制器按裝置 ID 聚合狀態：Unhealthy 進入隔離和告警，Unknown 先經過心跳容忍窗口。控制器用冪等鍵和租約標記壞裝置，阻止新分配，已有工作依檢查點遷移；限制每個節點的重新排程。恢復時先做探針和短 canary，再解除隔離，並用狀態延遲、誤報率、遷移成功率和業務 SLO 驗證。」

分步驟深入解答

1. 定義狀態模型。 記錄裝置識別、Pod、容器、ResourceClaim、節點、健康值、訊息、觀察時間和狀態版本。把 Unhealthy（明確故障）與 Unknown（無法確認）分開，避免一個布林值驅動所有自動化。

1. 建立資料流。 DRA 或 Device Plugin 把裝置分配給 Pod，kubelet 將驅動回報的健康資訊寫入 Pod status。狀態觀察器訂閱 Pod 變化，按裝置鍵去重後寫入可重播的裝置目錄；告警和控制器都從該目錄讀取，避免各自直接掃 API 造成壓力。

1. 隔離新分配。 對明確不健康的裝置設定內部 quarantine 記錄，讓排程擴充、ResourceClaim 選擇或節點容量視圖排除它。不要直接修改 Pod status，也不要把單次異常立刻轉成節點 NotReady；隔離動作必須帶原因、操作者和到期時間。

1. 處理執行中工作。 控制器先判斷工作是否有檢查點和冪等提交，再依租約取得遷移權。可恢復工作先停止接收新請求、保存檢查點、釋放裝置並在健康裝置上重建；不可恢復工作保留失敗證據並通知租戶。每個裝置和工作只允許一個遷移流程。

1. 設計 Unknown 護欄。 Unknown 可能來自 kubelet、驅動或節點網路中斷。設定以心跳為基礎的容忍窗口和指數退避；窗口內只告警，超過窗口才限制新分配。節點整體失聯時，使用節點租約和既有故障偵測，不能僅憑一個 Pod status 推斷所有裝置損壞。

1. 恢復與驗證。 裝置重新回報健康後，先執行驅動探針、分配小型工作和持續觀察，再解除 quarantine。指標包括狀態年齡、Unknown 持續時間、誤隔離率、遷移成功率、GPU 閒置時間和業務錯誤率；用回放事件測試重複更新、亂序狀態和控制器重啟。

Device health event
  -> Pod status observer
  -> deduplicate by (node, deviceID, statusVersion)
  -> device quarantine record with lease and expiry
  -> scheduler/claim filter excludes unhealthy device
  -> checkpointed workload migration
  -> probe + canary
  -> release quarantine

高品質示範回答

我會先建立裝置級狀態目錄，把驅動、kubelet、Pod、ResourceClaim 和業務工作關聯起來。Unhealthy 是明確故障，立即建立帶租約和到期時間的 quarantine，阻止新分配並告警；Unknown 先走心跳容忍窗口，期間只告警，超過窗口再限制分配。控制器按裝置 ID 去重，重啟後可從事件和狀態目錄恢復，不依賴記憶體標記。

執行中工作是否遷移由檢查點、冪等提交和租戶優先級決定。可恢復工作保存檢查點、釋放裝置並在健康裝置上重建；不可恢復工作保留失敗證據。恢復時先做驅動探針和小規模 canary，再解除隔離。排程外掛、DRA 選擇和節點容量視圖都要消費隔離記錄，狀態本身只提供診斷訊號，不取代 readiness 或業務 SLO。我要用狀態延遲、誤報率、遷移成功率和業務錯誤率證明系統有效。

常見錯誤

• 錯誤表現： 看到 Unknown 就立刻刪除所有 Pod → 失敗原因： 短暫觀測中斷被放大成叢集抖動 → 修正方法： 使用租約、心跳窗口和限流。
• 錯誤表現： 只按節點隔離，不記錄裝置 ID → 失敗原因： 一張壞卡拖垮同節點健康裝置 → 修正方法： 以裝置和 ResourceClaim 為主鍵，必要時再提升到節點。
• 錯誤表現： 直接修改 Pod status 讓它看起來健康 → 失敗原因： 狀態來源失真，控制器可能錯誤恢復 → 修正方法： 保留 kubelet 來源，另建可稽核 quarantine 狀態。
• 錯誤表現： 裝置恢復後立即接收滿載工作 → 失敗原因： 瞬時恢復或驅動狀態尚未穩定 → 修正方法： 先探針、短 canary、逐步放量。

追問及應對

一張 GPU 失效但 Pod 還有其他 GPU，是否只遷移部分工作？

先確認框架是否支援動態縮容和重新綁定。若模型需要固定裝置拓撲，就整體遷移；若可分片，則只遷移受影響分片，並為剩餘裝置保留一致的 ResourceClaim 和檢查點語意。

狀態訊息很舊但值仍是 Healthy，怎麼辦？

把健康值和狀態年齡分開。超過心跳上限後轉為 Unknown，不要繼續把舊 Healthy 當作即時證明；告警和排程策略依狀態年齡設定護欄。

如何防止多個控制器重複遷移？

以裝置 ID、工作 ID 和狀態版本組成冪等鍵，使用帶到期時間的租約或樂觀版本更新。失去租約的控制器必須停止動作，新的控制器從持久化記錄繼續。

什麼時候可以把裝置重新放回容量池？

驅動回報健康只是必要條件。還要通過裝置探針、分配小型工作、持續觀察窗口，並確認 quarantine 原因已關閉；任一步失敗就延長隔離，不做人工強制放行。

參考資料

• Kubernetes v1.36：Haru
• Kubernetes v1.36：More Drivers, New Features, and the Next Era of DRA
• Kubernetes v1.34：Pods Report DRA Resource Health
• Dynamic Resource Allocation 文件

面試作答要點

先畫出驅動到 Pod status、觀察器、隔離記錄和排程過濾的資料流，再區分 Unhealthy 與 Unknown，最後補租約、檢查點、限流、恢復 canary 和指標。

一句話總結

裝置健康狀態讓 Kubernetes 能觀察硬體故障，但安全恢復仍需要裝置級隔離、Unknown 護欄、冪等遷移和分階段再利用。