这篇文章已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不准确。

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 (排空) 节点，节点关机可能导致工作负载失败。节点关机可以是优雅的，也可以是非优雅的。

的优雅节点关机 (Graceful Node Shutdown) 功能允许 Kubelet 在实际关机前检测到节点关机事件，妥善终止 Pod 并释放资源。

当节点关机但未被 Kubelet 的节点关机管理器检测到时，这便成为非优雅节点关机。非优雅节点关机通常对无状态应用不是问题，但对于有状态应用来说是个问题。如果 Pod 卡在已关机的节点上而未能在运行中的节点上重启，有状态应用将无法正常运行。

在非优雅节点关机的情况下，您可以手动在 Node 上添加一个 out-of-service taint (污点)。

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

如果 Pod 没有匹配的 toleration (容忍度)，此 taint 会触发该节点上的 Pod 被强制删除。附加到已关机节点的持久卷将被分离，并且新的 Pod 将在另一个运行中的节点上成功创建。

注意：在应用 out-of-service taint 之前，您必须验证节点已处于关机或断电状态（而不是正在重启过程中）。

一旦所有与 out-of-service 节点关联的工作负载 Pod 都已迁移到新的运行节点上，并且已关机的节点已恢复，您应在该节点恢复后移除其上的该 taint。

Stable 版本有什么新特性

随着非优雅节点关机功能晋升到 Stable，NodeOutOfServiceVolumeDetach 特性门在 kube-controller-manager 上被锁定为 true，且无法禁用。

Pod GC Controller 中的指标 force_delete_pods_total 和 force_delete_pod_errors_total 已得到增强，以统计所有强制 Pod 删除。指标中添加了一个原因，指示 Pod 是否因已终止、孤立、因 out-of-service taint 而终止，或因正在终止且未调度而强制删除。

Attach Detach Controller 中的指标 attachdetach_controller_forced_detaches 也添加了一个“原因”，指示强制分离是由于 out-of-service taint 还是超时引起的。

下一步是什么？

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

如何了解更多？

查看此功能的更多文档 此处。

如何参与贡献？

我们向所有帮助设计、实现和评审此功能，并帮助其从 alpha、beta 推进到 stable 阶段的贡献者致以衷心感谢。

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