Kubernetes WG Node Lifecycle 章程解读统一节点排空Node Drain与节点生命周期管理的技术路线图【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community在 Kubernetes 生态中节点维护Node Maintenance长期面临各自为战的困境kubectl drain、cluster autoscaler、karpenter、kured 等工具各有一套排空drain逻辑而节点优雅关闭、PodDisruptionBudgetPDB、API 发起的驱逐Eviction等机制之间又缺乏统一协调。Kubernetes Node Lifecycle 工作组WG正是为解决这一系统性痛点而成立其章程wg-node-lifecycle/charter.md定义了该组的目标边界、落地交付物与治理机制。本文将围绕这份章程梳理 Kubernetes 节点生命周期面临的核心问题、工作组拟引入的统一 API 设计方向、涉及的 KEP 与生态项目以及通往 GA 的优先级路线帮助读者理解 Kubernetes 在节点维护、驱逐与优雅终止方面正在发生的架构演进。一、工作组定位为什么需要统一的节点生命周期方案章程开篇即点明了成立背景Kubernetes 生态在节点维护场景下面临挑战多个项目在独立解决同类问题。这种重复建设带来双重代价——各项目维护负担沉重且用户在不同工具之间迁移时行为不一致。工作组的使命是开发整个生态可以依赖的统一 API降低跨项目的维护负担并解决两类核心问题阻碍节点排空impede node drain的场景导致 Pod 被不当终止improper pod termination的场景。章程强调方案必须是开箱即用、易于配置的同时要无缝集成现有的 API 与行为并保持极简且可扩展minimalistic and extensible以支撑生态中的高级用例。在解决节点排空之前工作组认为必须先完整理解节点生命周期其范围覆盖节点的供应与退役provisioning/sunsetting、PodDisruptionBudgets、API 发起的驱逐、节点关机node shutdown。这些环节会进一步影响节点与 Pod 的自动扩缩容、调度/反调度、负载均衡以及集群内运行的应用。这正是章程将探索统一排空与维护方式作为首要目标的原因——它牵一发而动全身。二、范围内工作In Scope九大探索方向章程将工作组的探索范围细分为九个方向每一项都对应具体的 Kubernetes 机制缺口统一排空与维护 API探索通过引入新 API、扩展现有 API包括对 Node 对象的扩展或交互来统一节点的排空和维护方式Node API 状态增强分析节点生命周期、Node API 及可能的交互探索增强 Node API 以暴露额外的状态state/status从而让其他核心 Kubernetes 与社区 API 围绕节点生命周期管理实现收敛coalesce改进中断模型改进当前由 API 发起的 Eviction API 和 PDB 实现的中断模型提升应用工作负载的反调度、可用性与迁移能力并探索与其他驱逐机制的交互协调 Pod 终止协调围绕调度/反调度、抢占preemption、驱逐与就绪探针readiness probes的 Pod 终止问题优雅/非优雅节点关机改进 Graceful/Non-Graceful Node Shutdown并评估其对节点生命周期的影响感知维护的调度与扩缩容改进调度器与节点/Pod 自动扩缩容使其将正在进行的节点维护与新的中断模型/驱逐纳入考量包括按调度约束均衡 PodDaemonSet 与静态 Pod 生命周期考虑在节点维护期间改进 DaemonSet 与静态 Pod 的 Pod 生命周期云厂商接入点探索云厂商用例及其接入节点生命周期的方式使用户能在不同平台上使用同一套 API 或配置迁移存量用户将基于驱逐的 kubectl 式排空kubectl、cluster autoscaler、karpenter 等及其他场景的用户迁移到新的统一节点排空方案。此外章程还包含两个具有前瞻性的探索点终止原因追踪探索节点被终止/排空/销毁背后的可能场景以及如何针对每种场景进行跟踪与响应同时参考过往讨论与历史视角例如 tombstones 墓碑机制可调度性反馈机制探索确保节点可调度性如就绪状态与能力的反馈机制既适用于节点供应阶段也适用于节点生命周期的其余阶段。三、范围外工作Out of Scope明确边界章程明确排除了两类容易混淆的工作防止工作组越界云厂商特有逻辑目标不是实现各家云厂商的逻辑而是提供厂商可以使用、挂接hook into或扩展的高层 API基础设施供应与物理生命周期管理不负责基础设施的供应/销毁方案也不负责物理基础设施的生命周期管理解决方案。这一边界与章程提供跨厂商统一 API的定位一脉相承——WG 产出的是抽象层具体平台适配留给云厂商与第三方。四、利益相关方Stakeholders与用户故事章程列出了九个利益相关 SIG覆盖了节点生命周期的全部关键环节SIG Apps、SIG Autoscaling、SIG CLI、SIG Cloud Provider、SIG Cluster Lifecycle、SIG Network、SIG Node、SIG Scheduling、SIG Storage。在仓库的 sigs.yaml 中可看到同样的利益相关方列表以及工作组的三位负责人来自 Red Hat、Anthropic、NVIDIA和每周会议信息。利益相关方横跨多个 SIG面向广泛的最终用户、公有云与私有云厂商、Kubernetes 发行版厂商和云厂商终端用户。章程用一组用户故事生动刻画了各角色的诉求这些诉求正是 API 设计的原始需求输入角色诉求集群管理员通过简单接口发起节点排空/维护无需人工干预可通过 API 观察排空进度、发现阻塞排空的工作负载集群管理员排空完成后执行任意后续动作重置 GPU 驱动、重置 NIC、软件更新或关机集群管理员通过控制面 API 协调硬件加速器accelerator的维护与排空降低维护成本集群管理员所有卷从节点卸载完成后节点才被声明为完全排空最终用户在优雅移除/终止 Pod 时支持先扩容后缩容surge upscale的迁移策略并可监控被优雅移除的 Pod最终用户为蓝绿升级提供更多替代方案尤其含特殊硬件加速器的场景按需选择排空与升级的协调策略以提升成本效益云厂商借助 Kubernetes 安全地移除硬件降低机群常规维护的运营成本最终用户/管理员混合使用按需与 Spot 实例以降低云开销在实例因成本阈值被云厂商终止时保持集群稳定用户对宠物级或昂贵工作负载VM、带加速器的 ML长时间阻止终止或拥有可靠的迁移路径——仅靠terminationGracePeriodSeconds不够因为终止/迁移可能耗时数小时甚至数天用户应用在 Pod 终止前完成所有网络与存储操作关闭连接、从 endpoints 移除、落盘缓存写入、完成存储清理应用开发者就绪探针信号在某些场景下不足如节点关机时就绪状态无变化需要在类似场景下停止向应用转发流量其中从 endpoints 移除被中断的 Pod声明完全排空等诉求直接对应下文交付物中的端点移除 API 与卷卸载协调机制。五、交付物Deliverables六类 API 与参考实现章程明确工作组将协调需求收集、设计、实现与推进毕业graduation各阶段并协调既有 KEP 的毕业及新 API/场景的探索。计划探索的交付物包括节点排空/维护表达 API声明式表达节点排空与维护解决 Eviction API 与 PDB 问题的 API重构 API 发起的驱逐与中断模型优雅终止机制节点关机时优雅终止 Pod 的 API/机制DRA 设备反调度 API对使用 DRADynamic Resource Allocation设备的 Pod 进行反调度端点移除 API在 Pod 终止前将其从 endpoints 移除可调度性跟踪 API跟踪节点可调度性如就绪状态与能力。在实现层面工作组计划提供新 API 的参考实现包括但不限于控制器kube-controller-manager、API 校验、与现有核心组件的集成及面向生态的扩展点并配套E2E / 一致性Conformance测试——这是 Kubernetes 功能走向 GA 的必要条件也印证了章程对可落地、可验证的坚持。六、相关特性、KEP 与文档一张技术地图章程列出了与本工作组直接相关的关键 KEP 与设计文档构成了节点生命周期领域的技术地图。结合 wg-node-lifecycle/annual-report-2025.md 中的进展信息可整理如下相关特性/KEP主题备注依据章程与 2025 年报Declarative Node Maintenanceenhancements #4212声明式节点维护列为 GA 优先项2025 年报显示其已被范围更广的 Specialized Lifecycle Management#5683取代EvictionRequest APIenhancements #4563受管优雅 Pod 终止原称 Evacuation列为 GA 优先项2025 年报显示目标 Kubernetes 1.36Graceful Node Shutdownenhancements #2000优雅节点关机列为 GA 优先项DRA device taints and tolerationsenhancements #5055DRA 设备污点与容忍支撑 DRA 设备反调度 APIDisrupted Pods 从 endpoints 移除设计文档终止前移除端点对应端点移除 API交付物Node Readiness Gatesenhancements #5233节点就绪门控对应可调度性跟踪方向kubelet 触发 Pod 重调度设计文档kubelet 主动触发重调度探索 kubelet 在终止流程中的角色Implicit tolerationsenhancements #5282隐式容忍配合 scheduler-plugins 的 Filter 插件实现非 GPU Pod 不调度到 GPU 节点Node Resource Hot Plugenhancements #3953节点资源热插拔节点能力动态变化场景需要说明的是章程中的 KEP 链接指向 enhancements 仓库如 issues/4212、4563、2000、5055、5233、5282、3953本文按主题归纳引用这些 KEP 的最终状态以 Kubernetes enhancements 仓库的演进为准2025 年报也证实部分 KEP 正在被更广泛的新提案如 #5683迭代。七、生态中的相关项目问题图谱与协作坐标章程专门列出已知的在生态中解决类似问题、或可从本工作组工作中受益的项目这既是问题图谱也是潜在协作与迁移对象的清单节点终止处理aws-node-termination-handler、kuredkubereboot、drainoplanetlabs、strimzi/drain-cleaner、pod-graceful-drainforiequal0节点维护/生命周期算子medik8s/node-maintenance-operator、Mellanox/maintenance-operator、kubevirt/kubevirt、openshift/machine-config-operator自动扩缩容与调度kubernetes/autoscaler 中的 cluster-autoscaler、kubernetes-sigs/karpenter、jukie/karpenter-deprovision-controller集群生命周期与部署kubernetes-sigs/cluster-api、kubernetes-sigs/kubespray硬件加速器场景NVIDIA/pika此外章程还指出企业内部还存在大量自研定制方案。这些分散的解决方案正是统一 API 要收敛的对象——WG 的目标不是取代它们而是提供它们可以共同依赖的底层抽象正如章程所说让用户跨平台使用同一套 API 或配置。八、优先级与路线三个特性冲刺 GA章程明确给出了工作组的活动优先级——将以下三个特性推进到稳定状态GADeclarative Node Maintenance声明式节点维护后演化为范围更广的 Specialized Lifecycle ManagementEvictionRequest APIGraceful Node Shutdown在会议与日常评审/指导层面章程规定了四档优先级用于在议题拥挤时保证核心工作不被淹没与 WG 重点特性相关的紧急议题尤其是 KEP 与代码冻结期WG 范围内的议题讨论WG 范围内的演示presentationsWG 其他特性或范围内议题——若某议题被多次提出需防止其被饿死starvation。结合 wg-node-lifecycle/annual-report-2025.md 的进展工作组在 KubeCon NA Maintainer Summit 上介绍了 Pod Eviction 与 Node Maintenance 两大核心方向EvictionRequest API 目标 Kubernetes 1.36替代 Declarative Node Maintenance 的 Specialized Lifecycle ManagementKEP #5683目标 Kubernetes 1.37且在发布前已在多个利益相关 SIG 间进行了数周讨论以对齐需求与设计。九、治理与解散机制临时性协作的纪律与其他工作组的章程一致本章程遵循 Kubernetes 的治理惯例。章程引用两份治理文档committee-steering/governance/README.mdKubernetes Charter 约定——committee-steering/governance/wg-charter-template.md 提供了章程模板本文档即按此模板组织committee-steering/governance/wg-governance.md角色与组织管理——该文档定义了工作组的成立、汇报与解散流程。章程明确遵守并选择接收opt-inwg-governance 的更新与修改。工作组的性质是临时的根据 committee-steering/governance/wg-governance.md工作组不拥有代码、有可度量的明确目标、在达成目标后解散。本 WG 的解散条件为上述特性KEP与核心 API 达到 GA 稳定状态且在相关 SIG 内建立起持续维护的归属权ownership后解散若无法达成合适的 SIG 归属或不再需要额外协调将评估是否解散。十、参与方式与延伸阅读WG Node Lifecycle 通过每周会议、Slack 频道与邮件列表运作具体信息维护在 wg-node-lifecycle/README.md 与 sigs.yaml 中README 为自动化生成文件实际数据源为 sigs.yaml。工作组的所有权与评审通过 OWNERS 别名机制管理见 wg-node-lifecycle/OWNERS 与仓库根目录的 OWNERS_ALIASES。若希望深入了解可在本仓库中继续阅读以下材料wg-node-lifecycle/charter.md本文解析的对象完整章程原文wg-node-lifecycle/annual-report-2025.md2025 年度报告含 KEP 目标版本与进展committee-steering/governance/wg-governance.md工作组成立、汇报与解散流程committee-steering/governance/wg-charter-template.md章程模板便于理解本文档的结构来源sig-wg-lifecycle.mdSIG/WG 生命周期管理总览结语从这份章程可以看到Kubernetes 正在将节点排空/维护从各工具各自实现的临场方案收敛为由控制面 API 统一表达、由多个 SIG 协同演进的一等公民能力。围绕统一排空 API、EvictionRequest、优雅节点关机与节点状态增强WG Node Lifecycle 为集群管理员、应用开发者与云厂商勾勒了一条清晰的演进路径更少的手工干预、更可观察的排空进度、更安全的硬件维护以及更可靠的 Pod 终止语义。随着相关 KEP 陆续进入 1.36/1.37 及后续版本这份章程所定义的技术方向正在逐步落地为可用的 Kubernetes 原生能力。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes WG Node Lifecycle 章程解读：统一节点排空（Node Drain）与节点生命周期管理的技术路线图
Kubernetes WG Node Lifecycle 章程解读统一节点排空Node Drain与节点生命周期管理的技术路线图【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community在 Kubernetes 生态中节点维护Node Maintenance长期面临各自为战的困境kubectl drain、cluster autoscaler、karpenter、kured 等工具各有一套排空drain逻辑而节点优雅关闭、PodDisruptionBudgetPDB、API 发起的驱逐Eviction等机制之间又缺乏统一协调。Kubernetes Node Lifecycle 工作组WG正是为解决这一系统性痛点而成立其章程wg-node-lifecycle/charter.md定义了该组的目标边界、落地交付物与治理机制。本文将围绕这份章程梳理 Kubernetes 节点生命周期面临的核心问题、工作组拟引入的统一 API 设计方向、涉及的 KEP 与生态项目以及通往 GA 的优先级路线帮助读者理解 Kubernetes 在节点维护、驱逐与优雅终止方面正在发生的架构演进。一、工作组定位为什么需要统一的节点生命周期方案章程开篇即点明了成立背景Kubernetes 生态在节点维护场景下面临挑战多个项目在独立解决同类问题。这种重复建设带来双重代价——各项目维护负担沉重且用户在不同工具之间迁移时行为不一致。工作组的使命是开发整个生态可以依赖的统一 API降低跨项目的维护负担并解决两类核心问题阻碍节点排空impede node drain的场景导致 Pod 被不当终止improper pod termination的场景。章程强调方案必须是开箱即用、易于配置的同时要无缝集成现有的 API 与行为并保持极简且可扩展minimalistic and extensible以支撑生态中的高级用例。在解决节点排空之前工作组认为必须先完整理解节点生命周期其范围覆盖节点的供应与退役provisioning/sunsetting、PodDisruptionBudgets、API 发起的驱逐、节点关机node shutdown。这些环节会进一步影响节点与 Pod 的自动扩缩容、调度/反调度、负载均衡以及集群内运行的应用。这正是章程将探索统一排空与维护方式作为首要目标的原因——它牵一发而动全身。二、范围内工作In Scope九大探索方向章程将工作组的探索范围细分为九个方向每一项都对应具体的 Kubernetes 机制缺口统一排空与维护 API探索通过引入新 API、扩展现有 API包括对 Node 对象的扩展或交互来统一节点的排空和维护方式Node API 状态增强分析节点生命周期、Node API 及可能的交互探索增强 Node API 以暴露额外的状态state/status从而让其他核心 Kubernetes 与社区 API 围绕节点生命周期管理实现收敛coalesce改进中断模型改进当前由 API 发起的 Eviction API 和 PDB 实现的中断模型提升应用工作负载的反调度、可用性与迁移能力并探索与其他驱逐机制的交互协调 Pod 终止协调围绕调度/反调度、抢占preemption、驱逐与就绪探针readiness probes的 Pod 终止问题优雅/非优雅节点关机改进 Graceful/Non-Graceful Node Shutdown并评估其对节点生命周期的影响感知维护的调度与扩缩容改进调度器与节点/Pod 自动扩缩容使其将正在进行的节点维护与新的中断模型/驱逐纳入考量包括按调度约束均衡 PodDaemonSet 与静态 Pod 生命周期考虑在节点维护期间改进 DaemonSet 与静态 Pod 的 Pod 生命周期云厂商接入点探索云厂商用例及其接入节点生命周期的方式使用户能在不同平台上使用同一套 API 或配置迁移存量用户将基于驱逐的 kubectl 式排空kubectl、cluster autoscaler、karpenter 等及其他场景的用户迁移到新的统一节点排空方案。此外章程还包含两个具有前瞻性的探索点终止原因追踪探索节点被终止/排空/销毁背后的可能场景以及如何针对每种场景进行跟踪与响应同时参考过往讨论与历史视角例如 tombstones 墓碑机制可调度性反馈机制探索确保节点可调度性如就绪状态与能力的反馈机制既适用于节点供应阶段也适用于节点生命周期的其余阶段。三、范围外工作Out of Scope明确边界章程明确排除了两类容易混淆的工作防止工作组越界云厂商特有逻辑目标不是实现各家云厂商的逻辑而是提供厂商可以使用、挂接hook into或扩展的高层 API基础设施供应与物理生命周期管理不负责基础设施的供应/销毁方案也不负责物理基础设施的生命周期管理解决方案。这一边界与章程提供跨厂商统一 API的定位一脉相承——WG 产出的是抽象层具体平台适配留给云厂商与第三方。四、利益相关方Stakeholders与用户故事章程列出了九个利益相关 SIG覆盖了节点生命周期的全部关键环节SIG Apps、SIG Autoscaling、SIG CLI、SIG Cloud Provider、SIG Cluster Lifecycle、SIG Network、SIG Node、SIG Scheduling、SIG Storage。在仓库的 sigs.yaml 中可看到同样的利益相关方列表以及工作组的三位负责人来自 Red Hat、Anthropic、NVIDIA和每周会议信息。利益相关方横跨多个 SIG面向广泛的最终用户、公有云与私有云厂商、Kubernetes 发行版厂商和云厂商终端用户。章程用一组用户故事生动刻画了各角色的诉求这些诉求正是 API 设计的原始需求输入角色诉求集群管理员通过简单接口发起节点排空/维护无需人工干预可通过 API 观察排空进度、发现阻塞排空的工作负载集群管理员排空完成后执行任意后续动作重置 GPU 驱动、重置 NIC、软件更新或关机集群管理员通过控制面 API 协调硬件加速器accelerator的维护与排空降低维护成本集群管理员所有卷从节点卸载完成后节点才被声明为完全排空最终用户在优雅移除/终止 Pod 时支持先扩容后缩容surge upscale的迁移策略并可监控被优雅移除的 Pod最终用户为蓝绿升级提供更多替代方案尤其含特殊硬件加速器的场景按需选择排空与升级的协调策略以提升成本效益云厂商借助 Kubernetes 安全地移除硬件降低机群常规维护的运营成本最终用户/管理员混合使用按需与 Spot 实例以降低云开销在实例因成本阈值被云厂商终止时保持集群稳定用户对宠物级或昂贵工作负载VM、带加速器的 ML长时间阻止终止或拥有可靠的迁移路径——仅靠terminationGracePeriodSeconds不够因为终止/迁移可能耗时数小时甚至数天用户应用在 Pod 终止前完成所有网络与存储操作关闭连接、从 endpoints 移除、落盘缓存写入、完成存储清理应用开发者就绪探针信号在某些场景下不足如节点关机时就绪状态无变化需要在类似场景下停止向应用转发流量其中从 endpoints 移除被中断的 Pod声明完全排空等诉求直接对应下文交付物中的端点移除 API 与卷卸载协调机制。五、交付物Deliverables六类 API 与参考实现章程明确工作组将协调需求收集、设计、实现与推进毕业graduation各阶段并协调既有 KEP 的毕业及新 API/场景的探索。计划探索的交付物包括节点排空/维护表达 API声明式表达节点排空与维护解决 Eviction API 与 PDB 问题的 API重构 API 发起的驱逐与中断模型优雅终止机制节点关机时优雅终止 Pod 的 API/机制DRA 设备反调度 API对使用 DRADynamic Resource Allocation设备的 Pod 进行反调度端点移除 API在 Pod 终止前将其从 endpoints 移除可调度性跟踪 API跟踪节点可调度性如就绪状态与能力。在实现层面工作组计划提供新 API 的参考实现包括但不限于控制器kube-controller-manager、API 校验、与现有核心组件的集成及面向生态的扩展点并配套E2E / 一致性Conformance测试——这是 Kubernetes 功能走向 GA 的必要条件也印证了章程对可落地、可验证的坚持。六、相关特性、KEP 与文档一张技术地图章程列出了与本工作组直接相关的关键 KEP 与设计文档构成了节点生命周期领域的技术地图。结合 wg-node-lifecycle/annual-report-2025.md 中的进展信息可整理如下相关特性/KEP主题备注依据章程与 2025 年报Declarative Node Maintenanceenhancements #4212声明式节点维护列为 GA 优先项2025 年报显示其已被范围更广的 Specialized Lifecycle Management#5683取代EvictionRequest APIenhancements #4563受管优雅 Pod 终止原称 Evacuation列为 GA 优先项2025 年报显示目标 Kubernetes 1.36Graceful Node Shutdownenhancements #2000优雅节点关机列为 GA 优先项DRA device taints and tolerationsenhancements #5055DRA 设备污点与容忍支撑 DRA 设备反调度 APIDisrupted Pods 从 endpoints 移除设计文档终止前移除端点对应端点移除 API交付物Node Readiness Gatesenhancements #5233节点就绪门控对应可调度性跟踪方向kubelet 触发 Pod 重调度设计文档kubelet 主动触发重调度探索 kubelet 在终止流程中的角色Implicit tolerationsenhancements #5282隐式容忍配合 scheduler-plugins 的 Filter 插件实现非 GPU Pod 不调度到 GPU 节点Node Resource Hot Plugenhancements #3953节点资源热插拔节点能力动态变化场景需要说明的是章程中的 KEP 链接指向 enhancements 仓库如 issues/4212、4563、2000、5055、5233、5282、3953本文按主题归纳引用这些 KEP 的最终状态以 Kubernetes enhancements 仓库的演进为准2025 年报也证实部分 KEP 正在被更广泛的新提案如 #5683迭代。七、生态中的相关项目问题图谱与协作坐标章程专门列出已知的在生态中解决类似问题、或可从本工作组工作中受益的项目这既是问题图谱也是潜在协作与迁移对象的清单节点终止处理aws-node-termination-handler、kuredkubereboot、drainoplanetlabs、strimzi/drain-cleaner、pod-graceful-drainforiequal0节点维护/生命周期算子medik8s/node-maintenance-operator、Mellanox/maintenance-operator、kubevirt/kubevirt、openshift/machine-config-operator自动扩缩容与调度kubernetes/autoscaler 中的 cluster-autoscaler、kubernetes-sigs/karpenter、jukie/karpenter-deprovision-controller集群生命周期与部署kubernetes-sigs/cluster-api、kubernetes-sigs/kubespray硬件加速器场景NVIDIA/pika此外章程还指出企业内部还存在大量自研定制方案。这些分散的解决方案正是统一 API 要收敛的对象——WG 的目标不是取代它们而是提供它们可以共同依赖的底层抽象正如章程所说让用户跨平台使用同一套 API 或配置。八、优先级与路线三个特性冲刺 GA章程明确给出了工作组的活动优先级——将以下三个特性推进到稳定状态GADeclarative Node Maintenance声明式节点维护后演化为范围更广的 Specialized Lifecycle ManagementEvictionRequest APIGraceful Node Shutdown在会议与日常评审/指导层面章程规定了四档优先级用于在议题拥挤时保证核心工作不被淹没与 WG 重点特性相关的紧急议题尤其是 KEP 与代码冻结期WG 范围内的议题讨论WG 范围内的演示presentationsWG 其他特性或范围内议题——若某议题被多次提出需防止其被饿死starvation。结合 wg-node-lifecycle/annual-report-2025.md 的进展工作组在 KubeCon NA Maintainer Summit 上介绍了 Pod Eviction 与 Node Maintenance 两大核心方向EvictionRequest API 目标 Kubernetes 1.36替代 Declarative Node Maintenance 的 Specialized Lifecycle ManagementKEP #5683目标 Kubernetes 1.37且在发布前已在多个利益相关 SIG 间进行了数周讨论以对齐需求与设计。九、治理与解散机制临时性协作的纪律与其他工作组的章程一致本章程遵循 Kubernetes 的治理惯例。章程引用两份治理文档committee-steering/governance/README.mdKubernetes Charter 约定——committee-steering/governance/wg-charter-template.md 提供了章程模板本文档即按此模板组织committee-steering/governance/wg-governance.md角色与组织管理——该文档定义了工作组的成立、汇报与解散流程。章程明确遵守并选择接收opt-inwg-governance 的更新与修改。工作组的性质是临时的根据 committee-steering/governance/wg-governance.md工作组不拥有代码、有可度量的明确目标、在达成目标后解散。本 WG 的解散条件为上述特性KEP与核心 API 达到 GA 稳定状态且在相关 SIG 内建立起持续维护的归属权ownership后解散若无法达成合适的 SIG 归属或不再需要额外协调将评估是否解散。十、参与方式与延伸阅读WG Node Lifecycle 通过每周会议、Slack 频道与邮件列表运作具体信息维护在 wg-node-lifecycle/README.md 与 sigs.yaml 中README 为自动化生成文件实际数据源为 sigs.yaml。工作组的所有权与评审通过 OWNERS 别名机制管理见 wg-node-lifecycle/OWNERS 与仓库根目录的 OWNERS_ALIASES。若希望深入了解可在本仓库中继续阅读以下材料wg-node-lifecycle/charter.md本文解析的对象完整章程原文wg-node-lifecycle/annual-report-2025.md2025 年度报告含 KEP 目标版本与进展committee-steering/governance/wg-governance.md工作组成立、汇报与解散流程committee-steering/governance/wg-charter-template.md章程模板便于理解本文档的结构来源sig-wg-lifecycle.mdSIG/WG 生命周期管理总览结语从这份章程可以看到Kubernetes 正在将节点排空/维护从各工具各自实现的临场方案收敛为由控制面 API 统一表达、由多个 SIG 协同演进的一等公民能力。围绕统一排空 API、EvictionRequest、优雅节点关机与节点状态增强WG Node Lifecycle 为集群管理员、应用开发者与云厂商勾勒了一条清晰的演进路径更少的手工干预、更可观察的排空进度、更安全的硬件维护以及更可靠的 Pod 终止语义。随着相关 KEP 陆续进入 1.36/1.37 及后续版本这份章程所定义的技术方向正在逐步落地为可用的 Kubernetes 原生能力。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考