devops

Kubernetes v1.35：通过原地 Pod 重启实现新水平的效率

发布: (2026年1月3日 GMT+8 02:30)
10 min read
原文: Kubernetes Blog

Source: Kubernetes Blog

启用功能

通过启用 RestartAllContainersOnContainerExits 功能门即可使用此功能。此 alpha 功能是对 Container Restart Rules 功能的扩展，该功能已在 Kubernetes 1.35 中升级为 beta。

# Example feature‑gate configuration
apiVersion: apiserver.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: RestartAllContainersOnContainerExits
    configuration:
      enabled: true

问题

当单容器重启不足且重新创建 Pod 成本过高时，现有的重启机制就显得力不从心。

  • Kubernetes 长期支持 restartPolicy（Pod 级别），最近也支持了 单容器级别 的 restartPolicy。
  • 这些策略在处理单独的崩溃时表现良好，但许多现代应用都有 复杂的容器间依赖。

典型场景

  • Init 容器 用于准备环境（例如挂载卷或生成配置文件）。
    如果主应用容器破坏了该环境，仅重启主容器并不足够——必须重新执行整个初始化过程。

  • Watcher sidecar 监控系统健康。
    当它检测到不可恢复但可重试的错误状态时，需要从干净的状态重新启动主应用容器。

  • 资源管理 sidecar 失效。
    即使 sidecar 能自行重启，主容器可能仍卡在尝试访问已过期或损坏的连接上。

在所有这些情况下，期望的操作 不是 重启单个容器，而是 全部容器一起 重启。以前唯一的办法是删除 Pod，让控制器（例如 Job 或 ReplicaSet）创建一个新 Pod——这是一种缓慢且昂贵的过程，需要调度器、节点资源分配以及网络和存储的重新初始化。

对大规模 AI/ML 工作负载的影响

  • 规模：≥ 1,000 节点，每节点一个 Pod。
  • 需求：当出现故障（例如节点崩溃）时，整个集群的所有 Pod 必须重新创建，以在训练继续前重置状态，即使大多数 Pod 并未直接受影响。
  • 成本：同时删除、创建并调度数千个 Pod 会形成巨大的瓶颈。估计的额外开销约为 ≈ $100 k 每月 的资源浪费。

传统上处理这些故障需要在训练框架与 Kubernetes 之间进行复杂的集成——往往脆弱且繁琐。新特性提供了 Kubernetes 原生的解决方案，提升了鲁棒性，让开发者可以专注于核心训练逻辑。

额外收益

保持 Pod 在其分配的节点上运行，可进一步实现 基于特定 Pod 身份的节点级缓存——这在 Pod 被不必要地迁移到不同节点时是无法实现的。

介绍 RestartAllContainers 操作

Kubernetes v1.35 为容器重启规则添加了一个新动作：RestartAllContainers。
当容器以符合该动作规则的方式退出时，kubelet 会启动一次快速的 就地重启 Pod。

就地重启期间保留了哪些内容？

  • Pod UID、IP 地址和网络命名空间
  • Pod 沙箱及所有附加设备
  • 所有卷，包括 emptyDir 和来自 PVC 的挂载卷

在终止所有运行中的容器后，Pod 的启动顺序会从头重新执行：

  1. 所有 init 容器 按顺序再次运行。
  2. 随后启动 sidecar 和普通容器，确保在已知良好的环境中进行全新启动。

注意： 临时容器会被终止。所有其他容器——包括之前成功或失败的容器——都会被重新启动，且不受各自重启策略的影响。

用例

1. 高效重启机器学习/批处理作业

  • 问题： 在故障时重新调度工作节点 Pod 成本高昂；在一个拥有 1,000 台节点的训练集群中，额外开销每月可能超过 $100 k 的计算资源。
  • 解决方案： 使用 RestartAllContainers 实现 快速、混合的恢复策略：
    • 仅重新创建“异常”Pod（例如，位于不健康节点上的 Pod）。
    • 对其余健康的 Pod 触发 RestartAllContainers。
  • 结果： 基准测试显示恢复开销从 几分钟降至几秒。

2. 由 Watcher‑Sidecar 驱动的重置

Watcher sidecar 可以监控主训练进程。如果它遇到特定的、可重试的错误，watcher 将以指定的退出码退出，从而触发工作节点 Pod 的快速重置，使其能够 在不涉及 Job 控制器的情况下 从上一次检查点重新启动。此功能现已在 Kubernetes 中原生支持。

了解更多： 未来的开发和 JobSet 功能已在 KEP‑467 – JobSet in‑place restart 中描述。

示例 Pod 规范

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
    # This init container will re‑run on every in‑place restart
    - name: setup-environment
      image: my-repo/setup-worker:1.0
  containers:
    - name: watcher-sidecar
      image: my-repo/watcher:1.0
      # Container‑level restart policy (still respected for individual restarts)
      restartPolicy: Always
  restartPolicyRules:
    - action: RestartAllContainers
      # Example rule: trigger when the watcher exits with code 42
      exitCodes: [42]

上面的代码片段演示了如何声明一个 pod，使其在 watcher-sidecar 以退出码 42 退出时重新启动 所有容器。

Bottom Line

RestartAllContainers 为 Kubernetes 用户提供了一种 轻量级、就地的 pod 重置机制，它：

  • 在大规模下节省计算资源和成本。
  • 将恢复时间从分钟降至秒级。
  • 保留关键的 pod 身份（UID、IP、卷等）。
  • 在无需额外控制器逻辑的情况下，实现更丰富的 sidecar 驱动恢复模式。

此功能标志着在 Kubernetes 上构建 健壮、高效的 AI/ML 平台 的重要一步。

RestartAllContainers

onExit

exitCodes:
  operator: In          # A specific exit code from the watcher triggers a full pod restart
  values: [88]
containers:
  - name: main-application
    image: my-repo/training-app:1.0

1. 重新运行 Init 容器以获得干净状态

想象一种情况，init 容器负责获取凭证或设置共享卷。
如果主应用以某种方式失败并破坏了该共享状态，则需要重新运行 init 容器。

通过配置主应用在检测到此类损坏时以特定代码退出，您可以触发 RestartAllContainers 操作，确保 init 容器在应用重新启动之前提供干净的设置。

2. 高速率相似任务执行的处理

某些工作负载最适合以 Pod 执行的方式呈现，其中每个任务都需要一个干净的环境（例如，游戏会话后端或队列项处理器）。
当任务速率很高时，Pod 的完整创建、调度和初始化周期成本过高——尤其是对于短生命周期的任务。

能够从头重新启动 所有容器 提供了一种 Kubernetes 原生的方式来处理此场景，无需自定义解决方案或框架。

如何使用

  1. 启用功能门

    • 在您的 Kubernetes 控制平面组件（API 服务器和 kubelet）上设置 RestartAllContainersOnContainerExits。
    • 需要 Kubernetes v1.35+。
    • 此 alpha 功能扩展了 ContainerRestartRules 功能，该功能在 v1.35 中升级为 beta 并默认启用。

  2. Add restartPolicyRules to any container (init, sidecar, or regular) and use the RestartAllContainers action.

  3. 最佳实践清单

    • 确保所有容器都是 可重入 的。
    • 验证外部工具能够处理 init 容器的重新运行。
    • 请记住，当发生完整容器重启时，preStop 钩子不会执行；容器必须能够容忍突发终止。

观察重启

  • 在 Pod 的状态中新增了一个条件 AllContainersRestarting。

    • 当触发重启时变为 True。
    • 当所有容器已终止且 Pod 准备重新开始其生命周期时恢复为 False。

  • 此操作导致重启的所有容器，其容器状态中的 restart count 将递增。

Learn More

  • Pod Lifecycle – 官方文档。
  • KEP‑5532 – Restart All Containers on Container Exits（详细提案）。
  • JobSet in‑place restart – JobSet issue #467 中的讨论。

我们想听取您的反馈！

作为 alpha 功能，RestartAllContainers 已准备好供实验使用。
欢迎提供您的使用案例和反馈。此功能由 SIG Node 社区驱动。

参与方式：

  • Slack: #sig-node
  • 邮件列表: (link to SIG Node mailing list)
Back to Blog

相关文章

阅读更多 »