В 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” 🙂