Kubernetes v1.35：Job Managed By 特性正式发布（GA）
在 Kubernetes v1.35 中，通过 .spec.managedBy 指定外部 Job 控制器的能力升级为正式可用（GA）。
该特性允许外部控制器对 Job 的调谐（reconciliation）承担完全责任，从而解锁更强大的调度模式， 例如借助 MultiKueue 进行跨多集群派发。
为何要委派 Job 调谐？
该特性的主要动机是支持多集群批处理调度架构，例如 MultiKueue。
MultiKueue 架构区分“管理集群（Management Cluster）”与一组“工作集群（Worker Clusters）”：
- 管理集群负责派发 Job，但不负责执行。 它需要接收 Job 对象以跟踪状态，但会跳过 Pod 的创建与执行。
- 工作集群接收被派发的 Job，并执行实际的 Pod。
- 用户通常与管理集群交互。由于状态会自动回传， 用户无需访问工作集群也能“实时”观察 Job 的进度。
- 在工作集群中，被派发的 Job 会作为常规 Job 运行，
由内置 Job 控制器管理，且不会设置
.spec.managedBy。
通过使用 .spec.managedBy，管理集群上的 MultiKueue 控制器可以接管某个 Job 的调谐。
它会将工作集群中运行的“镜像（mirror）Job”的状态复制回管理集群。
为什么不直接禁用 Job 控制器？理论上可以通过完全禁用内置 Job 控制器来实现， 但这通常不可行或不现实，原因主要有两点：
- 托管控制平面：在许多云环境中，Kubernetes 控制平面是锁定的， 用户无法修改控制器管理器的参数。
- 混合集群角色：用户常常需要一种“混合”模式：
管理集群将部分重型工作负载派发到远端集群，
但仍在管理集群中执行较小的、或与控制平面相关的 Job。
.spec.managedBy让这种粒度可以按 Job 逐个控制。
.spec.managedBy 的工作机制
.spec.managedBy 字段用于指示由哪个控制器负责该 Job。
具体而言，它有两种工作模式：
- 标准（Standard）：如果未设置，或设置为保留值
kubernetes.io/job-controller， 内置 Job 控制器会像往常一样调谐该 Job（标准行为）。
- 委派（Delegation）：如果设置为任何其他值，内置 Job 控制器将完全跳过对该 Job 的调谐。
为防止出现孤儿 Pod 或资源泄漏，该字段是不可变的（immutable）。 你不能将一个正在运行的 Job 从一个控制器转移到另一个控制器。
如果你计划实现一个外部控制器，请注意你的控制器需要符合 Job API 的定义。
为确保这种一致性，这项工作的一个重要部分是引入了一套完善且严格的 Job 状态校验规则。
更多细节请参阅如何进一步了解？一节。
生态采纳情况
.spec.managedBy 字段正在快速成为 Kubernetes 批处理生态中委派控制的标准接口。
多种自定义工作负载控制器正在加入该字段（或等效字段）， 以便让 MultiKueue 接管它们的调谐并在多集群之间进行编排：
虽然理论上可以用 .spec.managedBy 从零实现一个自定义 Job 控制器，
但我们尚未观察到这种用法。该特性更明确地面向委派模式（例如 MultiKueue）而设计，
以避免重复造轮子。
如何进一步了解？
如果你想进一步深入了解：
阅读面向用户的文档：
深入了解设计历程：
- Kubernetes 增强提案（KEP）Job's managed-by mechanism， 其中包括引入了更全面的 Job status validation rules。
- Kueue 的 KEP：MultiKueue。
也可以通过任务指南了解 MultiKueue 在实践中如何使用 .spec.managedBy：
跨集群运行 Job。
致谢
与任何 Kubernetes 特性一样，这项特性也由许多人一起塑造： 他们参与设计讨论、评审、试运行与缺陷报告等工作。
我们特别感谢：
- Maciej Szulik——提供指导、辅导与评审。
- Filip Křepinský——提供指导、辅导与评审。
参与其中
这项工作由 Kubernetes 的 Batch Working Group 发起， 并与 SIG Apps 紧密协作， 同时也得到了 SIG Scheduling 社区的强力支持与投入。
如果你对批处理调度、多集群解决方案或进一步改进 Job API 感兴趣：
- 欢迎加入 Batch WG 与 SIG Apps 会议。