Give every developer
their own Kubernetes cluster
AI research teams
Each developer gets an isolated cluster on the hardware you already own: standard kubectl, a real control plane, persistent storage, and hard CPU, memory, and GPU quotas. No VM per person, no shared namespace everyone has to trust.
apiVersion: kubecell.io/v1alpha1kind: VirtualClustermetadata: name: child-dev namespace: kubecell-systemspec: cellRef: {name: cell1} classRef: {name: ascend-910b}- VMs to manage
- 0
- lines to create a cluster
- 0
- from apply to first Ready
- 0 min
- standard kubectl, Helm, and CI
- 0%
VMs to manage
lines to create a cluster
from apply to first Ready
standard kubectl, Helm, and CI
Standard Kubernetes tooling, no new workflow to learn
Why KubeCell
Platform-grade isolation without a platform rewrite
Four resources to learn, one management plane to operate, and the Kubernetes workflow your team already knows.
Real clusters, not namespaces
Every developer gets their own API server, so they can install CRDs, operators, and webhooks without stepping on anyone else.
Know it will fit before you create it
A dry-run request tells you whether CPU, memory, GPUs, and storage are available — and exactly what is missing when they are not. Nothing is created until you are ready.
Grow by picking a bigger tier
Each cluster presents one node sized by the quota tier you choose. Need more CPU, memory, or another GPU? Move to the next tier instead of learning a new scaling model.
Isolation you can audit
Quotas, network policy, and blocked privileged workloads are enforced on the host — visible in the same Kubernetes objects you already know.
Manifests you can read in a minute
You write which host to use and how much CPU, memory, and GPU you need. Versions, ports, and security defaults are handled for you.
Tested versions, predictable upgrades
KubeCell pins the versions it validates and reports drift in resource status, so upgrades are a deliberate step — not a surprise on a Monday morning.
How it works
Four commands to a running cluster
Humans run four commands. KubeCell handles the rest: what to install, which versions, and how to keep every host consistent.
Check before you change anything
A read-only preflight inspects both clusters and stops at the first problem. Nothing is modified until you pass --apply and --confirm.
Add your host
Register the machine and approve it manually — a deliberate safety gate, so a new host can never join silently.
Let KubeCell prepare the host
Storage, ingress, and accelerator support are installed at tested versions. You do not assemble the stack yourself.
Create the developer cluster
Pick the host and a quota tier, apply an eight-line manifest, and collect the kubeconfig from the resource status.
The first cluster usually takes 10–20 minutes while container images are pulled onto the host. Clusters created afterwards start much faster.
✓ host reachable and healthy✓ machine profile detected: ascend-910b✓ storage available: 2.1 TiB✓ accelerators detected: 8 × Ascend 910B→ host cell1 registered and waiting for approval→ preflight: accepted (cpu, memory, 2 × Ascend 910B, storage)✓ cluster child-dev is ReadyNAME STATUS ROLES AGE VERSIONkubelet Ready <none> 42s v1.34.2+k3s1Architecture
One management plane, many isolated clusters
You apply manifests to a single management cluster. KubeCell turns them into changes on the host, then hands back an endpoint and a kubeconfig.
Your manifests
host, quota, cluster
KubeCell
one management cluster
Host setup + cluster creation
applied on the host
Your host
runs the workloads
Your cluster
kubectl + kubeconfig
Isolation model
Isolation is enforced on the host, not promised in a README
Every cluster runs in its own space on the host with real Kubernetes guardrails. Nothing depends on developers behaving well.
A dedicated namespace per cluster
Your workloads run in their own namespace on the host, with quotas, defaults, and network rules attached to it.
Hard CPU, memory, and GPU limits
Quotas come from the tier you pick and are enforced by Kubernetes itself, not by convention or a dashboard.
Private by default
Clusters cannot reach each other's services unless you explicitly allow it.
Unsafe workloads are blocked
Privileged containers and hostPath volumes are rejected before they reach a host, with a hint about what to use instead.
Nothing changes behind your back
Every host-side change is a declarative manifest applied through one management plane, so you can see and review what happened.
Whole GPUs, never shared
Accelerators are allocated as whole cards: your cluster gets the card, or it does not. No oversubscription between tenants.
Trade-offs
Not namespaces. Not a VM per developer.
KubeCell sits between the two familiar extremes: real cluster semantics per developer, sharing the hardware underneath.
| Aspect | Shared namespaces | VM per developer | KubeCell |
|---|---|---|---|
| API surface | Shared API server, shared cluster-wide resources | Own API, heavy per-VM control plane | Own K3s API server per developer cluster |
| Isolation | Namespaces and RBAC only; shared kernel | Strong VM boundary, high fixed cost | Dedicated namespace, hard quota, network policy |
| Accelerators | Shared allocation, hard to reason about | GPU passthrough per VM, limited density | Whole cards per cluster, never shared |
| Density and cost | High density, weak boundaries | Low density, duplicated control planes | Shared hosts, isolated control planes |
| Day-2 operations | One cluster to upgrade | Thousands of VMs to patch | One management plane to operate |
The manifests
Three small files stand between a host and a developer
A Cell describes one physical host and what it offers. A VirtualNodeClass is a quota tier. A VirtualCluster is eight lines.
apiVersion: kubecell.io/v1alpha1kind: Cellmetadata: name: cell1 namespace: kubecell-systemspec: managedClusterRef: name: cell1 machineProfile: name: ascend-910b devices: - name: ascend resourceName: huawei.com/Ascend910Not sure a request will fit? Create the Plan first: it checks capacity without creating anything, tells you exactly which resource is missing, and never blocks a later change.
Tested versions
Versions that are validated together
KubeCell pins and verifies the components each release supports, and reports any drift in resource status — so upgrades are a decision, not a surprise.
| Component | Version | What it does for you |
|---|---|---|
| Management cluster | Single-node K3s | Holds your manifests and reports state; runs no tenant workloads. |
| Host Kubernetes | K3s v1.36.3+k3s1 | Validated on ARM64 bare metal. |
| K3k | v1.2.0 | Creates and manages the per-developer control planes on each host. |
| Cluster Kubernetes | v1.34.2+k3s1 | The version your developers see and target with kubectl. |
| OCM Hub | v1.3.1 | The audited channel between the management cluster and hosts. |
| Storage | TopoLVM on hosts | Persistent volumes for clusters, backed by local disks on the host. |
Use cases
One operator, five shapes of shared hardware
If a team needs a real Kubernetes API and the hardware lives on shared bare metal, KubeCell is the seam between them.
Accelerator sandboxes
Give each researcher their own cluster with two dedicated Ascend 910B cards — no partitioning tricks, no shared queue.
Read the scenarioEphemeral test environments
Create a cluster per pull request or integration run, hand over the kubeconfig, then delete it and let KubeCell clean up the host.
Read the scenarioWorkshops and training
Forty students, one physical host, forty clusters. Credentials are easy to hand out, and quotas stop one busy cluster from ruining the class.
Read the scenarioEdge and field labs
Hosts live where the hardware is. They connect outbound to one management plane, so there is no inbound tunnel to maintain per site.
Read the scenarioSelf-service for platform teams
Publish hosts and quota tiers once; teams self-serve clusters inside the limits you defined, with capacity visible to everyone.
Read the scenarioFAQ
Questions engineers ask first
Design trade-offs worth knowing before you install anything.
More questions answered in the full FAQ.
Give every developer a real cluster
Start with the read-only preflight. Nothing is created until you explicitly confirm, so the first command you run is always safe.
go run ./cmd/kubecell-installer doctor management --bundle ./kubecell-release