騰訊雲帳號快速認證 騰訊雲 TKE Pod 掛載 CBS 提示 `Volume-In-Use` 鎖死排查
一、先看懂這個報錯到底在說什麼
在騰訊雲 TKE 裡，Pod 重新調度、重建或擴容時，最讓人頭疼的情況之一，就是明明節點已經換了，PVC 也在，CBS 卻一直掛不上去，事件裡反覆出現 Volume-In-Use。表面上看，像是磁碟被某個地方“佔著不放”；實際上，這通常不是雲盤真的壞了，而是 Kubernetes 的掛載狀態、節點狀態、CSI 控制器同步，和底層雲盤的使用關係沒有對齊。
簡單說，CBS 這顆雲盤在上一個節點上被認為還在使用，但集群裡的新節點又想把它掛上來。對 Kubernetes 而言，這是一種保護機制：同一塊磁碟不能同時被兩個節點以可寫方式掛載，否則容易造成資料損壞。所以當系統判斷“還在使用中”時，就會把掛載請求擋下來。
真正麻煩的是，Volume-In-Use 並不等於唯一原因。它可能是正常保護，也可能是狀態卡死。要處理這個問題，不能只看報錯，要沿著“Pod — PVC — PV — CSI — Node — CBS”整條鏈路往下查。
二、先判斷是正常佔用，還是真的鎖死
遇到這類問題，第一步不是急著刪 Pod，也不是直接重建磁碟，而是先確認是不是上個節點真的還持有這塊卷。很多人一看到事件提示，就以為磁碟卡死了，其實有時候只是節點還沒完成卸載，或者 kubelet 與 CSI 外掛之間的同步有延遲。
可以先看 Pod 狀態是否已經切換到新節點，舊 Pod 是否還在 Terminating，或者舊節點是否 NotReady。只要舊節點還在正常工作，雲盤被認定在使用中就很合理。相反，如果舊節點已經宕機、被下線、甚至在雲端實例已經不存在，但卷狀態仍然卡在使用中，那就更像是鎖死。
另一個關鍵，是看同一個 PVC 是否被多個工作負載引用。某些情況下，StatefulSet、手工建立的 Pod、測試用臨時 Pod 共用同一個 PVC，管理員以為只有一個應用在用，實際上還有別的 Pod 掛著。這時候報 Volume-In-Use 不是錯誤，而是資源衝突。
三、最常見的幾種成因
1. Pod 被強制刪除，但卸載流程沒走完
在正常刪除 Pod 的過程裡，kubelet 會先卸載卷，再把容器清掉。但如果直接強制刪除，或者節點突然異常，這個流程可能中斷。結果是：Pod 沒了，卷的掛載痕跡卻還留在節點上。Kubernetes 控制面看到的狀態，和實際節點上的狀態就不一致了。
2. 節點異常退出或重啟
節點重啟、卡死、網路中斷，都是高頻原因。當節點沒來得及向集群回報卸載成功，控制器會傾向保守處理，把卷當成仍在使用。這種情況下，新的 Pod 調度到別的節點，常常會一直卡在掛載階段。
3. CSI 控制器與節點插件狀態不同步
TKE 的 CBS 掛載依賴 CSI 驅動。控制器端記錄的是“應該掛在哪裡”，節點端反映的是“實際掛在哪裡”。只要其中一端失去同步，就可能出現卷已經被釋放，但控制器還以為沒有釋放；或者控制器已經放行，節點端仍殘留掛載資訊。這種不同步，往往是鎖死感最強的來源。
騰訊雲帳號快速認證 4. PV 回收或重新綁定過程異常
有些場景裡，PVC 被刪除後重新建立，PV 回收策略、最終化器、資料殘留都會影響下一次掛載。如果舊 PV 還沒完全清理，或者新 PVC 綁到了帶有歷史掛載痕跡的 PV，也容易引發 Volume-In-Use。
5. 同一卷被多個工作負載誤用
最典型的是測試環境。為了快速驗證，有人把同一個 CBS 卷掛給不同 Pod，或在不同命名空間複用同一份 PVC 配置。CBS 這類雲盤本質上是單節點可寫掛載，不是共享文件系統。一旦誤用，就會持續報使用中。
四、排查時應該按什麼順序看
排查這類問題，最怕跳步。建議按“應用層 — 編排層 — 節點層 — 雲盤層”一層層縮小範圍。
先看 Pod 是否真的卡在 ContainerCreating 或 Init 階段，再看事件裡是 Attach 失敗、Mount 失敗，還是 Detach 未完成。不同報錯對應的方向完全不同。如果是 Attach 失敗，通常偏向卷還在別的節點上；如果是 Mount 失敗，往往要往節點本地和 CSI 日誌查；如果是 Detach 卡住，則要看舊節點是否還在線。
接著看 PVC 與 PV 的綁定關係，確認目標卷是否正確。很多看似磁碟鎖死的問題，實際是 PVC 指向了錯誤 PV，或者同名資源在不同命名空間造成誤判。別忽略事件時間線，因為時間順序能告訴你，究竟是先發生節點異常，還是先發生卷卸載失敗。
再往下，去看節點狀態。節點是否 Ready，kubelet 是否正常，CSI node plugin 是否在跑，對排查很重要。很多時候，卷掛不上不是雲盤不行，而是節點上的掛載代理根本沒工作。
五、實戰中最有效的幾個檢查點
1. 看 Pod 事件
事件資訊是第一現場。你要關心的不只是 “Volume-In-Use” 這四個字，而是它前後的上下文。是等待 attach 的超時，還是拒絕重掛，還是正在清理舊掛載。這些細節能迅速縮小範圍。
2. 看節點是否仍有殘留掛載
如果舊節點還在，重點是確認磁碟是否還掛在本地。很多鎖死其實不是雲端鎖，而是本地掛載表沒清乾淨。只要本地還認為它被佔用，新的掛載請求就進不來。
3. 看 CSI 相關組件是否健康
控制器、節點插件、sidecar 組件，只要有一個卡住，都會讓掛載狀態長時間停留在中間態。尤其在升級、滾動重啟、資源壓力大時，最容易出現“看起來都在跑，實際上訊息沒流通”的情況。
4. 看雲端雲盤狀態
雖然大部分問題出在 Kubernetes，但雲端側狀態也不能忽略。比如卷是否還綁定在舊實例上，是否已從控制台視角完成 detach，是否有異常任務未結束。若雲端側仍認為卷在使用，集群端自然掛不上。
六、如何處理已經鎖死的場景
如果你已經確認舊 Pod 不在了，舊節點也不再可用，PVC 仍然卡在 Volume-In-Use，那就可以進入修復流程。原則只有一個：先釋放錯誤的佔用，再讓調度重新建立正確關係，不要一開始就粗暴重建業務。
常見做法是先確認該卷沒有真正被任何活躍工作負載使用，然後處理殘留的掛載痕跡。若是舊節點還存活，就應優先讓節點恢復正常卸載；若節點已經不可恢復，再考慮從控制面清除遺留狀態。這裡最忌諱的是邊查邊重建，因為你越是快速操作，越容易把掛載關係搞得更亂。
如果是 CSI 卡住，先重啟相關插件，比直接動雲盤更安全。很多情況下，重啟 node plugin 就能讓節點重新上報真實掛載狀態，控制面收到更新後，卷就能正常重新附著。當然，前提是雲盤在底層並沒有真的被別的實例佔用。
如果仍然無法恢復，再檢查 PVC 與 PV 的最終綁定狀態，確認是否需要刪除錯誤的工作負載後重新調度。處理時要非常小心資料安全，尤其是帶有業務資料的 CBS 盤，不要為了快速恢復而跳過核對步驟。
七、為什麼這類問題特別容易在 TKE 裡出現
TKE 的優點是調度靈活、擴縮容快，但也正因為這樣，節點變動、Pod 漂移、升級滾動、異常驅逐都更頻繁。對使用雲盤的狀態型應用來說，這些動作都會放大掛載一致性的風險。CBS 本身是穩定的，真正難的是容器平台與雲盤之間的協調。
另一個原因是，很多團隊把狀態型服務當成無狀態服務來運維，習慣了秒刪秒建，卻沒有為存儲的釋放和重新附著預留時間。當 Pod 被頻繁搬家時，Volume-In-Use 的概率自然會上升。換句話說，這不是單純的技術故障，也是使用方式的問題。
八、日常如何預防，少走彎路
第一，對使用 CBS 的應用，盡量避免強制刪除 Pod。正常終止能讓卸載流程完整跑完，能省掉很多後續排查時間。
第二，讓節點維護和應用遷移有節奏。節點下線、重啟、升級前，先確認上面的有狀態服務是否完成搬遷，不要讓雲盤跟著節點一起“半路失聯”。
第三，對 StatefulSet、PVC、PV 的生命週期要有明確規範。尤其是測試環境，不要圖方便共用同一個卷。共享讀寫應用要用專門的共享存儲方案，不要拿 CBS 硬頂。
第四，給 CSI 組件留足資源。控制器和節點插件一旦因 CPU、記憶體不足而抖動，最先暴露的往往就是掛載和卸載延遲。看似是存儲問題，根子卻可能是系統資源不足。
騰訊雲帳號快速認證 第五，建立標準排查清單。當團隊裡每個人都知道先看事件、再看節點、再看插件、最後看雲盤時，問題定位速度會快很多，不會一上來就全員圍著雲控制台找答案。
九、把 Volume-In-Use 當成一種狀態，而不是一句報錯
騰訊雲帳號快速認證 很多人第一次看到 Volume-In-Use，會把它理解成“磁碟被鎖住了”。其實更準確地說，它是在提醒你：系統認為這塊卷仍處於被使用狀態，這個狀態可能真實，也可能失真。排查的核心，不是和報錯對抗，而是把真實狀態找回來。
只要你能把 Pod 的生命週期、節點的健康狀態、CSI 的同步關係、雲盤的實際附著情況連成一條線，大部分鎖死問題都能定位清楚。真正棘手的從來不是 Volume-In-Use 這個提示，而是大家習慣只看表面，不願意沿著整個掛載鏈路往下查。
對運維來說，最值錢的不是把一次問題修好，而是找到重複出現的模式。當你把這些模式沉澱下來，後面再遇到 TKE Pod 掛載 CBS 卡在 Volume-In-Use，你就不會慌，因為你知道它通常只是幾類典型狀況的組合：舊節點沒放手、CSI 沒同步、PVC 用錯、或者操作太急。把這些點一個個排掉，磁碟自然會重新回到正確位置。
十、結語
TKE 裡的 CBS 掛載問題，看起來是雲盤故障，實際上大多是狀態協調問題。只要理解 Kubernetes 對卷的保護邏輯，再結合節點、CSI、PV/PVC 的實際狀態去看，就能把 Volume-In-Use 從一個讓人焦慮的報錯，變成一個可定位、可修復、可預防的日常問題。真正成熟的運維，不是從不出問題，而是每次出問題都能快速看清楚是哪一層在卡。
