Introduction
What tenantplane is, who it's for, and the principles behind it.
tenantplane is a lightweight, inspectable control plane for managing virtual Kubernetes tenants. It gives platform engineering teams multi-tenancy where synchronization, isolation, and day-2 operations stay predictable and explainable.
The problem
As Kubernetes adoption grows, platform teams need to hand out cluster-like environments to many teams, CI pipelines, and preview deployments — without running a full cluster for each one. Existing virtual-cluster approaches work, but they often become hard to operate: the host view and the tenant view drift, isolation is implicit, and nobody can answer why a particular host object exists.
The approach
tenantplane treats the two hardest parts of multi-tenancy — synchronization and isolation — as first-class, visible subsystems.
- Each tenant runs a small k3s control plane inside a host namespace, provisioned and reconciled by the tenantplane controller.
- A SyncPolicy declares which resources cross the virtual-to-host boundary. The sync engine maps every tenant object to a deterministic host object and records a decision for each action.
- An IsolationProfile composes NetworkPolicy, ResourceQuota, LimitRange, and Pod Security into one explicit boundary.
Who it’s for
- Platform teams building internal developer platforms.
- CI/CD and preview-environment systems that need high-density, ephemeral tenant clusters.
- Anyone who has to answer audit questions about what runs where and why.
Coming from vcluster, Kamaji, or Capsule and wondering how tenantplane differs? See Why tenantplane — it uses the per-tenant control-plane pattern as an implementation detail and builds a distinct, explainability-first product on top.
Design principles
- Every synchronization decision should be explainable.
- Every isolation boundary should be explicit.
- Platform operations should remain transparent.
- The host cluster should always remain understandable and observable.
- Tenant environments should evolve as isolation requirements change.
Project status
tenantplane is in early development. Today the controller provisions a shared-mode control plane, applies isolation, extracts a tenant kubeconfig, and runs host-ward resource sync with decisions surfaced as Kubernetes Events. See the Roadmap for what’s next, and expect pre-1.0 APIs to change.
Found a gap? Open an issue or PR.