随着 Kubernetes（容器编排平台） 采用率的增长，讨论已从运行容器转向管理日益复杂的应用生命周期。现代平台支持无状态 Web 服务、有状态数据库、批处理、AI 工作负载和平台服务。与此同时，它们必须在升级、扩缩容事件和基础设施故障期间保持可靠。

每个 Kubernetes 用户都依赖 SIG Apps，无论他们是否意识到这一点。Deployments、StatefulSets、DaemonSets、Jobs 和 CronJobs 构成了应用在 Kubernetes 生态系统中部署、更新、扩缩容和运维方式的基础。

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

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

SIG Apps 简介

Natalie Fisher：您能介绍一下自己、您的角色，以及您是如何参与 SIG Apps 的吗？

Janet Kuo：我是 Google 的高级主任软件工程师，自 2015 年起担任 Kubernetes 维护者，当时正值我们冲刺 1.0 发布之际加入社区。在早期，我的重点是构建核心 Workloads API（应用程序编程接口），特别是开发 Deployment、ReplicaSet、StatefulSet 和 DaemonSet 等控制器，定义它们的发布行为，并将它们从初始设计推进到 GA。这些实际工作是我进入 SIG Apps 的起点。

从那时起，我一直深入参与 Kubernetes 的技术和社区两方面工作。自 2019 年以来，我一直作为联合主席和技术负责人领导 SIG Apps。目前，除了维护 workloads API 之外，我还推动 Agent（智能体） Sandbox 等新子项目，以确保 Kubernetes 为下一代智能体和 AI 工作负载做好准备。

Maciej Szulik：我从 2014 年就开始为 Kubernetes 做贡献。从那时起，我在项目的多个领域工作过：控制器、kubectl 和 apimachinery，这最终让我成为 SIG Apps 的主席和技术负责人之一。我目前的重点是在 SIG Apps 框架下提升工作负载控制器的可靠性，以及作为 SIG CLI 技术负责人确保 kubectl 的稳定性和易用性。作为指导委员会成员，我也关心整体社区的健康和成长。在 Kubernetes 之外，我在 Defense Unicorns 担任 Staff Platform Engineer，通过一个名为 zarf 的项目帮助 Kubernetes 更加原生支持气隙环境。

问题与解决方案

SIG Apps 负责支撑应用在 Kubernetes 上运行方式的核心工作负载 API。从 Deployments 和 StatefulSets 到 Jobs 和 CronJobs，这些控制器决定了工作负载在出现问题时如何创建、更新、扩缩容和恢复。

随着 Kubernetes 扩展以支持日益多样化的工作负载——包括 AI、批处理和大规模分布式应用——SIG Apps 持续演进这些 API，同时平衡可靠性、向后兼容性和运维简洁性。

NF：对于可能不太熟悉的读者，什么是 SIG Apps，它在更广泛的 Kubernetes 生态系统中扮演什么角色？

MS：SIG Apps 是 Kubernetes 特别兴趣小组，负责工作负载 API。CronJob 和 Job 帮助运行批处理工作负载，而 DaemonSet、Deployment、ReplicaSet 和 StatefulSet 则服务于大多数其他应用程序。更广泛地说，SIG Apps 拥有大多数开发者日常实际接触的层：将工作负载规范转化为运行中、自愈的 Pod 的控制器。它是决定 Deployment 如何滚动发布、Job 如何重试、DaemonSet 如何按节点放置 Pod 的小组。

JK：补充 Maciej 的描述，随着行业转型，我们看到运行复杂、非传统工作负载（如分布式 AI 训练、批处理和动态智能体环境）的巨大需求。我们的角色正在扩展：我们不仅维护经典的工作负载 API，还在积极演进它并建立新模式（如 Agent Sandbox），以确保 Kubernetes 仍然是下一代工作负载（如 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 内零散地解决，而是决定成立一个专门的节点生命周期工作组来妥善处理，并希望能落地长期解决方案而非一次性补丁。

JK：从 AI 的角度来看，弹性至关重要。当你运行跨越数百个 GPU 的大规模分布式 LLM 训练任务时，单个节点故障就可能中止整个流水线。同样，如果运行日志或 GPU 监控智能体的 DaemonSet 卡在坏节点上，会影响整个集群的健康。

除了节点生命周期工作组处理基础设施级降级的工作外，SIG Apps 还通过 JobSet（用于分布式训练）和 LeaderWorkerSet（LWS）（用于分片 LLM 推理）等子项目在编排层解决这个问题。这些 API 引入了“全有或全无”的故障处理模式，即单个 Pod 或 Job 故障会触发协调的组级重启，从最后一个干净的检查点恢复，而不是让卡住的工作负载停留在不一致状态。

实际影响

SIG Apps 内部正在进行的工作远不止控制器实现和 API 设计。我们希望了解这些改进对在生产环境中运行 Kubernetes 集群的平台团队来说，在实践中意味着什么。

NF：对于在生产环境中运行 Kubernetes 的平台团队来说，如果当前正在讨论的节点生命周期和工作负载韧性相关工作能够成功交付，他们会注意到哪些实际改进？

MS：我主要是从旁观者的角度来看，真正在 Node Lifecycle Working Group 里的人会给你更准确的答案。但就我来看，我希望他们的工作能够转化为更少的凌晨 3 点告警，那些最终被证明是“某个 DaemonSet 滚动发布卡住了，因为节点 X 不稳定，有人不得不手动 cordon/delete/restart 才能把它解开”的情况。

JK：同意 Maciej 所说的，除了减少人工干预之外，平台团队还将看到更好的资源可预测性和成本效率。例如，在 GPU 空闲时间极其昂贵的 AI 工作负载中，让 Kubernetes 自动检测到降级节点，并在作业崩溃前重新调度训练协调器或智能体，意味着更少的计算浪费和更稳定的作业执行。

## 挑战与权衡

演进数百万工作负载所依赖的 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 都提供了许多参与机会。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Kubernetes Blog

原创地址：https://kubernetes.io/blog/2026/09/22/sig-apps-spotlight/