Kubernetes Namespace Isolation Beyond Namespace Boundaries
Go beyond namespace boundaries for customer Kubernetes. vMetal supplies infrastructure, and vCluster separates tenant APIs while Private Nodes dedicate worker capacity to each tenant.
Go beyond namespace boundaries for customer Kubernetes. vMetal supplies infrastructure, and vCluster separates tenant APIs while Private Nodes dedicate worker capacity to each tenant.
Tenants sharing a Kubernetes cluster still depend on common cluster-wide resources and administrative policies.
A misbehaving tenant can destabilize other workloads. Namespace boundaries do not prevent cluster-wide failures from spreading.
Tenants can observe platform internals, cluster-wide agents and other tenants' nodes. Namespaces weren't designed to hide any of that.
Cluster-admin access can change cluster-wide resources. Namespace boundaries alone do not give each customer an independent administrative scope.
Namespaces divide resources within one Kubernetes API. vCluster supplies independent tenant APIs and data stores; Private Nodes dedicate workers. vMetal manages machines, avoiding separate control-plane servers for each tenant. Lintasarta runs 170+ tenant clusters in production.
Provide separate tenant APIs, dedicated worker capacity and tenant-owned networking and storage configuration without dedicated control-plane machines per customer.
Each tenant has an independent Kubernetes API, data store and RBAC boundary. Lightweight control-plane hosting reduces dedicated server requirements for customer Kubernetes administration; Private Nodes keep production workers tenant-specific.

Give tenants cluster-admin within their own Kubernetes environment for customer Kubernetes administration. They manage CRDs, operators and RBAC there, while platform administrators retain control of tenant provisioning, infrastructure access and fleet policies.

vNode uses Linux user namespaces and seccomp to restrict workload privileges and system calls. It adds runtime hardening for customer Kubernetes administration without a guest kernel or hypervisor, complementing dedicated workers rather than allocating GPUs.

Private Nodes dedicate worker capacity to one tenant cluster, with its own CNI and storage configuration. For customer Kubernetes administration, select physical servers or VMs according to the required infrastructure boundary.

Every tenant cluster is a conformant, CNCF-certified Kubernetes control plane with standard Kubernetes APIs. Tenants get real Kubernetes, not a namespace partition or a proprietary abstraction.

This isn’t a side project. Behind every vCluster deployment is 5+ years of deep K8s engineering, security hardening, and battle-tested infrastructure work at massive scale.
Talk to our team about your stack
Deploy vCluster on your infra in minutes
Go live with a hyperscaler-grade tenant experience in days
Kubernetes namespaces share a single control plane, so all tenants share the same API server, data store and cluster-wide resources. A misconfigured or malicious tenant can affect others through RBAC escalation, CRD conflicts or resource exhaustion. Namespaces are a logical partition with no kernel boundary between them. For compliance-sensitive or high-density GPU environments, a shared control plane is a structural risk that namespace-level policies can only partly address.
vCluster gives each tenant an independent Kubernetes API, data store and RBAC scope. Private Nodes dedicate worker capacity to that tenant, including its own CNI and storage configuration. vMetal orchestrates the machines underneath. This separates tenant administration and worker placement; shared infrastructure, application permissions and network policies still require an explicit security design.
Yes. Because each tenant has its own control plane, it gets cluster-admin rights within its tenant cluster. Tenants can install CRDs, deploy operators and configure RBAC without conflicting with other tenants or exposing platform internals. This is one of the most common failure points with namespace isolation, where CRD conflicts across tenants are a routine operational problem.
Dedicated Private Nodes remove cross-tenant workload placement from those workers. Bare metal avoids a hypervisor layer, but this is not a throughput or latency guarantee. GPU drivers, workload configuration, network fabrics and storage can still influence performance. vNode adds runtime hardening using the Linux kernel; benchmark the selected stack against the workload and service levels you intend to offer.
vCluster is a CNCF-certified Kubernetes distribution and exposes standard Kubernetes APIs in tenant environments. This supports familiar clients, Helm charts and cluster-scoped resources such as CRDs. Certification covers Kubernetes conformance rather than an entire AI platform or customer deployment. Validate the selected version, networking, storage, GPU drivers and runtime integrations for the workloads you plan to support.
Private Nodes, the recommended production model, give each tenant dedicated hardware with its own CNI and CSI. Control plane isolation can be extended to VM-level separation when you need OS-level boundaries. vNode helps prevent container breakout and limits blast radius, and hardware network isolation (VLANs, VXLANs, VRFs) comes through the Netris integration.
Go beyond namespace isolation with dedicated control planes for every tenant.