聚焦SIG Apps
内容提要
SIG Apps负责Kubernetes核心工作负载API（Deployment、StatefulSet、Job等）。两位主席回顾其演进，当前重点包括：提升工作负载弹性与节点生命周期管理，成立专项工作组；通过JobSet、LeaderWorkerSet、Agent Sandbox等新项目支持AI训练与推理；在保持向后兼容前提下谨慎演进API。KEP-4443拟为PodFailurePolicyRule增加Name字段，便于上层工具区分失败原因。
延伸解读
SIG Apps 的职责与影响
SIG Apps 负责 Kubernetes 核心工作负载 API，包括 Deployment、StatefulSet、DaemonSet、Job 和 CronJob。这些控制器将工作负载规范转化为运行中的自愈 Pod，决定了应用如何部署、更新、扩缩容以及在故障时恢复。无论用户是否意识到，每个 Kubernetes 用户都依赖 SIG Apps 的工作。
当前工作重点：弹性与节点生命周期
SIG Apps 当前重点提升工作负载弹性与节点生命周期管理。节点生命周期问题在 SIG Apps、SIG Node 和 SIG Autoscaling 中反复出现，因此成立了专项工作组，旨在提供长期解决方案而非临时补丁。同时，通过 JobSet、LeaderWorkerSet 和 Agent Sandbox 等新项目支持 AI 训练与推理，引入“全有或全无”的故障处理模式。
API 演进的权衡与策略
在演进核心工作负载控制器时，SIG Apps 面临艰难权衡：控制器应多积极地放弃卡住的 Pod，以及需要哪些信号来正确判断。同时必须考虑向后兼容性，因为 Deployment、DaemonSet 和 Job 的行为已被依赖十年，即使更正确的更改也可能破坏自动化。因此，SIG Apps 倾向于设计可选功能，并以 CRD 形式引入全新范式，而非膨胀核心 API。
KEP-4443 提案与贡献机会
KEP-4443 拟为 PodFailurePolicyRule 增加可选的 Name 字段，该字段会附加到 JobFailed 条件原因中，使 JobSet 等上层工具能根据触发失败的规则做出不同反应。该提案因原贡献者离开而搁置，现已有新人接手，目标在 Kubernetes 1.38 发布。对于新贡献者，建议从 #sig-apps Slack 频道和定期会议开始，或参与 Agent Sandbox 等新子项目，这些项目有大量绿地开发机会。
Q&A
SIG Apps 在 Kubernetes 中负责哪些工作？
SIG Apps 是 Kubernetes 中负责核心工作负载 API 的特别兴趣小组，包括 Deployment、StatefulSet、DaemonSet、Job 和 CronJob 等控制器，这些控制器决定了工作负载的创建、更新、扩缩容和故障恢复方式。
SIG Apps 当前关注的重点方向有哪些？
当前重点包括：提升工作负载弹性与节点生命周期管理（已成立专项工作组），通过 JobSet、LeaderWorkerSet、Agent Sandbox 等新项目支持 AI 训练与推理，以及在保持向后兼容的前提下谨慎演进 API。
SIG Apps 如何应对 AI 和分布式工作负载带来的弹性挑战？
SIG Apps 通过子项目如 JobSet（用于分布式训练）和 LeaderWorkerSet（用于分片 LLM 推理）在编排层引入“全有或全无”的故障处理模式，即单个 Pod 或 Job 失败会触发组级协调重启，从最近检查点恢复，避免工作负载卡在不一致状态。
KEP-4443 提案要解决什么问题？
KEP-4443 旨在为 Job API 的 PodFailurePolicyRule 增加一个可选的 Name 字段，该字段会被附加到 JobFailed 条件原因中，使上层工具（如 JobSet）能够根据触发失败的具体规则做出不同反应，解决当前不同规则产生相同通用原因的问题。
SIG Apps 在演进核心工作负载控制器时面临哪些主要权衡？
主要权衡包括：控制器应在多大程度上放弃卡住的 Pod 以及需要哪些信号来正确判断；同时必须考虑向后兼容性，因为 Deployment、DaemonSet 和 Job 的行为已被依赖十年，即使更正确的更改也可能破坏现有自动化。因此 SIG Apps 倾向于设计可选功能，并以 CRD 形式引入全新范式。
对于想为 SIG Apps 做贡献的新人，有什么建议？
建议从 #sig-apps Slack 频道和定期 SIG Apps 会议开始。也可以关注较新的子项目如 Agent Sandbox，这些项目正在积极演进，维护者友好，有大量绿地开发机会，适合新人快速做出显著贡献。
