本文发表时间超过一年。较旧的文章可能包含过时的内容。请检查页面上的信息自发布以来是否已不正确。

Kubernetes 1.28：非优雅节点关闭功能进入 GA 阶段

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

Kubernetes 的非优雅节点关闭功能现在在 Kubernetes v1.28 中正式 GA。它在 Kubernetes v1.24 中作为 alpha 引入，并在 Kubernetes v1.26 中升级为 beta。此功能允许有状态的工作负载在原始节点意外关闭或最终处于无法恢复的状态（例如硬件故障或无响应的操作系统）时，在不同的节点上重新启动。

什么是非优雅节点关闭

在 Kubernetes 集群中，节点可以以计划的优雅方式关闭，也可以因为停电或其他外部原因而意外关闭。如果节点在关闭之前没有被排空，则节点关闭可能会导致工作负载失败。节点关闭可以是优雅的，也可以是非优雅的。

优雅节点关闭 功能允许 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 污点之前，您必须验证节点是否已处于关闭或断电状态（而不是处于重新启动过程中）。

一旦与 out-of-service 节点链接的所有工作负载 Pod 都移动到新的运行节点，并且关闭的节点已恢复，则应在节点恢复后删除受影响节点上的该污点。

稳定版中的新增功能

随着非优雅节点关闭功能升级到稳定版，功能门 NodeOutOfServiceVolumeDetach 在 kube-controller-manager 上被锁定为 true，并且无法禁用。

Pod GC 控制器中的指标 force_delete_pods_total 和 force_delete_pod_errors_total 得到增强，以考虑所有强制 Pod 删除。该指标添加了一个原因，以指示 Pod 是否是因为已终止、孤立、因 out-of-service 污点而终止或终止且未计划而被强制删除。

还向附加分离控制器中的指标 attachdetach_controller_forced_detaches 添加了一个“原因”，以指示强制分离是由 out-of-service 污点还是超时引起的。

下一步是什么？

此功能需要用户手动向节点添加污点以触发工作负载故障转移，并在节点恢复后删除污点。将来，我们计划找到自动检测和隔离已关闭/失败的节点并自动将工作负载故障转移到另一节点的方法。

如何了解更多信息？

请查看有关此功能的其他文档，此处。

如何参与？

我们非常感谢所有为该功能的设计、实现和审查做出贡献并帮助其从 alpha、beta 过渡到稳定版的所有贡献者

此功能是 SIG Storage 和 SIG Node 之间的合作。对于那些有兴趣参与 Kubernetes 存储系统任何部分的设计和开发的人，请加入 Kubernetes 存储特别兴趣小组 (SIG)。对于那些有兴趣参与支持 Pod 和主机资源之间受控交互的组件的设计和开发的人，请加入 Kubernetes Node SIG。