In Kubernetes v1.35, the ability to specify an external Job controller (through .spec.managedBy) graduates to General Availability. This feature allows external controllers to take full responsibility for Job reconciliation, unlocking powerful scheduling patterns like multi-cluster dispatching with MultiKueue. Why delegate Job reconciliation? The primary motivation for this feature is to support multi-cluster batch scheduling architectures, such as MultiKueue. The MultiKueue architecture distinguishes between a Management Cluster and a pool of Worker Clusters: The Management Cluster is responsible for dispatching Jobs but not executing them. It needs to accept Job objects to track status, but it skips the creation and execution of Pods. The Worker Clusters receive the dispatched Jobs and execute the actual Pods. Users usually interact with the Management Cluster. Because the status is automatically propagated back, they can observe the Job’s progress "live" without accessing the Worker Clusters. In the Worker Clusters, the dispatched Jobs run as regular Jobs managed by the built-in Job controller, with no .spec.managedBy set. By using .spec.managedBy, the MultiKueue controller on the Management Cluster can take over the reconciliation of a Job. It copies the status from the "mirror" Job running on the Worker Cluster back to the Management Cluster. Why not just disable the Job controller? While one could theoretically achieve this by disabling the built-in Job controller entirely, this is often impossible or impractical for two reasons: Managed Control Planes: In many cloud environments, the Kubernetes control plane is locked, and users cannot modify controller manager flags. Hybrid Cluster Role: Users…
Want more insights? Join Grow With Caliber - our career elevating newsletter and get our take on the future of work delivered weekly.