# Kamaji: Kubernetes control planes as Pods inside a management cluster > Kamaji is a Kubernetes Operator that runs tenant control planes as Pods inside a management cluster instead of on dedicated machines. It targets platform teams provisioning many clusters, and supports etcd, MySQL, PostgreSQL and NATS as backing stores. **clastix/kamaji** — Kamaji is the Hosted Control Plane Manager for Kubernetes. - Repository: https://github.com/clastix/kamaji - Website: https://kamaji.clastix.io - Stars: 2,051 · Forks: 228 - Language: Go - License: Apache-2.0 - Published: 2026-10-11 · Updated: 2026-10-11 · Language: en - Canonical page: https://hysenlabs.com/projects/clastix-kamaji ## Control planes in Pods, not on dedicated machines: who Kamaji is for Kamaji is a Kubernetes Operator that changes where the control plane of a tenant cluster lives. In a conventional setup, the API server, controller manager and scheduler each require dedicated virtual or physical machines. Kamaji runs those same components as Pods inside an existing management cluster, treating each tenant control plane as a workload that the Kubernetes scheduler places and the Operator continuously reconciles. Platform teams and managed Kubernetes service operators are the primary users. A single management cluster can host multiple TenantControlPlanes, each defined by a CRD, backed by a shared Datastore resource and exposed as a ClusterIP, LoadBalancer or NodePort service. Deleted add-ons are recreated automatically, certificate rotation runs without manual steps, and evicted control plane Pods are rescheduled by the underlying cluster. Two concrete figures set a performance baseline: a TenantControlPlane becomes ready to serve traffic in 16 seconds depending on infrastructure, and a Kubernetes version rollout completes in 10 seconds using a Blue/Green deployment to avoid serving mixed versions during the upgrade. Licensing is Apache-2.0, and the last push was on 2026-10-05. ## TenantControlPlane and Datastore: the two CRDs that define and persist a cluster Installing Kamaji adds two new API groups to the management cluster. TenantControlPlane (short name: tcp) is namespace-scoped and defines the desired state of a Kubernetes control plane. Its spec accepts Kubernetes configuration values alongside Pod-level settings: resource limits and requests, tolerations, node selectors and the service type for API server exposure. Full field documentation is at kamaji.clastix.io/reference/api/#tenantcontrolplane. Datastore is cluster-scoped and holds the backing state for one or more TenantControlPlanes. Separating the stateless definition from the stored state enables multi-tenancy at the Datastore level: several TenantControlPlanes can share one Datastore instance, eliminating the need for a dedicated quorum replica set per cluster. Resource savings reach up to 60% of hardware resources compared to a model where each cluster owns its own storage replicas. Auto-healing follows from this object model. TenantControlPlane objects are tracked continuously, and a deletion triggers idempotent recreation of the control plane components rather than leaving the tenant cluster broken. Datastore itself, which holds the actual cluster data, is not affected by the recreation of the definition object. ## Installing Kamaji: charts/, the docker.io/clastix/kamaji image, and go.mod requirements Container images are published at docker.io/clastix/kamaji, as set in CONTAINER_REPOSITORY in the Makefile. Helm charts sit in the repository's charts/ directory, and manifest-based deployment files are in deploy/. Full installation instructions are at kamaji.clastix.io; the truncated README does not contain installation commands. For building from source, go.mod requires go 1.26.5 and pins k8s.io/kubernetes v1.37.1 as a direct dependency. sigs.k8s.io/controller-runtime v0.25.1 provides the Operator framework, and sigs.k8s.io/gateway-api v1.6.2 is also a direct dependency. ENVTEST_K8S_VERSION in the Makefile is 1.31.0 with ENVTEST_VERSION release-0.19, targeting that Kubernetes API version in the integration test suite. github.com/clastix/kamaji-telemetry v1.0.0 appears as a direct dependency in go.mod; no documentation of what it collects or how to configure it is present in the repository. github.com/prometheus/client_golang v1.24.1 is also a direct dependency alongside prometheus/client_model v0.6.3, indicating a Prometheus metrics endpoint is present, though it is not documented in the repository files provided. ## etcd by default, then MySQL, PostgreSQL and NATS through kine etcd is the default Datastore driver. go.mod lists go.etcd.io/etcd/client/v3 v3.7.0 as a direct dependency. For teams that want to avoid operating an etcd cluster, Kamaji optionally uses kine, the database compatibility shim from the k3s project, which translates the etcd API to a SQL or NATS backend. go.mod lists github.com/go-sql-driver/mysql v1.10.1, github.com/go-pg/pg/v10 v10.15.1 and github.com/nats-io/nats.go v1.54.0 as direct dependencies, covering MySQL, PostgreSQL and NATS. Sharing a Datastore removes the RAFT quorum requirement. Standard etcd clusters require an odd number of replicas for consensus, so three etcd instances per tenant cluster multiplies to a large number of VMs at scale. A single managed MySQL or PostgreSQL instance serving all tenant clusters eliminates that per-cluster overhead, at the cost of making that database a single point of failure for all the clusters it backs. No guidance on Datastore sizing or driver migration appears in the repository files. Those decisions require consulting kamaji.clastix.io. ## kubeadm-managed certificates, automatic CoreDNS remediation, and konnectivity for NAT environments Certificate management uses kubeadm: certificates are created and rotated automatically for each TenantControlPlane. Kamaji also manages three core addons: kube-proxy, CoreDNS and konnectivity. Misconfiguration or manual deletion of the CoreDNS deployment triggers automatic remediation from the Operator, rather than leaving the tenant cluster degraded until a human intervenes. Konnectivity addresses a specific infrastructure constraint: connecting a control plane running inside the management cluster to worker nodes sitting in a different network with no inbound route back to the control plane. Non-routable IP addresses and NAT environments are the named cases. A reverse tunnel from the worker nodes to the control plane lets those workers join without being directly reachable from the management cluster's network. Hybrid configurations supported by this design include hosting the control plane in the cloud with on-premises worker nodes, and running Kubernetes at the edge. All tenant clusters are built with upstream Kubernetes binaries, giving them full CNCF compliance. Workers can join from cloud, edge and data center environments consistently, since the control plane is isolated from the data plane by design. ## When a single cluster makes Kamaji the wrong layer, and how kubeadm compares Kamaji's value appears at the scale of multiple clusters. Resource savings and operational simplifications both presuppose a scenario where the cost of many individual control planes is already a problem. For a single Kubernetes cluster, Kamaji requires a functioning management cluster before the first TenantControlPlane can exist; that management cluster must be provisioned and maintained independently, adding cost and a new failure domain. Kubeadm on dedicated machines is the direct alternative. Each cluster runs its control plane on VMs with no shared management layer above it. This is more expensive per cluster in hardware and operational time, but simpler in architecture: no Operator, no CRD-based abstraction, no shared Datastore and no dependency on a second Kubernetes cluster's health. Kamaji's own framing makes the tradeoff concrete: it exists for operators dealing with the cost of several control planes who want to consolidate them. Strong multi-tenancy is a distinct use case the project names: giving tenant users admin access to their own control plane while keeping them isolated at the infrastructure level, which RBAC on a shared cluster cannot provide. A high-density control plane setup, placing multiple control planes on the same infrastructure instead of one per machine, is another explicit scenario. ## Apache-2.0 licence, CalVer release naming and the ADOPTERS.md file Licensing is Apache-2.0, with a NOTICE file alongside the LICENSE in the repository root. go.mod sets the module path as github.com/clastix/kamaji and requires go 1.26.5. Release names use CalVer: 26.10.2-edge encodes year 26, month 10, patch revision 2. All three recent releases carry the edge suffix: 26.10.2-edge on 2026-10-05, 26.9.5-edge on 2026-09-28 and 26.9.4-edge on 2026-09-21. A weekly cadence is consistent across those three, but edge releases signal pre-stable builds. No stable release channel is described anywhere in the repository. Public adoption is tracked in ADOPTERS.md in the repository root, and it is the concrete file to read during due diligence before adopting Kamaji for a managed Kubernetes service. Case studies from Clastix and partners covering private managed services, Platform-as-a-Service offerings and hybrid cloud scenarios are linked from the project page, though those are external posts rather than in-repository documentation. ## Conclusion Kamaji makes economic sense for platform teams that need to run many Kubernetes clusters and want to avoid the cost of dedicated control plane machines for each one. For a single cluster, it adds management overhead that kubeadm on dedicated VMs does not carry. Before adopting, read ADOPTERS.md for production deployment examples that resemble your scale, confirm the Datastore driver your infrastructure already runs (etcd, MySQL, PostgreSQL or NATS), and check whether the current edge release, 26.10.2-edge as of 2026-10-05, is an acceptable stability level for your environment. ## FAQ ### What is Kamaji in Kubernetes? Kamaji is a Kubernetes Operator that runs tenant cluster control planes as Pods inside a management cluster instead of on dedicated machines. It uses TenantControlPlane and Datastore CRDs to define and persist the state of each cluster. ### Can Kamaji use a database other than etcd? Yes. Kamaji optionally replaces etcd with MySQL, PostgreSQL or NATS through the kine compatibility shim. go.mod lists direct dependencies for all three drivers alongside the etcd client. ### What is a TenantControlPlane in Kamaji? A TenantControlPlane is a namespace-scoped CRD (short name: tcp) that defines the desired state of a Kubernetes control plane. Its spec accepts Kubernetes configuration values and Pod-level settings such as resource limits, tolerations and the service type for API server exposure. ### Does Kamaji handle Kubernetes certificate management automatically? Yes. Kamaji uses kubeadm to create and rotate TLS certificates automatically for each TenantControlPlane. No manual certificate steps are described in the repository. ### What is the Kamaji licence? Kamaji is distributed under the Apache-2.0 licence, with a NOTICE file alongside the LICENSE in the repository root. ## Sources - [clastix/kamaji on GitHub](https://github.com/clastix/kamaji) - [License: Apache-2.0](https://github.com/clastix/kamaji/blob/master/LICENSE) - [Project website](https://kamaji.clastix.io) - [README](https://github.com/clastix/kamaji/blob/master/README.md) - [Releases](https://github.com/clastix/kamaji/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clastix-kamaji