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

Kubernetes 1.28：非平滑節點關閉功能進入 GA 階段

作者：Xing Yang (VMware), Ashutosh Kumar (Elastic) |

Kubernetes 的“節點非體面關閉（Non-Graceful Node Shutdown）”功能現已在 Kubernetes v1.28 中正式釋出（GA）。該功能在 Kubernetes v1.24 中作為 Alpha 版本引入，並在 Kubernetes v1.26 中升級為 Beta 版本。如果原始節點意外關閉或進入不可恢復狀態（例如硬體故障或作業系統無響應），此功能允許有狀態工作負載在另一個節點上重新啟動。

什麼是非體面關閉

在 Kubernetes 叢集中，節點可以以計劃好的體面方式關閉，也可能由於斷電或其他外部原因而意外關閉。如果在關閉前沒有騰空（drain）節點，節點關閉可能導致工作負載故障。節點關閉可以是體面的，也可以是非體面的。

節點體面關閉功能允許 Kubelet 在實際關閉前檢測到節點關閉事件，從而正確終止 Pod 並釋放資源。

當節點關閉但未被 Kubelet 的節點關閉管理器檢測到時，這就成了非體面節點關閉。非體面節點關閉通常對無狀態應用不是問題，但對有狀態應用來說是個問題。如果 Pod 卡在已關閉的節點上，並且沒有在執行中的節點上重新啟動，有狀態應用程式就無法正常執行。

在節點非體面關閉的情況下，你可以手動為該節點新增一個 out-of-service 汙點。

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

如果 Pod 上沒有匹配的容忍度，此汙點會觸發強制刪除節點上的 Pod。附加到已關閉節點的持久卷將被分離，新的 Pod 將在另一個執行中的節點上成功建立。

注意： 在應用 out-of-service 汙點之前，你必須確認該節點已經處於關閉或斷電狀態（而不是正在重啟）。

一旦與該“停止服務”節點相關的所有工作負載 Pod 都轉移到了一個新的執行節點上，並且關閉的節點已經恢復，你應該在該節點恢復後移除受影響節點上的該汙點。

穩定版有哪些新內容

隨著“節點非體面關閉”功能升級到穩定版，特性門控 NodeOutOfServiceVolumeDetach 在 kube-controller-manager 中被鎖定為 true，無法停用。

Pod GC 控制器中的指標 force_delete_pods_total 和 force_delete_pod_errors_total 得到了增強，以涵蓋所有強制性 Pod 刪除。指標中增加了一個 `reason` 欄位，以表明 Pod 被強制刪除的原因是已終止、孤立、因 `out-of-service` 汙點而終止，還是正在終止且未被排程。

Attach Detach 控制器中的指標 attachdetach_controller_forced_detaches 也增加了一個 `reason` 欄位，以表明強制分離是由 `out-of-service` 汙點還是超時引起的。

下一步是什麼？

此功能需要使用者手動向節點新增汙點以觸工作負載的故障轉移，並在節點恢復後移除汙點。未來，我們計劃尋找方法來自動檢測和隔離已關閉/失敗的節點，並自動將工作負載故障轉移到另一個節點。

我如何瞭解更多資訊？

在此處檢視關於此功能的更多文件：點選這裡。

如何參與？

我們非常感謝所有為該功能的設計、實現和審查做出貢獻，並幫助其從 Alpha、Beta 階段推進到穩定版的貢獻者們。

此功能是 SIG Storage 和 SIG Node 之間的合作成果。對於有興趣參與 Kubernetes 儲存系統任何部分的設計和開發的同仁，請加入 Kubernetes 儲存特別興趣小組（SIG）。對於有興趣參與支援 Pod 和主機資源之間受控互動的元件設計和開發的同仁，請加入 Kubernetes Node SIG。