當叢集開始回報 Kubernetes 節點 NotReady 時，有經驗的維運人員都知道，故障影響範圍往往會迅速擴大。一個工作節點一旦停止回報健康狀態，就可能打亂調度、觸發驅逐，並讓業務負載進入不穩定狀態。在真實的伺服器租用與伺服器託管環境中，最快的恢復方式並不是憑經驗盲猜，而是有條理地檢查節點狀態、本地執行時健康狀況、系統資源，以及與控制平面的連通性。本文將圍繞一套務實的恢復流程展開，面向希望獲得高價值技術資訊，而非空泛描述的技術讀者。

NotReady 在節點層面究竟代表什麼

在 Kubernetes 中，節點健康狀態透過一組狀態條件來發布，其中最關鍵的是 Ready。當這個條件切換為 False 時，表示該節點已不再被視為足夠健康，無法繼續正常接收新的工作負載調度。官方文件也指出，當 Ready 條件持續異常一段時間後，控制平面可能會為該節點加入 not-ready taint，這會影響調度行為，並根據 toleration 設定進一步影響正在執行的工作負載。

節點進入此狀態的原因可能很多，但其底層機制很直接：

  • 節點代理停止回報健康狀態。
  • 控制平面未能如預期收到心跳或租約更新。
  • 資源壓力或網路異常將節點標記為不健康。
  • 排程器與控制器開始將該節點視為不可靠目標。

也就是說，NotReady 並不是根本原因，而是叢集對外顯示出的症狀。真正的任務，是找出最先失效的子系統，並恢復節點、本地執行時與 API 端點之間最基本的信任鏈路。Kubernetes 官方文件介紹了節點心跳依賴狀態更新與 Lease 物件，因此無論是代理健康還是網路路徑，在排查中都至關重要。

導致節點進入 NotReady 的常見故障領域

大多數故障事件都可以歸類為幾個高度重複的類型。按照故障領域來組織思路，可以明顯縮短恢復時間，因為每一類問題都會在日誌與狀態條件中留下不同痕跡。

  • 節點代理故障：本地代理服務停止、卡住、設定錯誤，或無法完成認證。
  • 容器執行時異常：執行時 socket 不可用、服務當機，或執行時介面設定錯誤。
  • 網路路徑問題：節點無法存取 API 端點、DNS 發生故障，或覆蓋網路不健康。
  • 資源壓力：磁碟、記憶體或程序資源壓力使節點進入降級狀態。
  • 啟動或維護漂移：節點重新啟動後，服務啟動順序、憑證或設定檔未能正確恢復。

官方節點狀態說明列出了常見條件，例如 DiskPressure、MemoryPressure、PIDPressure 與 NetworkUnavailable。這些條件往往是排查的第一條線索，因為它們能在無需深入取證的前提下，快速縮小問題範圍。

先做最高訊噪比的快速檢查

首輪排查的目標只有一個：判斷該節點是被隔離了、被壓垮了，還是內部元件本身已經失效。不要一開始就重新啟動。重新啟動雖然看似簡單，卻可能掩蓋原始故障特徵；而如果儲存、網路或憑證本就處於異常狀態，盲目重新啟動還可能讓恢復更複雜。

  1. 先確認節點是 NotReady 還是 Unknown。
  2. 檢查節點狀態條件與最近事件。
  3. 確認節點代理服務是否處於活動狀態。
  4. 確認容器執行時是否處於活動狀態且可存取。
  5. 檢查磁碟、記憶體、inode 以及程序壓力。
  6. 從節點測試到 API 端點的可達性。
  7. 只有在基礎項目都通過後，再深入檢查網路元件。

通常一組簡短的指令就足以提供足夠的上下文，幫助你選擇正確的修復分支：

  • kubectl get nodes
  • kubectl describe node <node-name>
  • systemctl status kubelet
  • journalctl -u kubelet -xe
  • systemctl status containerd
  • df -h 與 free -m

如果節點代理仍在執行，卻無法維持註冊狀態，那麼日誌通常會指向認證、執行時或網路問題。如果節點代理已經停止，應優先恢復它。如果節點代理健康而執行時已失效，則先修復執行時。這個順序非常關鍵，因為僅僅恢復健康的執行時，並不能讓節點重新變為 Ready；節點代理必須能夠重新向上游成功回報狀態。Kubernetes 執行時文件同樣指出，如果執行時介面不可用或設定錯誤，節點註冊就可能失敗。

在接觸伺服器之前，先讀取節點物件

節點物件能提供的資訊，往往比很多人預想得更多。使用 describe 輸出時，不要把它當作機械式檢查項，而應把它當作一張地圖。重點關注狀態條件、污點以及事件流。

  • Ready=False：節點仍有一定連通性，足以回報「不健康」狀態。
  • Ready=Unknown：控制平面已經無法穩定收到該節點的狀態。
  • Pressure conditions：很可能存在本地資源耗盡。
  • NetworkUnavailable：叢集網路層面值得優先懷疑。
  • Not-ready taint：排程行為已經發生變化。

官方文件說明，當 Ready 心跳異常或缺失時，系統可能會加入諸如 node.kubernetes.io/not-ready 或 node.kubernetes.io/unreachable 這樣的污點。這個差異在維運上非常實用：False 往往表示節點仍能通訊，但狀態不健康；而 Unknown 則更常表示通訊鏈路已經中斷。

修復路徑一：乾淨地恢復節點代理

如果節點代理已停止，或日誌中顯示啟動失敗，那麼應將它視為首要故障點。常見原因包括無效參數、憑證過期、設定引用錯誤，或者無法連線到執行時 socket。修復動作應盡量簡潔，並確保可回滾。

  1. 先檢查服務狀態，閱讀最近日誌後再決定是否重新啟動。
  2. 驗證設定中的執行時端點以及本地憑證是否正確。
  3. 確認主機名稱與節點身分仍然符合目前叢集預期。
  4. 完成修改後，重新啟動服務並即時觀察最新日誌。

不要忽視那些看起來並不明顯的認證錯誤。有些節點在本地 shell 中看似一切正常，卻依然無法完成註冊或心跳更新。Kubernetes 官方也指出，節點代理負責節點狀態回報以及 Lease 更新，因此它的任何異常都會直接影響就緒狀態的可見性。

修復路徑二：恢復容器執行時

容器執行時一旦損壞，表面現象往往會讓人誤以為是節點代理的問題，但真正的故障可能隱藏在更底層。如果執行時服務已停止、卡住，或者暴露了錯誤的介面，Pod 生命週期操作就會停滯，節點就緒狀態也可能隨之崩潰。

  • 確認執行時服務處於活動狀態。
  • 檢查執行時 socket 路徑是否與節點代理設定一致。
  • 查看啟動日誌中是否存在外掛、介面或設定解析錯誤。
  • 如果執行時明顯異常，先重新啟動執行時，再重新啟動節點代理。

Kubernetes 官方執行時指引強調，執行時必須支援預期的介面版本，而圍繞執行時介面的設定錯誤可能直接導致節點註冊失敗。

當執行時恢復後，也不要立刻宣告問題已解決。還需要確認節點代理已可以重新與其通訊，然後再次檢查節點物件。因為即便執行時成功啟動，只要它仍無法為 Pod 建立沙箱網路，節點依舊談不上穩定。

修復路徑三：處理網路與 CNI 漂移

網路故障通常更棘手，因為它們可能偽裝成控制平面失聯、Pod 沙箱建立失敗，或間歇性的就緒狀態抖動。如果節點主機網路本身可達，但 Pod 無法完成網路初始化，就應仔細檢查本地 CNI 設定與執行時日誌。

  • 確認節點能夠解析並存取 API 端點。
  • 檢查本地 CNI 設定檔是否存在語法或版本不匹配。
  • 從執行時日誌中查找沙箱網路或網路命名空間錯誤。
  • 只有在確認設定有效後，再重新啟動網路元件。

Kubernetes 關於 CNI 相關錯誤的疑難排解說明指出，外掛行為與設定不匹配時，工作負載可能會陷入卡住狀態，正確做法應是先修正設定，再重新啟動執行時與節點代理。

在伺服器租用與伺服器託管環境中，也應順便檢查近期是否發生防火牆規則變更、MTU 不匹配，或維護視窗後的路由漂移。這類問題常常會在一次看似正常的重新啟動之後集中暴露出來。

修復路徑四：清除本地資源壓力

資源壓力類問題往往最容易驗證，卻也最容易被低估。節點並不需要完全耗盡磁碟或記憶體，才會進入功能性異常狀態。日誌膨脹、映像堆積、inode 耗盡，以及失控程序，都可能足以把它推向邊緣。

  1. 檢查可用磁碟空間以及 inode 使用率。
  2. 檢查可用記憶體，以及如適用時的 swap 行為。
  3. 查找過量日誌、失效沙箱與遺留無用產物。
  4. 謹慎清理無效資料，並僅在必要時重新啟動相關服務。

節點狀態模型明確包含磁碟、記憶體與程序壓力條件，因此一旦這些標誌被觸發，就應將其視為一級故障原因，而不是附帶雜訊。

用一句更「極客」的話來說：如果一台機器已經把大部分精力用在自我防禦上，而不是服務工作負載，那麼就緒狀態受損幾乎是必然結果。把節點清理到讓核心、執行時與代理都重新擁有喘息空間，往往才是真正的恢復。

什麼時候應該重新加入叢集，而不是原地修補

有時候，最短路徑並不是精細修補，而是進行一次可控替換。如果節點持續出現憑證問題、設定嚴重漂移，或在失敗升級後遺留了混亂狀態，那麼與其不斷疊加臨時補丁，不如直接重新加入叢集更穩妥。

  • 當節點身分或信任鏈已經損壞時，優先考慮重新加入。
  • 當本地設定變更歷史已不再可信時，優先考慮重新加入。
  • 當節點在 Ready 與 NotReady 之間頻繁抖動時，優先考慮重新加入。
  • 如果業務允許控制中斷，則可在 drain 後執行重新加入。

這種策略尤其適用於可替換型工作節點模式，但即使在更靜態的伺服器託管部署中，它同樣能有效縮短恢復至穩定狀態的時間。關鍵在於保持流程紀律：能 drain 就先 drain，記錄為何重建該節點，並確認替換後的節點不會繼承同樣的故障模式。

恢復後的驗證檢查

很多團隊會在這裡停得太早。kubectl get nodes 中節點重新變綠固然重要，但這只是必要條件，而不是充分條件。你真正需要的是整條就緒鏈路已恢復健康的證據。

  1. 確認節點顯示為 Ready。
  2. 確認資源壓力與網路條件都恢復正常。
  3. 確認新的 Pod 可以在該節點上排程並成功啟動。
  4. 確認執行時與節點代理日誌在恢復後保持安靜。
  5. 確認沒有新的警告事件持續累積。

如果節點雖然回到了 Ready，卻很快再次掉回異常狀態，就不要繼續陷入反覆重新啟動服務的循環。這通常表示原始故障只是被暫時掩蓋，而非真正修復。此時應回到最先失敗的依賴項，從那裡重新往前追蹤。

維持叢集穩定運行的預防策略

最快的恢復，往往是那些原本就很少需要恢復的系統。針對節點健康的預防性工程看似不夠炫目，但每逢叢集需要承受維護視窗、流量波動或檔案系統膨脹時，它都會帶來實實在在的回報。

  • 主動追蹤節點狀態條件與 Lease 行為。
  • 為日誌、映像與系統守護程序預留足夠本地資源餘量。
  • 在核心或設定變更後測試節點重新啟動行為。
  • 確保各節點之間的執行時與 CNI 設定一致。
  • 在正式事故發生之前，先演練節點替換流程。

Kubernetes 官方文件強調，節點可用性依賴穩定的心跳與健康的本地狀態回報。因此，圍繞節點代理、Lease 活動、資源壓力以及網路路徑建立預防性監控，通常比單純依賴通用可用性檢查更有價值。

總結

快速恢復一次 Kubernetes 節點 NotReady 事件，關鍵不在於死記硬背零散指令，而在於尊重依賴順序。先讀取節點物件，再驗證節點代理，再驗證執行時，然後檢查資源壓力，最後在證據明確指向時，再進入網路修復或重新加入流程。對於在伺服器租用或伺服器託管環境中運行叢集的技術團隊而言，這種方法能讓排障過程更銳利、更可複用，也更「無聊」——而在基礎設施維運領域，這恰恰是一種優點：故障影響範圍更小，根因更容易暴露，叢集也能在盡可能少的戲劇性波動中恢復工作。