Spotlight on SIG Apps：Kubernetes 应用工作负载演进的幕后引擎

核心摘要：SIG Apps 不是 Kubernetes 的“可选模块”，而是所有应用交付的底层契约——Deployments、StatefulSets、Jobs 等原生 Workload API 的设计者与守门人。在 AI 工作负载（如 vLLM 推理服务）、混合状态模型（有状态 Web + 无状态 API + Batch 训练）和跨云韧性升级成为常态的今天，SIG Apps 正从“如何部署”转向“如何可靠地演化”。其技术重心已悄然迁移：Rollout 控制器不再只关注 ReplicaSet 切换，而需协同 Kubelet、CSI、CNI 和调度器实现 workload-aware reconciliation；StatefulSet 的 podManagementPolicy 与 revisionHistoryLimit 开始影响 LLM 微调任务的 checkpoint 恢复路径；甚至 CronJob 的 startingDeadlineSeconds 在 GPU 集群资源争抢场景下，正成为 AI pipeline SLA 的隐性瓶颈。

背景动机：当“运行容器”已成过去式

Kubernetes 1.0 时代的核心命题是“如何把 Docker 容器跑起来”；而今天，SRE 团队面对的是更棘手的问题：

一个 vLLM + Triton 推理服务集群，要求滚动更新时 P99 延迟波动 < 50ms，且 GPU 显存不被新旧 Pod 同时抢占；
一个 Spark-on-K8s 批处理作业，在节点故障后需自动重试并恢复至 checkpoint，而非从头计算；
一个混合架构的微服务系统（前端 Deployment + Redis StatefulSet + Kafka Operator CRD + Prometheus CronJob），如何在一次集群升级中保证整体可用性 > 99.95%？

这些问题已超出 kube-scheduler 或 kubelet 的职责边界，直指 Workload API 层的设计哲学：它必须既是声明式契约（Declarative Contract），又是韧性执行引擎（Resilient Execution Engine）。而 SIG Apps，正是这个层的唯一维护者。

值得注意的是：SIG Apps 并不直接开发 Operator（那是 SIG API Machinery 或社区生态的事），而是为所有 Operator 提供语义基座——例如，Operator 的 Reconcile() 函数若要安全地扩缩 Pod，必须遵循 ReplicaSet 的 scale subresource 协议；若要实现有状态拓扑感知，必须复用 StatefulSet 的 pod-name-ordinal 命名规则与 volumeClaimTemplates 绑定逻辑。换句话说：你写的每一个 Helm Chart、Kustomize patch、甚至 Argo CD Application，底层都在调用 SIG Apps 定义的 API 原语。

核心技术：从基础控制器到韧性生命周期管理

1. Deployment：不只是“滚动更新”，而是 rollout 可观测性中枢

Deployment 的本质是一个 ReplicaSet 控制器的“元控制器”。但 SIG Apps 近年对其强化了三类关键能力：

Rollout 进度语义化：通过 status.conditions 中新增的 Progressing 和 Available 条件，配合 kubectl rollout status deployment/my-app --watch，SRE 可在 CI/CD 流水线中嵌入自动化熔断逻辑：

yaml

# 示例：Argo CD 自动回滚策略（基于 Deployment condition）
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  healthCheck:
    # 自定义健康检查：若 Deployment.status.conditions[0].type == "Progressing" 
    # 且 .status.conditions[0].status == "False" 持续 300s，则触发回滚

Pod Disruption Budget (PDB) 深度集成：Deployment 现在会主动等待 PDB 允许的 minAvailable 满足后才驱逐旧 Pod，避免滚动更新期间服务中断。这是 AI 推理服务高可用的硬性前提。

2. StatefulSet：面向 AI/ML 工作负载的拓扑韧性增强

传统认知中，StatefulSet 仅用于数据库。但 SIG Apps 已将其演进为 有状态计算单元的通用抽象。关键改进包括：

revisionHistoryLimit 控制 StatefulSetRevision 对象数量，直接影响 vLLM 模型热更新时的 checkpoint 版本回溯能力；
podManagementPolicy: Parallel + updateStrategy.type: RollingUpdate 组合，使分布式训练（如 DeepSpeed）能并行拉起全部 Worker Pod，加速 scale-up；
volumeClaimTemplates 与 CSI Driver 的深度协同：当使用 local-path-provisioner 或 rook-ceph 时，StatefulSet 会确保 PVC 名称与 Pod 名严格绑定，保障 GPU 计算节点重启后模型权重卷零丢失。

yaml

# vLLM + DeepSpeed 分布式推理服务典型 StatefulSet 片段
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: vllm-inference
spec:
  serviceName: "vllm-headless"
  replicas: 4
  podManagementPolicy: Parallel  # 关键！避免串行启动导致 GPU 空转
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 0  # 全量滚动，或设为 2 实现灰度
  revisionHistoryLimit: 5  # 保留最近 5 个 checkpoint 版本
  volumeClaimTemplates:
  - metadata:
      name: weights
    spec:
      accessModes: ["ReadOnlyMany"]
      storageClassName: "ceph-rbd-ro"
      resources:
        requests:
          storage: 200Gi

3. Job/CronJob：批处理的“确定性执行”保障

AI 训练 pipeline 对 Job 的可靠性要求远超传统 Cron 任务。SIG Apps 引入的关键机制：

backoffLimit 与 ttlSecondsAfterFinished 的组合，防止失败 Job 持久化占用 etcd；
CronJob.spec.startingDeadlineSeconds（默认 100s）必须显式调大至 600 以上，否则在 GPU 节点资源紧张时，定时训练任务可能因调度延迟而被跳过；
job.spec.completions + parallelism 支持 MPI-style 批处理，例如 completions: 8, parallelism: 4 表示分两轮完成 8 个独立训练任务。

运维建议：面向生产环境的 SIG Apps 最佳实践

永远启用 --feature-gates=JobTrackingWithFinalizers=true
（K8s 1.27+ 默认开启）该特性让 Job 控制器通过 Finalizer 精确跟踪 Pod 生命周期，避免因 kubelet crash 导致 Job “假完成”。这是 AI pipeline 依赖链可靠性的基石。
StatefulSet 升级务必配合 kubectl rollout restart 而非 kubectl apply
直接 apply 可能绕过 updateStrategy 触发强制重建，导致 PVC 意外解绑。正确姿势：
bash
```
kubectl set env statefulset/vllm-inference VERSION=v2.3.1 --overwrite
kubectl rollout restart statefulset/vllm-inference
```
为 Deployment 配置 minReadySeconds: 30 + progressDeadlineSeconds: 600
避免因 Pod 启动慢（如 vLLM 加载 70B 模型需 90s）被误判为失败。minReadySeconds 强制控制器等待健康检查通过后再计入可用副本数。
警惕 CronJob 的 concurrencyPolicy: Allow
在 GPU 集群中，若训练任务超时未退出，新实例将并发抢占显存，引发 OOMKill。生产环境应始终设为 Forbid 或 Replace。
监控维度必须覆盖 kube_state_metrics 的以下指标：
- kube_job_status_succeeded{job="my-training-job"}（确认完成）
- kube_deployment_status_replicas_updated{deployment="api-server"}（滚动进度）
- kube_statefulset_status_replicas_current{statefulset="redis-cluster"}（拓扑一致性）

Spotlight on SIG Apps：Kubernetes 应用工作负载演进的幕后引擎 ​

背景动机：当“运行容器”已成过去式 ​

核心技术：从基础控制器到韧性生命周期管理 ​

1. Deployment：不只是“滚动更新”，而是 rollout 可观测性中枢 ​

2. StatefulSet：面向 AI/ML 工作负载的拓扑韧性增强 ​

3. Job/CronJob：批处理的“确定性执行”保障 ​

运维建议：面向生产环境的 SIG Apps 最佳实践 ​

延伸阅读：SIG Apps 的未来战场 ​