Quickstart
From a fresh host to your first cluster
What you need before you start
KubeCell needs one small management cluster and at least one physical host. Both run K3s and must be able to pull the images in your release bundle.
- A management cluster (single-node K3s) with admin access and outbound network access.
- One or more host machines prepared with the platform baseline: kernel drivers, firmware, LVM volume groups, and preloaded images.
- A KubeCell release bundle from the releases page: the manifests and images for one tested version, with digests included.
- A label on each host node describing what the machine offers, for example
hardware.kubecell.io/profile=ascend-910b, plus the storage topology labels your platform team provides.
KubeCell is pre-release software. Run the quickstart in a lab environment, not in production.
# Point at the management cluster (hub) and the host clusterexport KUBECONFIG_HUB=~/.kube/hub.yamlexport KUBECONFIG_HOST=~/.kube/host.yaml# Verify the pinned versions in the bundle before anything elsels kubecell-release/manifests | headRun the read-only preflight
doctor is read-only by default and stops at the first failure. Fix everything it reports before you continue; the installer refuses to guess.
go run ./cmd/kubecell-installer doctor management --bundle ./kubecell-releasego run ./cmd/kubecell-installer doctor host \ --bundle ./kubecell-release \ --device huawei.com/Ascend910Install the management plane
CRDs first, then the hub that connects your hosts, then the KubeCell controller. The installer stays read-only unless you pass both --apply and --confirm.
kubectl apply-f kubecell-release/manifests/crdsgo run ./cmd/kubecell-installer management \ --bundle ./kubecell-release --apply --confirm# The management chart bundles the optional Kite dashboard# (kite.enabled, on by default) for viewing Cell and VirtualCluster CRs.helm list-n kubecell-systemOnboard the host in four commands
Join, approve by hand, install the host chart, and generate the Cell from live discovery. The manual approval is a deliberate safety gate: the installer never auto-approves a ManagedCluster.
# 1. join (run against the host cluster)KUBECONFIG=$KUBECONFIG_HOST clusteradm join \ --hub-token "$(clusteradm get token)" \ --hub-apiserver https://hub.example.com:6443 \ --cluster-name cell1 --wait# 2. accept (run against the management cluster)KUBECONFIG=$KUBECONFIG_HUB clusteradm accept --clusters cell1 --wait# 3. host chartkubectl create ns kubecell-systemhelm install kubecell-host ./charts/kubecell-host \ --namespace kubecell-system \ --set image.repository=<controller-repo> --set image.tag=<tag># 4. Cell, generated from live discoverygo run ./cmd/kubecell-installer host --step=cell --cell cell1 \ --kubeconfig $KUBECONFIG_HOST | grep -v '^#' > cell.yamlkubectl apply-n kubecell-system -f cell.yamlDraft a quota tier
suggest-class derives a tier from observed allocatable capacity. Adjust the numbers down to the tenant envelope you are comfortable with, then apply.
go run ./cmd/kubecell-installer suggest-class \ --cell-file cell.yaml --name ascend-910bkubectl apply-f virtualnodeclass.yamlkubectl-n kubecell-system get cell cell1 -o widePlan, then create the child cluster
Create a VirtualClusterPlan with identical content first. Wait for status.decision=Accepted, then create the VirtualCluster. When it reaches phase=Ready, fetch the admin kubeconfig Secret.
kubectl apply-f virtualcluster-plan.yamlkubectl-n kubecell-system get vcp child-dev-plan \ -o jsonpath='{.status.decision}{"\n"}'kubectl apply-f virtualcluster.yamlkubectl-n kubecell-system wait --for=condition=Ready \ vc/child-dev --timeout=20m# Export the admin kubeconfig (mode 600)kubectl-n kubecell-system get secret \ kubecell-child-dev-<uid>-admin-kubeconfig \ -o jsonpath='{.data.kubeconfig\.yaml}' | base64 -d > child-dev.yamlchmod600 child-dev.yamlkubectl--kubeconfig child-dev.yaml get nodesNext steps
Now that a cluster exists
The interesting part is day two: keeping tenants honest, wiring ingress, and reclaiming storage.