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

Kubernetes 1.28:非正常節點關閉移至 GA

Kubernetes 非正常節點關機功能現已在 Kubernetes v1.28 中正式發布 (GA)。它在 Kubernetes v1.24 中以 alpha 版本推出,並在 Kubernetes v1.26 中升級為 beta 版本。此功能允許具狀態工作負載在原始節點意外關機或最終處於無法恢復的狀態(例如硬體故障或作業系統無回應)時,於不同的節點上重新啟動。

什麼是非正常節點關機?

在 Kubernetes 叢集中,節點可能以計畫性的正常方式關機,或因停電或其他外部原因而意外關機。如果節點在關機前未被清空 (drained),則節點關機可能會導致工作負載失敗。節點關機可以是正常或非正常的。

正常節點關機功能允許 Kubelet 偵測節點關機事件,在實際關機前正確終止 Pod 並釋放資源。

當節點關機但未被 Kubelet 的節點關機管理器偵測到時,就會變成非正常節點關機。非正常節點關機通常對於無狀態應用程式來說不是問題,但對於具狀態應用程式來說卻是個問題。如果 Pod 卡在已關機的節點上,且未在運作中的節點上重新啟動,則具狀態應用程式將無法正常運作。

在非正常節點關機的情況下,您可以手動在節點上新增 out-of-service 污點。

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

如果 Pod 上沒有相符的容忍度 (tolerations),則此污點會觸發強制刪除節點上的 Pod。連接到已關機節點的持久卷將被分離,並且新的 Pod 將在不同的運作中節點上成功建立。

注意: 在套用 out-of-service 污點之前,您必須驗證節點是否已處於關機或斷電狀態(而不是在重新啟動過程中)。

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

穩定版本的新功能

隨著非正常節點關機功能升級為穩定版本,功能閘道 NodeOutOfServiceVolumeDetachkube-controller-manager 上會鎖定為 true,且無法停用。

Pod GC Controller 中的指標 force_delete_pods_totalforce_delete_pod_errors_total 經過增強,可以計算所有強制 Pod 刪除。指標中新增了一個「原因」來說明 Pod 是否因已終止、成為孤立狀態、因 out-of-service 污點而終止,或終止且未排程而被強制刪除。

Attach Detach Controller 中的指標 attachdetach_controller_forced_detaches 也新增了一個「原因」,以說明強制分離是否由 out-of-service 污點或逾時所引起。

下一步?

此功能需要使用者手動將污點新增到節點,以觸發工作負載容錯移轉,並在節點恢復後移除污點。未來,我們計畫尋找自動偵測和隔離已關機/故障節點的方法,並自動將工作負載容錯移轉到另一個節點。

如何瞭解更多資訊?

請查看此功能的其他文件此處

如何參與?

我們非常感謝所有貢獻者,他們協助設計、實作和審查此功能,並協助其從 alpha、beta 發展到穩定版本

此功能是 SIG Storage 和 SIG Node 之間的協作成果。對於有興趣參與 Kubernetes Storage 系統任何部分之設計和開發的人員,請加入 Kubernetes Storage 特殊興趣小組 (SIG)。對於有興趣參與設計和開發支援 Pod 和主機資源之間受控互動的組件的人員,請加入 Kubernetes Node SIG。