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