Single-Tenant Per Customer
Give each enterprise customer their own complete cluster stack. Dedicated nodes, an isolated tenant cluster, and full cluster-admin access if you choose to offer it. Your platform team handles provisioning and lifecycle. Customers see only their own environment.
Customer access model: External enterprise customers, optionally with cluster-admin on their own tenant cluster. Worker-node model: Private nodes per customer. See Choose a worker node model.
Typical stack: Platform + private nodes per customer. vMetal optional for physical server fleets. vNode for customers requiring privileged workload support.
What makes this path different: Each customer is fully isolated at the node level. Customers may have cluster-admin rights to their own cluster while remaining invisible to each other and to the platform layer. This path is closely related to the AI Cloud path. The main distinction is whether your customers consume Kubernetes directly (this path) or through your own product API (AI Cloud).
Day 0: Design decisions​
| Decision | Read next | Outcome |
|---|---|---|
| Define per-customer node allocation | Private Nodes, Auto Nodes | Each customer cluster maps to a dedicated node pool. Auto Nodes provisions and reclaims nodes as customers are added or removed. |
| Define the default network policy posture | Network policy | Set a default-deny east-west posture per customer template and confirm the control plane cluster's CNI enforces it. Some CNIs accept NetworkPolicy objects without enforcing them. |
| Choose the GPU scheduling model | DeviceClasses, DRA ResourceClaims | Device-plugin-style DeviceClass sync covers simple, whole-GPU allocation. DRA ResourceClaim sync (Pro) supports fine-grained and shared GPU allocation, relevant if customers get cluster-admin access to schedule their own workloads. |
| Plan tenant storage | Storage classes from host, CSI storage capacities | Decide which storage classes each customer can request, and whether to sync host CSIStorageCapacity for scheduler-aware placement. |
| Plan provisioning automation | Templates, Terraform | Customer cluster creation is triggered by your CRM or provisioning system, not by manual Platform operations. |
| Define offboarding and node reclaim | Manage private nodes, vMetal docs | Document how nodes are reclaimed and reimaged when a customer offboards. |
| Plan security hardening and audit logging | Security baseline, CIS hardening guide, Platform audit logging | Apply a CIS benchmark baseline to the control plane cluster and decide audit log retention and SIEM integration, especially where customers hold cluster-admin access to their own cluster. |
Day 1: Stand up the first customer cluster​
- Install vCluster Platform.
- Configure Auto Nodes or vMetal for automated node provisioning and reclaim.
- Create a per-customer cluster template with private nodes, backing store, and HA.
- Apply a default-deny network policy in the template and confirm the control plane cluster's CNI enforces it.
- Configure per-customer storage classes in the template.
- Configure GPU scheduling: sync DeviceClasses for device-plugin allocation, or enable DRA ResourceClaim sync for fine-grained allocation.
- Apply the CIS hardening baseline to the control plane cluster and enable Platform audit logging.
- Wire provisioning automation to Platform using Terraform, CLI, or API.
- Validate the full customer lifecycle: provision, validate isolation, access as cluster-admin, offboard, and verify node reclaim.
Day 2: Operate​
| Operation | Read next |
|---|---|
| Add and remove customers | Auto Nodes, provisioning automation |
| Back up and restore per-customer | Snapshots, restore |
| Upgrade customer clusters | Upgrade vCluster |
| Track GPU utilization and faults for metering and troubleshooting | GPU observability templates, NVSentinel GPU observability |
| Review audit logs and security posture | Platform audit logging, security baseline |