節點關機

在 Kubernetes 叢集中，節點可以透過計劃性的優雅方式關停，也可能由於電源故障或其他外部原因而意外關停。如果在關停前未排空節點，節點關停可能導致工作負載故障。節點關停可以是優雅的或非優雅的。

優雅的節點關停

kubelet 嘗試檢測節點系統關停，並終止在該節點上執行的 Pod。

kubelet 確保 Pod 在節點關停期間遵循正常的Pod 終止過程。在節點關停期間，kubelet 不接受新的 Pod（即使這些 Pod 已經繫結到該節點）。

啟用優雅節點關停

• Linux
• Windows

配置優雅節點關停

請注意，預設情況下，以下兩個配置選項 shutdownGracePeriod 和 shutdownGracePeriodCriticalPods 都設定為零，因此不會啟用優雅節點關停功能。要啟用該特性，兩個選項都應適當配置並設定為非零值。

一旦 kubelet 收到節點關停通知，它會為 Node 設定一個 NotReady 狀況，其 reason 設定為 "node is shutting down"。kube-scheduler 遵循此狀況，不會將任何 Pod 排程到受影響的節點上；其他第三方排程器預計會遵循相同的邏輯。這意味著新的 Pod 將不會被排程到該節點上，因此也不會啟動。

如果檢測到正在進行的節點關停，kubelet 還會在 PodAdmission 階段拒絕 Pod，這樣即使是具有 容忍度 node.kubernetes.io/not-ready:NoSchedule 的 Pod 也不會在該節點上啟動。

當 kubelet 透過 API 在其 Node 上設定該狀況時，kubelet 也會開始終止所有在本地執行的 Pod。

在優雅關停期間，kubelet 分兩個階段終止 Pod

1. 終止節點上執行的常規 Pod。
2. 終止節點上執行的關鍵 Pod。

優雅節點關停特性透過兩個 KubeletConfiguration 選項進行配置

• shutdownGracePeriod:

  指定節點應延遲關停的總持續時間。這是常規 Pod 和關鍵 Pod 終止的總寬限期。

• shutdownGracePeriodCriticalPods:

  指定在節點關停期間用於終止關鍵 Pod 的持續時間。此值應小於 shutdownGracePeriod。

例如，如果 shutdownGracePeriod=30s，並且 shutdownGracePeriodCriticalPods=10s，kubelet 將延遲節點關停 30 秒。在關停期間，前 20（30-10）秒將用於優雅地終止普通 Pod，最後 10 秒將用於終止關鍵 Pod。

Reason:         Terminated
Message:        Pod was terminated in response to imminent node shutdown.

基於 Pod 優先順序的優雅節點關停

為了在優雅節點關停期間，為 Pod 的關停順序提供更大的靈活性，如果已在叢集中啟用此特性，優雅節點關停將遵循 Pod 的 PriorityClass。該特性允許叢集管理員根據優先順序類，在優雅節點關停期間明確定義 Pod 的順序。

如上所述，優雅節點關停特性分兩個階段關停 Pod，先是非關鍵 Pod，然後是關鍵 Pod。如果需要更大的靈活性，以更精細的方式明確定義關停期間的 Pod 順序，則可以使用基於 Pod 優先順序的優雅關停。

當優雅節點關停遵循 Pod 優先順序時，可以分多個階段進行優雅節點關停，每個階段關停特定優先順序類的 Pod。kubelet 可以配置每個階段的精確階段和關停時間。

假設叢集中存在以下自定義 Pod 優先順序類：

在 kubelet 配置中，shutdownGracePeriodByPodPriority 的設定可能如下所示

對應的 kubelet 配置 YAML 配置將是

shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60

上表意味著任何 priority 值 >= 100000 的 Pod 將獲得 10 秒的關停時間，任何值 >= 10000 且 < 100000 的 Pod 將獲得 180 秒的關停時間，任何值 >= 1000 且 < 10000 的 Pod 將獲得 120 秒的關停時間。最後，所有其他 Pod 將獲得 60 秒的關停時間。

無需指定所有類的對應值。例如，你可以改用以下設定

在上述情況下，具有 custom-class-b 的 Pod 將與 custom-class-c 一起進入相同的關停桶。

如果在特定範圍內沒有 Pod，則 kubelet 不會等待該優先順序範圍內的 Pod。相反，kubelet 會立即跳到下一個優先順序類值範圍。

如果此功能已啟用但未提供配置，則不會採取任何排序操作。

使用此功能需要啟用 GracefulNodeShutdownBasedOnPodPriority 特性門控，並在 kubelet 配置中將 ShutdownGracePeriodByPodPriority 設定為包含 Pod 優先順序類值及其各自關停週期的所需配置。

指標 graceful_shutdown_start_time_seconds 和 graceful_shutdown_end_time_seconds 在 kubelet 子系統中發出，用於監控節點關停。

非優雅節點關停處理

節點關停操作可能未被 kubelet 的節點關停管理器檢測到，原因可能是該命令未觸發 kubelet 使用的抑制鎖機制，或者由於使用者錯誤，即 ShutdownGracePeriod 和 ShutdownGracePeriodCriticalPods 未正確配置。請參閱上文的優雅節點關停部分了解更多詳情。

當節點關停但未被 kubelet 的節點關停管理器檢測到時，作為 StatefulSet 一部分的 Pod 將在關停節點上處於終止狀態，無法移動到新的執行節點。這是因為關停節點上的 kubelet 無法刪除 Pod，因此 StatefulSet 無法建立具有相同名稱的新 Pod。如果 Pod 使用了卷，則 VolumeAttachments 將不會從原始關停節點中刪除，因此這些 Pod 使用的卷無法附加到新的執行節點。結果是，在 StatefulSet 上執行的應用程式無法正常執行。如果原始關停節點啟動，Pod 將被 kubelet 刪除，並在不同的執行節點上建立新的 Pod。如果原始關停節點未啟動，這些 Pod 將永遠停留在關停節點上的終止狀態。

為了緩解上述情況，使用者可以手動向節點新增汙點 node.kubernetes.io/out-of-service，並帶有 NoExecute 或 NoSchedule 效果，將其標記為停止服務。如果節點被此汙點標記為停止服務，則如果 Pod 沒有匹配的容忍度，它們將被強制刪除，並且節點上正在終止的 Pod 的卷分離操作將立即發生。這使得停止服務節點上的 Pod 能夠在不同節點上快速恢復。

在非優雅關停期間，Pod 分兩個階段終止

1. 強制刪除沒有匹配 out-of-service 容忍度的 Pod。
2. 立即執行此類 Pod 的卷分離操作。

超時時強制儲存分離

在 Pod 刪除在 6 分鐘內未成功的情況下，如果節點當時不健康，Kubernetes 將強制分離正在解除安裝的卷。任何仍在節點上執行的，使用強制分離卷的工作負載將導致違反 CSI 規範，該規範指出 ControllerUnpublishVolume “必須在所有 NodeUnstageVolume 和 NodeUnpublishVolume 呼叫併成功後呼叫”。在這種情況下，相關節點上的卷可能會遇到資料損壞。

強制儲存分離行為是可選的；使用者可以選擇使用“非優雅節點關停”功能。

可以透過在 kube-controller-manager 中設定 disable-force-detach-on-timeout 配置欄位來停用超時時強制儲存分離。停用超時時強制分離功能意味著，在不健康狀態下超過 6 分鐘的節點上託管的卷，其關聯的 VolumeAttachment 將不會被刪除。

應用此設定後，仍然附加到卷的不健康 Pod 必須透過上述非優雅節點關停程式進行恢復。

下一步

瞭解更多資訊：

• 部落格：非優雅節點關停。
• 叢集架構：節點。