In Kubernetes v1.35, the .spec.managedBy field has gone stable (https://kubernetes.io/blog/2025/12/18/kubernetes-v1-35-job-managedby-for-jobs-goes-ga/). It lets you hand off Job management to an external controller for convenient multi-cluster scheduling, without disabling the built-in Job controller.

The idea of putting the control plane into a separate k8s cluster is gradually becoming accessible even on smaller installations:

• Gardener: the “garden/seed/shoot” architecture: control planes of “shoot” clusters run as workloads in “seed” clusters (a separate domain/cluster for the control plane), while the “shoot” itself keeps the worker nodes.
• MultiKueue: Kueue’s mechanism for multi-cluster dispatching of batch workloads in Kubernetes.
• Crossplane: used as a control plane in a separate cluster for declarative provisioning of external resources (including Kubernetes clusters) via managed resources/compositions.
• Argo ApplicationSet: generating Applications from a list of clusters/labels/matrices.
• Flux CD Hub and Spoke: one central cluster manages delivery of apps and infrastructure to multiple target clusters via Helm/Kustomize, with RBAC, dependencies, monitoring, and CI.
• and a whole wagonload of enterprise solutions.

The trend is interesting. On the one hand — more complexity; on the other — great separation for init ordering, security, reliability, simplifying ops, and so on. Ideally, this control-plane cluster would be rented from someone with high reliability in a ready-made form: with monitoring, permissions, a configured workload-cluster profile (including CD), and so on. Better yet — a tool for such “rolling out”. “Denver for k8s multi-cluster” 🙂