本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 1.26：非正常節點關閉功能移至 Beta 階段

作者：Xing Yang (VMware)、Ashutosh Kumar (VMware) | 2022 年 12 月 16 日星期五

Kubernetes v1.24 導入了處理非正常節點關閉的改進措施的 Alpha 品質實作。在 Kubernetes v1.26 中，此功能移至 Beta 版。此功能允許具狀態工作負載在原始節點關閉或處於無法復原的狀態（例如硬體故障或作業系統損壞）後，容錯移轉至不同的節點。

什麼是 Kubernetes 中的節點關閉？

在 Kubernetes 叢集中，節點可能會關閉。這可能以計畫的方式發生，也可能意外發生。您可能會規劃安全性修補程式或核心升級，而需要重新啟動節點，或者節點可能會因 VM 執行個體搶佔而關閉。節點也可能因硬體故障或軟體問題而關閉。

若要觸發節點關閉，您可以在 Shell 中執行 shutdown 或 poweroff 命令，或實際按下按鈕以關閉機器電源。

如果未在關閉前排空節點，節點關閉可能會導致工作負載失敗。

在下文中，我們將描述什麼是正常節點關閉，什麼是非正常節點關閉。

什麼是正常節點關閉？

kubelet 處理正常節點關閉允許 kubelet 偵測節點關閉事件、正確終止該節點上的 Pod，並在實際關閉前釋放資源。重要 Pod 會在所有常規 Pod 終止後終止，以確保應用程式的基本功能可以盡可能長時間地繼續運作。

什麼是非正常節點關閉？

只有在 kubelet 的節點關閉管理員可以偵測到即將發生的節點關閉動作時，節點關閉才能是正常的。但是，在某些情況下，kubelet 無法偵測到節點關閉動作。這可能是因為 shutdown 命令未觸發 kubelet 在 Linux 上使用的 Inhibitor Locks 機制，或是因為使用者錯誤。例如，如果未針對該節點正確設定 shutdownGracePeriod 和 shutdownGracePeriodCriticalPods 詳細資訊。

當節點關閉（或崩潰）且該關閉未被 kubelet 節點關閉管理員偵測到時，它會變成非正常節點關閉。非正常節點關閉對於具狀態應用程式而言是個問題。如果包含屬於 StatefulSet 一部分的 Pod 的節點以非正常方式關閉，則 Pod 將無限期地停留在 Terminating 狀態，並且控制平面無法在健康的節點上為該 StatefulSet 建立替換 Pod。您可以手動刪除失敗的 Pod，但這對於自我修復叢集而言並不理想。同樣地，ReplicaSet 建立的 Pod 作為 Deployment 的一部分，將停留在 Terminating 狀態，並且繫結到現在已關閉的節點，無限期地保持為 Terminating 狀態。如果您已設定水平擴展限制，即使是那些終止中的 Pod 也會計入限制，因此如果您的工作負載已達到最大規模，則可能難以自我修復。（順帶一提：如果已執行非正常關閉的節點重新啟動，kubelet 會刪除舊的 Pod，而控制平面可以建立替換。）

Beta 版的新功能是什麼？

對於 Kubernetes v1.26，非正常節點關閉功能為 Beta 版，並且預設為啟用。NodeOutOfServiceVolumeDetach 功能閘道預設在 kube-controller-manager 上啟用，而不是選擇加入；如果需要，您仍然可以停用它（也請提交問題以說明問題）。

在儀表方面，kube-controller-manager 報告了兩個新的指標。

force_delete_pods_total: 正在強制刪除的 Pod 數量（在 Pod 垃圾收集控制器重新啟動時重設）
force_delete_pod_errors_total: 嘗試強制 Pod 刪除時遇到的錯誤數量（也在 Pod 垃圾收集控制器重新啟動時重設）

它是如何運作的？

在節點關閉的情況下，如果正常關閉無法運作，或者節點由於硬體故障或作業系統損壞而處於無法復原的狀態，您可以手動在節點上新增 out-of-service 污點。例如，這可以是 node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 或 node.kubernetes.io/out-of-service=nodeshutdown:NoSchedule。如果 Pod 上沒有相符的容忍度，此污點會觸發強制刪除節點上的 Pod。連接到關閉節點的持續性磁碟區將會分離，並且新的 Pod 將會在不同的執行中節點上成功建立。

kubectl taint nodes <node-name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute

注意： 在套用 out-of-service 污點之前，您必須驗證節點是否已處於關閉或斷電狀態（而非處於重新啟動的中間），原因是用戶有意關閉它，或是節點因硬體故障、作業系統問題等而關閉。

一旦所有連結到 out-of-service 節點的工作負載 Pod 都移至新的執行中節點，並且關閉的節點已復原，您應該在節點復原後移除受影響節點上的該污點。

下一步是什麼？

根據回饋和採用情況，Kubernetes 團隊計畫在 1.27 或 1.28 版本中將非正常節點關閉實作推向正式發布 (GA)。

此功能需要使用者手動將污點新增至節點，以觸發工作負載的容錯移轉，並在節點復原後移除污點。

叢集運營商可以自動化此流程，方法是如果可以透過程式化方式判斷節點是否真的關閉，並且節點與儲存裝置之間沒有 IO，則自動套用 out-of-service 污點。然後，叢集運營商可以在工作負載成功容錯移轉到另一個執行中節點且關閉的節點已復原後，自動移除污點。

未來，我們計畫尋找方法來自動偵測和隔離關閉或處於無法復原狀態的節點，並將其工作負載容錯移轉到另一個節點。

如何瞭解更多資訊？

若要瞭解更多資訊，請閱讀 Kubernetes 文件中的非正常節點關閉。

如何參與？

我們非常感謝所有協助設計、實作和審查此功能的貢獻者

Michelle Au (msau42)
Derek Carr (derekwaynecarr)
Danielle Endocrimes (endocrimes)
Tim Hockin (thockin)
Ashutosh Kumar (sonasingh46)
Hemant Kumar (gnufied)
Yuiko Mouri(YuikoTakada)
Mrunal Patel (mrunalp)
David Porter (bobbypage)
Yassine Tijani (yastij)
Jing Xu (jingxu97)
Xing Yang (xing-yang)

在整個過程中，有許多人協助審查設計和實作。我們要感謝所有為此工作做出貢獻的人，包括大約 30 位審查了過去幾年 KEP 和實作的人。

此功能是 SIG Storage 和 SIG Node 之間的協作。對於那些有興趣參與 Kubernetes 儲存系統任何部分的設計和開發的人，請加入 Kubernetes Storage Special Interest Group (SIG)。對於那些有興趣參與設計和開發支援 Pod 和主機資源之間受控互動的元件的人，請加入 Kubernetes Node SIG。