前一篇討論「從 Pod 到請求：Logs、Metrics、Tracing 如何串起 AI Serving」，這篇聚焦「故障注入：Pod、Node、GPU 任一層出事會怎樣」，並沿用同一組輸入、環境與判讀規則，避免只做名詞比較。

今天要回答的問題

模擬 Pod crash、node unavailable、GPU error／resource unavailable，觀察 scheduler 與服務恢復。

工程邊界

AI 服務發布要把「模型狀態」也納入 rollout

一般 rolling update 假設新 Pod 很快 Ready，但大型模型可能需要數十秒甚至數分鐘載入。PDB 可以限制同時不可用的 replica；canary 可讓少量真實流量先驗證；shadow 則可以複製流量而不影響使用者回應。

發布成功的條件不只是 Pod Ready，而應包含 latency、error、GPU memory 與模型輸出 sanity check。若失敗，要能回到前一個 image／model／config 組合。

一個可以直接重現的起點

今天的實作原則

驗證時先固定環境與輸入，每次只改一個變因，並同時記錄操作方法與判定標準。

把三種故障拆開注入

這份 YAML 將「在測試 namespace 依序刪 Pod、cordon/drain node 與模擬 GPU unhealthy」的變因與觀察欄位留在版本控制中，再由實際 workload 引用。

apiVersion: v1
kind: ConfigMap
metadata:
  name: day23-experiment
  namespace: ai-lab
data:
  change: "在測試 namespace 依序刪 Pod、cordon/drain node 與模擬 GPU unhealthy"
  fixed: "image, model, input"
  metrics: "detection, reschedule, ready, user errors"
  repeats: "3"

驗證與落地方式

驗證可從「在測試 namespace 依序刪 Pod、cordon/drain node 與模擬 GPU unhealthy」開始。除了保存 manifest 的期望狀態，也要同步觀察 scheduler event、Pod 狀態轉換、node／GPU 資源與實際請求結果。Kubernetes 顯示 Running 只代表容器已啟動，不代表模型已載入、服務已 Ready，更不代表使用者請求符合 SLO。

這篇優先比較：detection、reschedule、ready、user errors。測試時應準備一組不套用目標策略的對照組，再以相同 workload 套用新策略。若 placement 改善但等待時間、重啟次數或服務錯誤增加，代表問題只是從排程層移到執行層，不能直接判定方案有效。

常見誤判

• 只看 kubectl get pods 的最終狀態，忽略 Pending reason、event 順序與 readiness 變化。
• 把 GPU allocation 當成 GPU 效率；資源已分配仍可能因 queue、I/O 或模型載入而閒置。
• 只測單一 Pod，沒有涵蓋更新、驅逐、節點失效與重新排程，無法得知真正的服務中斷時間。

上線前檢查

部署前應確認 request／limit、affinity、taint、priority、probe 與 disruption policy 是否互相一致。變更後除了檢查 rollout，也要送出代表性請求，核對服務延遲、錯誤率與 GPU 指標。回滾條件需先定義，避免故障發生後才臨時決定是否撤回。若策略依賴特定 GPU 型號或叢集功能，也要明列適用條件，避免在不同 node pool 套用後得到相反結果。

如何閱讀結果

排程結果要和服務結果放在同一條時間線：先看 Pod 為何被放到某個節點，再看模型何時 Ready，最後核對請求是否成功。只改善 placement 卻讓 cold start 或資料下載變慢，仍然可能造成更長的使用者等待時間。

策略通過單次測試後，還要在 rollout、drain 與節點重新加入時重跑。這些事件會重新觸發排程與模型載入，最容易暴露 topology、storage、probe 與 disruption policy 之間的衝突。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：分清 Pod、node、GPU 三種故障的恢復責任。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：分清 Pod、node、GPU 三種故障的恢復責任。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：PDB、Rolling Update 與 AI 服務可用性。

參考資料

• Kubernetes: Schedule GPUs
• Kubernetes: Resource Management
• Kubernetes: Assigning Pods to Nodes
• NVIDIA DCGM Documentation