Can Kamaji manage the management cluster’s own control plane?

[MattiaDellOca]

Hey there! I recently learned about Kamaji at Voxxed Days Ticino 2026!

From what I understand, Kamaji helps simplify the management of Kubernetes clusters in a multi-tenant setup by automatizing part of the lifecycle such as certificates expiration.

As mentioned in the title, I’m curious whether Kamaji can manage the lifecycle of the cluster it’s running in. My impression is that it can’t, but I wanted to double-check before erroneously moving on 😅. My knowledge of the tool is still limited, and I’d like to see if it fits my scenario.

The reason I ask is that I recently started administrating an on-prem kubeadm-bootstrapped Kubernetes cluster. I’ve heard that managing a cluster manually can become overwhelming over time. Even though I haven’t run into major issues yet, I want to be prepared for potential challenges down the line.

Thanks so much for your time! 😁

[prometherion]

Hey Mattia, thanks for reaching out and for attending my talk at Voxxed!

Offering Control Planes management requires Kamaji relying on the Kubernetes primitives: a Deployment creating Pods hosted on a worker Node. This creates an egg/chicken problem since Kamaji needs an API Server to manage this operations, thus, it must be already existing somewhere else.

The basic idea behind Kamaji is: let's have a pet cluster to create as many as possible cattle clusters; way easier dealing with just one.

However, if you're interested, there was a presentation where a Kamaji adopter was managing bare metal nodes backed by Kamaji Control Plane pods which were running on (drums roll) a Kind (Kubernetes on Docker) instance. Although it sounds fascinating, the main problem again is about resiliency, and self remediation: a distributed system like Kubernetes has been designed on purpose, and everything running on a single instance is not compared to a production grade, due to several circumstances.

Eventually answering: no, Kamaji can't manage itself the management cluster where is itself running. But this doesn't mean it's not possible: we're heavily committed with another project named YAKI (Yet Another Kubernetes Installer) aimed to streamline and simplify the management of Kubernetes clusters, both for the management, as well as for the downstream/tenant ones.

I strongly believe in the Single Responsibility Principle, which sounds similar to the UNIX one's too (do one thing and so it right): although a but off topic, YAKI will play with Kamaji to simplify such management, and make Kubernetes at scale entirely autonomous.

I’ve heard that managing a cluster manually can become overwhelming over time.

Don't want to spread FUD here, but we have better things to do during our day times rather than managing Kubernetes: manual operations are toil, everything that could be automated and it's not is toil.