Kubernetes v1.35: Job Managed By Goes GA

Source: Kubernetes Blog

What This Means

• Full responsibility for Job reconciliation can now be delegated to external controllers.
• Enables advanced scheduling patterns, such as multi‑cluster dispatching.

Example Use‑Case

The MultiKueue project leverages this feature to orchestrate Jobs across multiple clusters.

For more details, refer to the official Kubernetes release notes for v1.35.

Why Delegate Job Reconciliation?

The primary motivation for this feature is to support multi‑cluster batch scheduling architectures, such as MultiKueue.

Architecture Overview

MultiKueue distinguishes between two kinds of clusters:

• Users normally interact with the Management Cluster.
• Because the status is automatically propagated back, users can observe a Job’s progress live without needing to access the Worker Clusters.
• In the Worker Clusters, the dispatched Jobs run as regular Jobs managed by the built‑in Job controller, without a .spec.managedBy field set.

Role of .spec.managedBy

By setting .spec.managedBy, the MultiKueue controller on the Management Cluster can take over reconciliation of a Job. It copies the status from the “mirror” Job running on the Worker Cluster back to the Management Cluster.

Why Not Simply Disable the Job Controller?

Disabling the built‑in Job controller altogether is often impossible or impractical for two main reasons:

1. Managed Control Plans – In many cloud environments the Kubernetes control plane is locked down, and users cannot modify controller‑manager flags.
2. Hybrid Cluster Role – Users frequently need a “hybrid” mode where the Management Cluster dispatches heavy workloads to remote clusters and still runs smaller or control‑plane‑related Jobs locally.
   • .spec.managedBy provides the necessary granularity on a per‑Job basis.

How .spec.managedBy Works

The .spec.managedBy field indicates which controller is responsible for a Job. It supports two modes of operation:

Note: This field is immutable. You cannot transfer a running Job from one controller to another, which helps prevent orphaned Pods or resource leaks.

Implementing an External Controller

If you plan to implement an external controller, ensure it conforms to the Job API specification. Conformance is enforced through extensive Job status validation rules.

Ecosystem Adoption

The .spec.managedBy field is rapidly becoming the standard interface for delegating control in the Kubernetes batch ecosystem.

Various custom workload controllers are adding this field (or an equivalent) to allow MultiKueue to take over their reconciliation and orchestrate them across clusters:

• JobSet
• Kubeflow Trainer
• KubeRay
• AppWrapper
• Tekton Pipelines

While it is possible to use .spec.managedBy to implement a custom Job controller from scratch, we haven’t observed that yet. The feature is specifically designed to support delegation patterns—like MultiKueue—without reinventing the wheel.

How Can You Learn More?

Documentation

• Jobs –
• Delegation of managing a Job object to an external controller –
• MultiKueue –

Design History

• Kubernetes Enhancement Proposal (KEP) – Job’s managedBy mechanism
  • Overview: –
  • Job‑status validation rules: –
• Kueue KEP – MultiKueue –

Practical Guide

• See how MultiKueue uses .spec.managedBy in the task guide for running Jobs across clusters –

Acknowledgments

As with any Kubernetes feature, many people helped shape this one through design discussions, reviews, test runs, and bug reports.
We would like to thank, in particular:

• Maciej Szulik – for guidance, mentorship, and reviews.
• Filip Křepinský – for guidance, mentorship, and reviews.

Get Involved

This work was sponsored by the Kubernetes Batch Working Group in close collaboration with SIG Apps, and with strong input from the SIG Scheduling community.

If you are interested in batch scheduling, multi‑cluster solutions, or further improving the Job API, you can:

• Join us in the Batch WG and SIG Apps meetings.
• Subscribe to the WG Batch Slack channel.