У Kubernetes v1.35 стабілізувалося поле .spec.managedBy (https://kubernetes.io/blog/2025/12/18/kubernetes-v1-35-job-managedby-for-jobs-goes-ga/). Воно дозволяє передати управління Job зовнішньому контролеру для зручного мультикластерного планування без вимкнення вбудованого Job-контролера.

Ідея з виділенням control-plane в окремий k8s кластер поступово стає доступною на дедалі менших інсталяціях:

• Gardener: Архітектура “garden/seed/shoot”: control planes “shoot”-кластерів запускаються як workloads у “seed”-кластерах (окремий домен/кластер для control plane), а “shoot” тримає worker-ноди.
• MultiKueue: механізм Kueue для мультикластерного диспетчингу batch-навантажень у Kubernetes.
• Crossplane: Використовується як control plane в окремому кластері для декларативного provisioning зовнішніх ресурсів (у т.ч. Kubernetes-кластерів) через managed resources/compositions.
• Argo ApplicationSet: генерація Applications за списком кластерів/лейблами/матрицями.
• Flux CD Hub and Spoke: один центральний кластер керує доставкою застосунків та інфраструктури на кілька цільових кластерів через Helm/Kustomize, з RBAC, залежностями, моніторингом та CI.
• і вагон рішень для ентерпрайзу.

Тенденція цікава. З одного боку — ускладнення, з іншого — чудове розділення для черговості ініціалізації, безпеки, надійності, спрощення ops і так далі. В ідеалі, якби цей control-plane кластер орендувався у когось з високою надійністю вже в готовому вигляді: з моніторингом, правами, налаштованим профілем workload-кластера (включаючи CD) і так далі. А краще — інструмент для такого “розгортання”. “Денвер для k8s multi-cluster” 🙂