本篇僅有原文版本。

AKS 節點 LUN 用盡：一次 PVC 掛載失敗的完整拆解

事情從一個很不起眼的告警開始：某個 StatefulSet 的 Pod 卡在 ContainerCreating，已經十二分鐘。叢集其他工作負載一切正常，節點狀態 Ready，資源用量看起來也不緊張。如果只看儀表板，你會覺得什麼事都沒發生。

先確認故障域

我的習慣是先問一個問題：這是「這個 Pod 的問題」還是「這個節點的問題」。方法很粗暴但有效——把 Pod 刪掉，看它排到別的節點上會不會好。

kubectl get pods -o wide -n data

如果換節點就正常，答案已經縮小了一半。

每台 VM 能掛幾顆磁碟，是有上限的

Azure 的每個 VM SKU 都有「最大資料磁碟數」的限制，而這個數字往往比人們預期的小得多。這個限制不是軟性建議，是硬性的——LUN 位置用完就是用完了。

容易被忽略的細節：Pod 被驅逐之後，磁碟的卸載不是瞬間完成的。在卸載完成前，那個 LUN 位置仍然被佔著。

真正該修的是可觀測性

把 Pod 弄回 Running 不算解決問題。真正的問題是這個故障完全沒有預警。雲端平台的硬性限制幾乎都不會主動出現在你的監控裡；你得自己去把它們找出來、量化、然後接上告警。