Kubernetes 1.24：非正常節點關閉 Alpha 簡介

Kubernetes v1.24 引入了 非正常節點關閉 的 Alpha 支援。此功能允許具狀態工作負載在原始節點關閉或處於無法復原的狀態（例如硬體故障或作業系統損壞）後容錯移轉至不同的節點。

這與正常節點關閉有何不同

您可能聽說過 Kubernetes 的 正常節點關閉 功能，並想知道非正常節點關閉功能與其有何不同。正常節點關閉允許 Kubernetes 偵測節點何時正常關閉，並適當處理該情況。節點關閉只有在 kubelet 能夠在實際關閉之前偵測到節點關閉動作時，才能是「正常」的。但是，在某些情況下，kubelet 可能無法偵測到節點關閉動作。這可能是因為關閉命令未觸發 kubelet 依賴的 systemd inhibitor locks 機制，或因為組態錯誤（ShutdownGracePeriod 和 ShutdownGracePeriodCriticalPods 未正確設定）。

正常節點關閉依賴於 Linux 特定的支援。kubelet 不會監看 Windows 節點上即將發生的關閉（這可能會在未來的 Kubernetes 版本中改變）。

當節點關閉但 kubelet 未偵測到時，該節點上的 Pod 也會非正常關閉。對於無狀態應用程式來說，這通常不是問題（一旦叢集偵測到受影響的節點或 Pod 發生故障，ReplicaSet 就會新增一個新的 Pod）。對於具狀態應用程式來說，情況更複雜。如果您使用 StatefulSet 並且在發生非正常故障的節點上有來自該 StatefulSet 的 Pod，則受影響的 Pod 將被標記為終止中；StatefulSet 無法建立替換 Pod，因為該 Pod 仍然存在於叢集中。因此，在 StatefulSet 上執行的應用程式可能會降級甚至離線。如果原始關閉的節點再次啟動，則原始節點上的 kubelet 會回報，刪除現有的 Pod，並且控制平面會在不同的執行節點上為該 StatefulSet 建立替換 Pod。如果原始節點發生故障並且沒有啟動，則這些具狀態 Pod 將無限期地停留在故障節點上的終止狀態。

$ kubectl get pod -o wide
NAME    READY   STATUS        RESTARTS   AGE   IP           NODE                      NOMINATED NODE   READINESS GATES
web-0   1/1     Running       0          100m   10.244.2.4   k8s-node-876-1639279816   <none>           <none>
web-1   1/1     Terminating   0          100m   10.244.1.3   k8s-node-433-1639279804   <none>           <none>

試用新的非正常關閉處理

若要使用非正常節點關閉處理，您必須為 kube-controller-manager 组件啟用 NodeOutOfServiceVolumeDetach 功能閘道。

在節點關閉的情況下，您可以手動將該節點標記為停止服務。您應在新增該污點之前，確認節點確實已關閉（而非處於重新啟動的中間）。您可以在 kubelet 未偵測到並提前處理的關閉後新增該污點；您可以使用該污點的另一種情況是，當節點由於硬體故障或作業系統損壞而處於無法復原的狀態時。您為該污點設定的值可以是 node.kubernetes.io/out-of-service=nodeshutdown: "NoExecute" 或 node.kubernetes.io/out-of-service=nodeshutdown:" NoSchedule"。前提是您已啟用先前提及的功能閘道，在節點上設定停止服務污點意味著節點上的 Pod 將被刪除，除非 Pod 上有相符的容忍度。連接到關閉節點的永久磁碟區將被卸離，並且對於 StatefulSet，替換 Pod 將在不同的執行節點上成功建立。

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

$ kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE    IP           NODE                      NOMINATED NODE   READINESS GATES
web-0   1/1     Running   0          150m   10.244.2.4   k8s-node-876-1639279816   <none>           <none>
web-1   1/1     Running   0          10m    10.244.1.7   k8s-node-433-1639279804   <none>           <none>

注意：在套用停止服務污點之前，您必須驗證節點是否已處於關閉或斷電狀態（而非處於重新啟動的中間），無論是因為使用者有意關閉它，還是因為節點因硬體故障、作業系統問題等而關閉。

一旦所有連結到停止服務節點的工作負載 Pod 都已移至新的執行節點，並且關閉的節點已復原，您應在節點復原後移除受影響節點上的該污點。如果您知道節點不會恢復服務，則可以改為從叢集中刪除該節點。

下一步是什麼？

根據回饋和採用情況，Kubernetes 團隊計劃在 1.25 或 1.26 版本中將非正常節點關閉實作推進到 Beta 階段。

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

如何瞭解更多資訊？

查看關於非正常節點關閉的文件。

如何參與？

此功能有一個漫長的故事。Yassine Tijani (yastij) 在兩年多前啟動了 KEP。Xing Yang (xing-yang) 繼續推動這項工作。SIG Storage、SIG Node 和 API 審閱者之間進行了許多討論，以確定設計細節。Ashutosh Kumar (sonasingh46) 完成了大部分實作，並在 Kubernetes 1.24 中將其引入 Alpha 階段。

我們要感謝以下人員提供的精闢見解：Tim Hockin (thockin) 對設計的指導，Jing Xu (jingxu97)、Hemant Kumar (gnufied) 和 Michelle Au (msau42) 從 SIG Storage 方面進行的審閱，以及 Mrunal Patel (mrunalp)、David Porter (bobbypage)、Derek Carr (derekwaynecarr) 和 Danielle Endocrimes (endocrimes) 從 SIG Node 方面進行的審閱。

有許多人協助審閱了設計和實作過程。我們要感謝所有為此努力做出貢獻的人，包括過去幾年審閱 KEP 和實作的約 30 人。

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

• ←上一篇
下一篇→