阿里雲帳號代充值 阿裡雲容器服務 ACK 節點狀態顯示 NotReady 原因排查（Kubelet/CRI 異常）

先看懂 NotReady 代表什麼

在阿里雲容器服務 ACK 里，節點狀態變成 NotReady，通常不是單一元件報錯，而是節點無法穩定向控制面匯報自己仍然健康。對業務來說，這意味著調度器會逐步把工作負載從這個節點上趕走，或者不再把新 Pod 放上去。很多人一看到 NotReady 就先懷疑網路，其實更常見的根因，往往落在 kubelet 本身、容器運行時 CRI、節點資源耗盡，或系統層面已經發生不可忽視的異常。

理解 NotReady 的關鍵，不是只看控制台的紅字，而是要把它拆成兩層：第一層是節點有沒有失去心跳，第二層是 kubelet 能不能正常和容器運行時、內核、磁碟、證書系統協同工作。前者決定節點是否還在線，後者決定它能不能持續承擔工作負載。排查時如果只盯著表象，很容易繞一大圈還是回到原點。

最常見的幾類根因

kubelet 自身失效

kubelet 是節點和控制面之間最直接的橋樑。它一旦停止、卡死、反覆重啟，或因配置錯誤而無法正常上報狀態，節點就很容易顯示 NotReady。這類問題的表現通常比較直接：Node Condition 裡的 Ready 變成 False，事件里會出現心跳超時、Kubelet not ready、PLEG unavailable、container runtime not ready 之類的提示。若 kubelet 連啟動都起不來，節點往往會在短時間內快速掉線。

常見觸發點包括 kubelet 配置被誤改、證書過期、cgroup 驅動不一致、節點磁碟滿導致寫入失敗，以及系統升級後內核參數與 kubelet 版本不兼容。這些問題不一定在第一時間爆炸，但一旦壓力上來，就會以 NotReady 的形式暴露出來。

CRI 或容器運行時異常

ACK 節點常見的容器運行時是 containerd，也可能因版本或配置不同出現其他 CRI 實現。當 runtime 卡住、socket 不通、shim 子進程堆積、鏡像拉取失敗或 runtime 啟動異常時，kubelet 會認為節點無法正常管理容器，從而把節點標成 NotReady。這類情況很容易誤判成 kubelet 問題，因為 kubelet 和 CRI 是緊密耦合的，表面上看都是節點沒上報，實際根因卻可能在 runtime。

一個很典型的現象是：kubelet 進程還在，systemctl 看起來也正常，但事件里反覆出現 container runtime is down、failed to connect to CRI socket、runtime service unavailable。這時若只重啟 kubelet，往往只能短暫恢復，真正的問題還卡在 containerd 或其依賴上。

磁碟、內存和 I/O 壓力

節點資源耗盡也是 NotReady 的高頻原因。當磁碟空間接近耗盡，kubelet 可能無法寫入狀態文件、pod 日志、臨時目錄或證書更新文件；當磁碟 inode 用盡時，表面上還有空間，實際也會寫不進去。內存壓力過高時，內核可能直接啟動 OOM 機制，導致 kubelet 或 containerd 被殺掉。I/O 被打滿時，kubelet 即便沒崩，也可能因超時而無法按時回應，節點狀態就會抖動甚至掉到 NotReady。

這類故障的難點在於，它往往不是單點故障，而是長時間積累後的結果。例如應用日志暴增、臨時文件沒有清理、鏡像層太多、監控採集過重，最後一起把節點拖垮。若不解決資源壓力，重啟只是把故障延後。

證書與時間問題

節點和控制面之間需要可靠的 TLS 通信。如果 kubelet 客戶端證書過期，或者節點時間漂移過大，TLS 驗證就會失敗，控制面無法正確接收節點心跳。這類問題常被忽略，因為它不像崩潰那樣明顯，但一旦證書輪轉異常，NotReady 會持續存在，且重啟進程未必能解決。對一些長時間未維護的節點，證書過期尤其常見。

排查順序比命令更重要

遇到 NotReady，不建議一上來就亂重啟。比較穩妥的做法，是先判斷問題層級，再決定下手位置。可以把排查分成三步：先看控制台與事件，再看節點服務與日志，最後看系統資源與底層狀態。這樣的好處是，能快速把故障定位到 kubelet、CRI 還是系統層，而不是在不同面板之間來回切換。

第一步：確認節點與事件信息

先在 ACK 控制台或通過 `kubectl get node` 看節點的 Ready 狀態，接著用 `kubectl describe node` 查看條件和事件。關注的不是那些看起來很長的輸出，而是幾個關鍵詞：Ready 是否變 False，Reason 是什麼，LastHeartbeatTime 是否長時間沒更新，事件是否反覆出現心跳丟失、runtime not ready、disk pressure、memory pressure。

如果事件里同時出現多種警告，要注意先後順序。比如先是磁碟壓力，後是 kubelet 無法寫入，再後是節點 NotReady，那真正的起點大概率是磁碟，而不是 kubelet 本身。很多排障失誤，就是因為只盯著最後一條報警。

第二步：看 kubelet 和容器運行時

進入節點後，先看服務狀態，再看最近日志。常用命令包括 `systemctl status kubelet`、`systemctl status containerd`、`journalctl -u kubelet -f`、`journalctl -u containerd -f`。如果 kubelet 反覆退出，日志里通常能看到更直接的提示，例如配置文件缺失、證書錯誤、無法連接 CRI socket、PLEG 超時、cgroup 不匹配、無法向 API Server 註冊節點等。

當 containerd 出問題時，還要觀察它是否真的在跑，socket 是否可連，是否有大量 shim 殘留進程，是否存在 image service 或 runtime service 調用超時。此時不要只看服務 active 不 active，還要看它是否只是進程活著但功能已經半死不活。對 kubelet 來說，這種狀態和完全停掉沒有本質區別。

阿里雲帳號代充值 第三步：檢查資源與內核

如果服務表面正常，就轉向系統層。先看磁碟：`df -h`、`df -i`。再看內存：`free -m`、`top`。再看系統日志中是否有 OOM、I/O error、filesystem read-only、cgroup failure 等關鍵字。很多節點在被磁碟寫滿後，文件系統會被動變成只讀，這時即便重啟部分服務，也會因無法寫文件而再次失敗。

還要特別留意時間同步。若節點時間偏差過大，TLS 驗證、證書輪轉和事件同步都可能出現異常。對排障來說，NTP 或 chrony 狀態雖然常被當成邊角問題，但在節點狀態異常時，這些細節往往決定你能不能順利恢復。

幾個高頻故障場景

場景一：containerd 卡死但 kubelet 還在

這是最容易誤判的一種。表面上 kubelet 還在運作，節點卻已經 NotReady，事件里出現 CRI 不可用。這時應該先處理 runtime，再觀察 kubelet 是否自動恢復。如果只是重啟 kubelet 而不看 containerd，幾分鐘後節點通常還會掉回去。

恢復時可以先確認容器業務是否已經被驅逐，避免在節點恢復前繼續承壓。若 containerd 無法正常啟動，還需要進一步查看它的配置文件、鏡像目錄、存儲驅動、殘留 shim 以及磁碟狀態。只有把底層恢復干淨，kubelet 才有機會重新註冊成功。

場景二：磁碟滿導致連鎖故障

這類問題的典型特徵是，最初只是某些 Pod 日志異常增長，接著 kubelet 開始報錯，然後節點狀態轉成 NotReady。真正的修復思路不是直接重啟，而是先騰空磁碟、清理無效日志、刪除過期鏡像、釋放 inode，再修復服務。若文件系統已經只讀，則要先處理掛載與文件系統完整性問題，否則重啟也只是徒勞。

場景三：證書過期或輪轉失敗

這類故障通常在節點運行較久後發生，尤其是平時維護不充分的集群。排查時如果看到 kubelet 能啟動，但無法和 API Server 正常通訊，並伴隨 x509 相關報錯，就要高度懷疑證書問題。此時需要確認證書有效期、輪轉策略以及節點時間是否正確。很多現場案例里，真正拖慢恢復的不是技術複雜度，而是沒能及時把證書問題列入優先級。

恢復後不要急著收工

阿里雲帳號代充值 節點重新回到 Ready，不代表事情就完全結束。更重要的是確認它是否穩定，而不是僅僅短暫回綠。建議觀察一段時間，看 kubelet 是否還有異常重啟，containerd 是否還有報錯，節點事件是否再次出現 Ready False。對業務影響較大的節點，還應檢查 Pod 是否已經正常回遷，關鍵服務是否有重建和探針失敗的後遺症。

如果節點曾經因資源耗盡而掉線，還要回頭看為什麼會耗盡。是單個業務異常膨脹，還是監控、日志、臨時文件、鏡像層疊加導致。若只是簡單清理而不做根因治理，NotReady 會成為反覆發作的老問題。真正有價值的排障，不只是把節點拉回來，還要避免下次再掉下去。

平時怎麼降低 NotReady 風險

阿里雲帳號代充值 把監控做在問題前面

不要等節點 NotReady 才去看。對 kubelet、containerd、磁碟空間、inode、內存、CPU、文件系統只讀、證書有效期這些指標，應該提前設置告警。當磁碟剩餘空間下降到危險區間時，提前清理；當容器運行時出現重啟風暴時，及早介入；當證書快到期時，提前安排輪轉。

把節點維護做成習慣

節點不是一次性資源。定期檢查系統更新、容器運行時版本、kubelet 參數、日志保留策略與時間同步，能避免很多低級故障。對長時間運行的節點，建議建立週期性巡檢清單，至少把磁碟、inode、證書和服務狀態納入日常維護。這些動作看似瑣碎，但它們能顯著降低 NotReady 的概率。

最後要記住一點：ACK 節點顯示 NotReady，不是一個孤立標籤，而是整個節點健康狀態的結果。只要把 kubelet、CRI 和系統資源三條線一起看，很多看似複雜的故障，其實都能很快收斂到少數幾個根因。排障時保持順序、保留證據、先止血後追因，通常比盲目重啟更可靠，也更接近真正的工程處理方式。