騰訊雲帳號開戶 騰訊雲 TKE 使用 LocalPV 本地磁碟爆滿導致 Pod 被卡死處理
一、先看結論：LocalPV 滿了，卡住的不是一個 Pod，而是一整條鏈路
在 TKE 裡用 LocalPV，最怕的不是磁碟慢，而是磁碟真的滿了。很多人第一反應是 Pod 壞了、應用掛了，實際上常常是本地磁碟把容器、Kubelet、日誌、甚至節點上的其他服務一起拖住了。LocalPV 的核心特點就是資料綁在節點上，空間一旦打滿，Pod 很容易出現啟動失敗、寫入阻塞、刪不掉、重建不起來這幾種狀況，最後看起來就像被卡死。
這類問題最麻煩的地方，在於它不是單純把 Pod 重啟一次就能解決。只要底層磁碟問題沒有解除，Pod 重新拉起來也會再次碰壁。尤其是 StatefulSet、資料庫、日誌收集器、緩存類應用，一旦把資料和本地卷綁得太緊，故障恢復就不再是容器層面的事，而是節點存儲層面的事。
二、LocalPV 為什麼特別容易把問題放大
LocalPV 的優點很明確：性能高、延遲低、資料就在本機，少了一層網路存儲的繞路。可它的代價也很直接：Pod 的生命週期和節點生命週期綁得很死。對雲硬碟來說，磁碟滿了，還能考慮擴容、掛載、遷移；對本地卷來說，更多時候只能先想辦法騰空間，或者把資料搬到另一個節點上重建。
在 TKE 中，LocalPV 常見於有狀態服務，像資料庫、訊息隊列、搜尋引擎、快取節點等。這類工作負載本來就會持續寫資料，日誌、索引、WAL、臨時檔案也都會吃空間。如果容量規劃時只看了業務資料，沒有把日誌、碎片、臨時檔、inode 這些因素算進去，磁碟很快就會被打穿。
更要命的是，磁碟滿不一定只是容量 100%。有些情況是 inode 先耗盡，表面上還有空間，實際上已經不能再建立新檔案。對容器來說，這種情況和磁碟爆滿幾乎一樣致命：新日誌寫不進去，應用無法落盤，元資料無法建立，最後就會卡在各種看似奇怪的狀態裡。
三、先判斷卡死在哪一層，不要一上來就刪 Pod
遇到問題時，先別急著刪 Pod。先看它卡在什麼階段，因為不同階段代表的故障點不一樣。
- 如果 Pod 停在 Pending 或 ContainerCreating，優先懷疑調度、PVC 綁定、掛載失敗，或節點磁碟已經沒有可用空間。
- 如果 Pod 顯示 Running，但應用沒有回應，常見原因是程序寫磁碟時被阻塞，或者日誌、索引、資料檔無法正常落盤。
- 如果 Pod 一直 Terminating，通常是程序退出卡住，或者卷卸載失敗，底層很可能仍然有 IO 壓力。
實際排查時，可以先從 Kubernetes 層看事件，再到節點上看磁碟。最實用的順序是先確認 Pod 狀態，再確認 PVC 和 PV 綁定情況，最後看節點本地磁碟是否真的滿了。
kubectl get pod -o wide
kubectl describe pod 目標Pod
kubectl get pvc,pv
kubectl get events --sort-by=.lastTimestamp如果事件裡出現掛載失敗、節點不健康、磁碟壓力、無法建立目錄、沒有足夠空間之類的提示，基本就能把方向鎖定到本地存儲。接著登入節點看磁碟使用情況。
df -h
df -i
du -sh /var/lib/kubelet/pods/*
du -sh /var/log/*很多人只看 df -h，結果漏掉 inode。實際上，在大量小檔案場景裡，inode 先滿的概率並不低。容器日誌、短週期任務產生的臨時檔、某些緩存目錄，都可能把 inode 吃光。表面看起來還剩幾十 GB，實際上已經不能正常建立檔案了。
四、緊急止血：先讓服務停損，再談恢復
處理 LocalPV 磁碟爆滿，第一原則不是快，而是穩。因為你一旦手快亂刪，可能把還能救回來的資料直接弄沒了。建議按照這個順序處理。
1. 先停止新的寫入
如果這是對外服務，先把流量切走，或者臨時縮容，避免應用繼續往滿盤裡寫。對資料庫、隊列、索引服務來說，持續寫入只會加劇損壞風險。能先停寫就先停寫，這一步很關鍵。
2. 找出是誰把磁碟吃滿了
先分清楚是業務資料滿了，還是日誌、緩存、臨時檔爆了。如果是日誌佔大頭，處理起來相對簡單；如果是業務資料本身爆量，就要考慮遷移和擴容方案，而不是只刪幾個檔案應付。
常見的清理目標包括容器日誌、歷史壓縮包、失效的臨時檔、過期快取、應用自己產生的 debug 文件。但要注意，不要直接清空你不理解的業務目錄，尤其是資料庫目錄、索引目錄、元資料目錄。刪錯了，可能比滿盤更麻煩。
3. 優先清理可再生內容
騰訊雲帳號開戶 最安全的做法，是先清理可以重建的內容，例如老舊日誌、臨時文件、備份碎片、下載緩存。如果容器本身還在跑，可以先把輸出重定向到更合理的位置，或者暫時關閉冗餘日誌級別，避免它繼續增長。
如果節點上的容器日誌把系統盤塞滿了，要同步清理 kubelet 產生的舊日誌和應用日誌。很多時候，真正的兇手不是 PVC 里的資料，而是節點上的日誌目錄。
4. 必要時把 Pod 移走，別硬撐
如果本地卷已經無法安全使用，且業務允許短暫中斷，最實際的方式往往是把 Pod 停掉，備份能備份的資料，然後在健康節點上重新拉起。LocalPV 的思路本來就不是依賴原地無限修補，而是把資料遷到可用的節點上。對有狀態服務來說，穩住資料比硬撐在線更重要。
五、Pod 卡在 Terminating，怎麼辦
不少人以為磁碟滿只是無法寫入，實際上它還會影響刪除流程。當 Pod 長時間卡在 Terminating，通常說明容器進程沒有正常退出，或者卸載卷的過程被卡住了。這種情況下，不要急著直接強殺，先判斷資料是否仍可恢復。
如果是普通無狀態服務，且資料不在本地卷裡，可以考慮先刪 Pod，再由控制器重建。但如果是 StatefulSet 或重要資料服務，先確認卷內資料是否需要保留。因為 LocalPV 很多時候是一節點一卷，Pod 一旦離開當前節點，原資料不一定能自動帶走。
如果確認業務可以接受重建，刪 Pod 之後要觀察 PVC、PV、節點調度是否正常。如果卷上還有需要保留的數據，則應先完成備份，再進行刪除。必要時，可在節點側把可讀資料複製出來，再做後續處理。對於已經嚴重損壞、IO 長時間阻塞的情況，重啟節點有時反而比反覆殺程序更有效，但這一步一定要先評估對其他 Pod 的影響。
六、真正要解決的，不只是這一次，而是下一次
LocalPV 的故障修一次不難，難的是防止它再發生。很多磁碟爆滿事件，本質上不是突發，而是長期缺少容量管理。只要平時沒有監控、沒有預警、沒有分層存放策略，最終一定會在某個高峰時刻爆出來。
1. 容量預警一定要前置
騰訊雲帳號開戶 不要等到 100% 才報警，80% 就該開始關注，85% 要有處置動作，90% 以上最好能自動通知值班人員。對本地卷來說，留出緩衝非常重要，因為系統運行本身就需要空間，磁碟太滿時，連基本維護操作都會失效。
2. 把日誌和業務資料分開
這是很多事故裡最容易被忽略的一點。業務資料屬於核心數據，日誌屬於可控消耗。如果兩者放在一起，日誌一旦失控，會直接把業務拖垮。合理的做法是讓應用日誌走專門的收集鏈路，不要把海量日誌直接堆在 LocalPV 裡。
騰訊雲帳號開戶 3. 不要把本地卷當成可無限擴容的雲硬碟
雲硬碟和本地磁碟的使用思路完全不同。雲硬碟滿了，很多場景還能在線擴容；本地卷滿了，通常更像是一個節點級問題。你要準備的是容量冗餘、節點冗餘、資料副本和遷移方案，而不是指望原地變大。
4. 對有狀態服務做容量上限設計
如果是資料庫、搜尋引擎、消息隊列，最好在應用層就設上限。例如單分片大小、單目錄大小、單日寫入量、保留日誌天數、快取最大空間等。沒有上限的系統，最後一定是由磁碟替你做上限，而且往往是在最難看的時候。
5. 避免把單點風險藏在 LocalPV 裡
LocalPV 適合高性能、低延遲、可接受節點綁定的場景，不適合把所有重要資料都壓在單節點上。對業務來說，最穩妥的方式通常是多副本、主從架構、跨節點部署，讓某個節點磁碟出問題時，服務還能在別的地方接上。
七、實戰裡最容易踩的幾個坑
第一個坑，是只看 Pod 不看節點。很多人看到 Pod 啟動失敗，就在 Deployment 或 StatefulSet 上反覆操作，結果忘了真正滿的是節點系統盤。Pod 再怎麼重建，節點不清理，問題永遠還在。
第二個坑，是只清目錄不看資料增長趨勢。今天刪掉 20G，明天又長回 30G，說明問題不在臨時空間，而在業務本身寫入模式。要麼改保留策略，要麼調整日誌級別，要麼重新設計資料生命周期。
第三個坑，是把 LocalPV 當成所有場景的標準答案。它的確快，但不是萬能。對追求高可用和可運維性的核心業務，還是要在性能、成本、恢復能力之間做平衡。單純追求本地性能，卻忽略恢復能力，最後會把維護成本成倍放大。
八、結語：本地磁碟問題，考驗的是運維思路，不只是手速
TKE 裡用 LocalPV，磁碟爆滿導致 Pod 卡死，表面看是一次存儲故障，實際上是一次架構和運維習慣的綜合體檢。真正成熟的處理方式，不是看到告警後再去救火，而是平時就把容量監控、日誌拆分、資料遷移、節點冗餘和故障演練做起來。
一旦真的遇到滿盤，先判斷是容量滿還是 inode 滿，再看是日誌、臨時檔還是業務資料在膨脹，然後按風險高低處理。能止血就先止血，能備份就先備份，能遷移就別硬撐。對 LocalPV 來說，最忌諱的就是把一次小問題拖成整個節點的故障。把這套流程理順，Pod 卡死這件事，才不會每次都變成一場長時間拉鋸戰。
