本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

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。