Kubernetes 1.28: 节点非体面关闭进入 GA 阶段（正式发布）

作者： Xing Yang (VMware) 和 Ashutosh Kumar (Elastic)

译者： Xin Li (Daocloud)

Kubernetes 节点非体面关闭特性现已在 Kubernetes v1.28 中正式发布。

此特性在 Kubernetes v1.24 中作为 Alpha 特性引入，并在 Kubernetes v1.26 中转入 Beta 阶段。如果原始节点意外关闭或最终处于不可恢复状态（例如硬件故障或操作系统无响应）， 此特性允许有状态工作负载在不同节点上重新启动。

什么是节点非体面关闭

在 Kubernetes 集群中，节点可能会按计划正常关闭，也可能由于断电或其他外部原因而意外关闭。 如果节点在关闭之前未腾空，则节点关闭可能会导致工作负载失败。节点关闭可以是正常关闭，也可以是非正常关闭。

节点体面关闭特性允许 kubelet 在实际关闭之前检测节点关闭事件、正确终止该节点上的 Pod 并释放资源。

当节点关闭但 kubelet 的节点关闭管理器未检测到时，将造成节点非体面关闭。 对于无状态应用程序来说，节点非体面关闭通常不是问题，但是对于有状态应用程序来说，这是一个问题。 如果 Pod 停留在关闭节点上并且未在正在运行的节点上重新启动，则有状态应用程序将无法正常运行。

在节点非体面关闭的情况下，你可以在 Node 上手动添加 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 的强制删除情况。 指标中会添加一个 "reason"，以指示 Pod 是否因终止、孤儿、因 out-of-service 污点而终止或因未计划终止而被强制删除。

Attach Detach Controller 中的指标 attachdetach_controller_forced_detaches 中还会添加一个 "reason"，以指示强制解除挂接是由 out-of-service 污点还是超时引起的。

接下来

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

如何了解更多？

在此处可以查看有关此特性的其他文档。

我们非常感谢所有帮助设计、实现和审查此功能并帮助其从 Alpha、Beta 到稳定版的贡献者：

<! This feature is a collaboration between SIG Storage and SIG Node. For those interested in getting involved with the design and development of any part of the Kubernetes Storage system, join the Kubernetes Storage Special Interest Group (SIG). For those interested in getting involved with the design and development of the components that support the controlled interactions between pods and host resources, join the Kubernetes Node SIG. --> 此特性是 SIG Storage 和 SIG Node 之间的协作。对于那些有兴趣参与 Kubernetes 存储系统任何部分的设计和开发的人，请加入 Kubernetes 存储特别兴趣小组（SIG）。 对于那些有兴趣参与支持 Pod 和主机资源之间受控交互的组件的设计和开发，请加入 Kubernetes Node SIG。