SIG Apps 聚焦：Kubernetes 工作负载管理的演进

随着 Kubernetes 的普及，讨论的焦点已从运行容器转向管理日益复杂的应用生命周期。现代平台需要支撑无状态 Web 服务、有状态数据库、批处理、AI 工作负载以及平台服务，同时还必须在升级、扩缩容和基础设施故障期间保持可靠。

每个 Kubernetes 用户都在依赖 SIG Apps，无论他们是否意识到这一点。Deployment、StatefulSet、DaemonSet、Job 和 CronJob 构成了整个 Kubernetes 生态中应用部署、更新、扩缩容和运维的基础。

SIG Apps 致力于提升工作负载的韧性、改进应用生命周期管理，并解决应用在遇到节点故障、发布中断以及日益复杂的基础设施环境时出现的运维难题。

本期聚焦，我们与 SIG Apps 三位主席中的两位——Janet Kuo 和 Maciej Szulik——坐下来聊了聊 Kubernetes 工作负载管理的演进、在应用可靠性与运维简洁性之间取舍的挑战，以及这个 Kubernetes 最具影响力的特别兴趣小组之一中应用生命周期管理的未来。

认识 SIG Apps

Janet Kuo：我是 Google 的高级主任软件工程师，从 2015 年起担任 Kubernetes maintainer，加入社区时我们正全力冲刺 1.0 发布。早期我的工作重点是构建核心 Workloads API，具体来说就是开发 Deployment、ReplicaSet、StatefulSet、DaemonSet 这些控制器，定义它们的发布行为，并推动它们从最初的设计走向 GA。正是这些实际动手的工作让我进入了 SIG Apps。

此后，我在 Kubernetes 的技术和社区两方面都保持着深度参与。自 2019 年起，我一直担任 SIG Apps 的 Co-Chair 和 Tech Lead。目前除了维护 workloads API，我还在推动 Agent Sandbox 等新的子项目，确保 Kubernetes 能够支撑下一代的 agentic 和 AI 工作负载。

Maciej Szulik：我从 2014 年就开始为 Kubernetes 做贡献了。此后，我在项目的多个领域工作过：controller、kubectl 和 apimachinery，最终成为 SIG Apps 的 Chair 兼 Tech Lead 之一。我目前的工作重点，一是 SIG Apps 旗下 workload controller 的可靠性，二是 kubectl 的稳定性和易用性——这是我作为 SIG CLI Tech Lead 的职责。此外，作为 Steering Committee 的一员，我也关心整个社区的健康与成长。Kubernetes 之外，我在 Defense Unicorns 担任 Staff Platform Engineer，通过一个叫 zarf 的项目，帮助 Kubernetes 更好地支持 airgap 环境。

问题与解法

SIG Apps 负责核心的 workload API，应用在 Kubernetes 上如何运行，靠的就是这些 API。从 Deployment、StatefulSet 到 Job、CronJob，这些 controller 决定了 workload 如何创建、更新、扩缩容，以及出问题时如何恢复。

随着 Kubernetes 支持的 workload 类型越来越多样——包括 AI、批处理和大型分布式应用——SIG Apps 也在持续演进这些 API，同时兼顾可靠性、向后兼容和运维上的简洁。

NF：可能有读者不太熟悉，SIG Apps 是什么？它在整个 Kubernetes 生态中扮演什么角色？

MS：SIG Apps 是 Kubernetes 中负责 workload API 的 Special Interest Group。CronJob 和 Job 用于运行批处理 workload，DaemonSet、Deployment、ReplicaSet 和 StatefulSet 则服务于大多数其他应用。更宽泛地说，SIG Apps 掌管的是大多数开发者日常真正接触到的那一层：把 workload 规格变成正在运行、能自愈的 pod 的 controller。Deployment 如何滚动发布、Job 如何重试、DaemonSet 如何做到每个节点放一个 pod，都是这个组决定的。

JK：补充一下 Maciej 说的。随着行业变化，运行复杂、非传统 workload 的需求正在暴涨，比如分布式 AI 训练、批计算和动态 agent 环境。我们的角色也在扩展：不只是维护经典的 workload API，还在主动演进它，并建立新的模式（比如 Agent Sandbox），确保 Kubernetes 仍然是下一代 workload（比如 AI）的最佳平台。

NF：在 SIG Apps 负责的工作负载 API（Deployment、StatefulSet、DaemonSet、Job 和 CronJob）中，哪些领域最受维护者和贡献者关注？

MS：长期以来，我们的重心是让批处理工作负载在 Kubernetes 上顺畅运行，如今我们已将注意力转向确保服务类工作负载（DaemonSet、StatefulSet 等）不被落下。这意味着要改进滚动发布和扩缩容行为的性能与大规模表现，同时清理用户反馈问题的积压，优先处理用户群体呼声最高的那些。

当前的重点方向

随着 Kubernetes 工作负载的规模和复杂度不断增长，工作负载控制器面临的挑战也在变化。我们请教了 SIG Apps 的几位主席：贡献者今天的精力集中在哪些地方，他们认为哪些韧性问题优先级最高。

NF：在你们看来，SIG Apps 当前试图解决的最重要的工作负载韧性问题是什么？

MS：节点生命周期方面的挑战在 SIG Apps、SIG Node 和 SIG Autoscaling 的讨论中反复出现。DaemonSet 和 Job 只是痛点最明显的地方，因为它们与节点状态的绑定最直接。与其在单个 SIG 内部零敲碎打地解决，我们决定专门成立一个 Node Lifecycle 工作组来认真推进这件事，希望能拿出长期方案，而不是一个个临时补丁。

JK：从 AI 的角度看，韧性至关重要。当你运行一个横跨数百块 GPU 的大规模分布式 LLM 训练任务时，单个节点故障就可能让整条流水线停摆。同样，如果负责日志或 GPU 监控的 DaemonSet 卡在某个坏节点上，整个集群的健康都会受影响。

除了 Node Lifecycle 工作组在基础设施层面的降级处理之外，SIG Apps 也在编排层通过 JobSet（面向分布式训练）和 LeaderWorkerSet（LWS，面向分片式 LLM 推理）等子项目来应对这一问题。这些 API 引入了“全有或全无”的故障处理模式：单个 Pod 或 Job 失败会触发整个组的协同重启，从最近一次干净的 checkpoint 恢复，而不是让卡住的工作负载悬在不一致的状态里。

实际影响

SIG Apps 内部开展的工作远不止控制器实现和 API 设计。我们想弄清楚，对于在生产环境中运维 Kubernetes 集群的平台团队来说，这些改进在实践中究竟意味着什么。

NF：对于在生产环境中运维 Kubernetes 的平台团队，如果目前讨论中的节点生命周期与工作负载韧性相关工作能够顺利落地，他们会感受到哪些实际改进？

MS：我大多是从旁观者的角度来看这件事，真正在 Node Lifecycle Working Group 里的人会给你更准确的回答。但就我看到的而言，我希望他们的工作能减少那种凌晨三点的告警——结果发现只是“某个 DaemonSet 滚动更新卡住了，因为节点 X 不稳定，得有人手动 cordon/delete/restart 才能解开”。

JK：同意 Maciej 说的，除了减少人工干预，平台团队还会看到资源可预测性和成本效率明显改善。比如在 GPU 空闲时间极其昂贵的 AI 工作负载中，让 Kubernetes 自动检测到劣化节点，并在任务崩溃前重新调度训练协调器或 agent，意味着更少的算力浪费和更稳定的任务执行。

挑战与取舍

要演进数百万工作负载所依赖的 API，需要谨慎的工程实现，更需要谨慎的决策。我们问了 SIG Apps 的几位主席，在改动 Kubernetes 核心工作负载控制器时，他们会权衡哪些技术和运维上的取舍。

NF：在演进核心工作负载控制器时，SIG Apps 遇到的最棘手的技术或运维取舍有哪些？

MS：说实话，有几个矛盾反复出现：控制器该多激进地放弃卡住的 Pod，以及它到底需要哪些信号才能做出正确判断。与此同时，我们始终要考虑向后兼容。Deployment、DaemonSet 和 Job 的行为已经被依赖了十年[被 Kubernetes 用户、工具链、自动化和更高层控制器]，所以哪怕一个改动明显“更正确”，也可能在无意中破坏人们围绕旧行为搭建的自动化。

JK：我们最难的取舍之一，就是克制住那种为了让设计“优雅”而破坏向后兼容的冲动。我们得改为设计可选启用的功能，让用户自己决定是否采用新行为，而不是强加给遗留工作负载。当需要支持全新的范式时，我们更倾向于先以 CRD 的形式引入，而不是把核心 API 撑得臃肿，Agent Sandbox、JobSet 和 LWS 就是这么做的。

展望未来

SIG Apps 的工作很大一部分是维护现有工作负载 API 的稳定性，但该小组也在通过新的增强提案塑造 Kubernetes 的未来。最后我们问了一个最近重新活跃起来的提案，以及它对工作负载管理未来意味着什么。

NF：SIG 最近讨论了重启 KEP-4443，目标版本是 Kubernetes 1.38。这个提案想解决哪些机会或挑战？为什么现在是重新审视它的合适时机？

KEP-4443 针对的是 Job API 中一个不大但真实存在的缺口：PodFailurePolicy 可以配置为给 JobFailed 条件添加一个条件原因，但针对不同容器退出码的不同 Pod 失败策略规则，产生的都是同一个通用原因。提案很简单：给每个 PodFailurePolicyRule 加一个可选的 Name 字段，追加到 JobFailed 条件的原因后面，这样 JobSet 这类上层工具终于可以根据触发失败的具体规则做出不同反应。

至于时机，答案和开源世界里一贯的答案一样简单：推动这件事的原贡献者离开了。现在有新人愿意接手，所以我们把目标定在了下一个版本。

参与其中

NF：如果有人想为 SIG Apps 做贡献，你会建议他们从哪里开始，尤其是那些还不是 Kubernetes 维护者的人？

MS：最好的起点是 #sig-apps Slack 频道和我们定期的 SIG Apps 会议。我们都是从这里开始的。如果觉得有点吓人，或者没人马上回复，那完全正常。大家都很忙，这不是针对你。

JK：除了 Maciej 的回答之外，我建议看看我们较新的子项目和倡议。给 Deployment 或 StatefulSet 这类稳定 API 做贡献可能会让人望而却步，因为向后兼容的要求把改动门槛抬得很高，容易上手的机会也少得多。

如果你是社区新人，Agent Sandbox 这类项目是极好的切入点。它们正在快速演进，维护者团队友好，而且有大量全新开发的空间，你能很快做出有分量的贡献。

总结

从项目最早的日子起，SIG Apps 就塑造了 Kubernetes 应用的部署和运维方式。用户日常使用 Deployment、StatefulSet、Job 和 DaemonSet 时，往往不会去想背后的控制器，但 SIG Apps 的工作持续影响着整个 Kubernetes 生态中工作负载的可靠性与可扩展性。

从提升工作负载韧性、改进节点生命周期行为，到为 AI 和分布式计算开辟新的模式，这个 SIG 在推动 Kubernetes 演进的同时，始终坚守项目的一条核心原则：维护用户所依赖的稳定性和向后兼容。无论你关注的是核心工作负载 API、Agent Sandbox 这样的新兴项目，还是想帮助改善各地 Kubernetes 用户的运维体验，SIG Apps 都有很多参与的机会。