Internal Kubernetes Platform
Provide isolated Kubernetes environments for internal engineering teams, business units, and the services they own. Clusters are long-running and may carry internal production traffic. Tenant isolationTenant IsolationThe capability to host multiple separate users, teams, or workloads on the same infrastructure while providing strong isolation between them. vCluster delivers tenant isolation through dedicated control planes, isolated resource namespaces, and optional private nodes per tenant. gives each team its own control plane and prevents noisy-neighbor effects across teams. Shared nodes avoid standing up separate infrastructure per team.
Large enterprises use this model to replace shared cluster namespaces with stronger tenant isolation. Each team gets their own control planeControl PlaneThe container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. In vCluster, each tenant cluster has its own control plane components., their own RBAC, and their own view of Kubernetes, without owning the infrastructure underneath.
Shared nodes are a supported, common model for trusted tenants. They give each tenant control-plane, API, and namespace isolation, but tenant workloads share the same kernel and physical nodes. They aren't a security boundary for untrusted tenants with Kubernetes access or arbitrary workload execution. Good fits are development, testing, CI/CD, and internal engineering teams.
Use private nodes for external, resale, regulated, or otherwise untrusted tenant offerings, optionally with vNode for runtime isolation.
NetworkPolicy is an added isolation layer worth enabling even for trusted tenants. vCluster can create the policies for you through policies.networkPolicy, and your control plane cluster's CNI enforces them. Confirm your CNI supports enforcement, since some accept NetworkPolicy resources without acting on them. See the security baseline.
If you accept shared nodes for a trusted-tenant use case, follow the shared-node hardening guide as the required next step.
This path targets your own internal teams and services. If tenants are external customers or you're reselling access, follow the AI Cloud or Single-Tenant Per Customer paths, which use private nodes.
Customer access model: Internal, trusted engineering teams with Kubernetes access to their own tenant clusterTenant clusterA fully isolated Kubernetes environment provisioned for a single tenant. Each tenant cluster has its own API server, controller manager, and resource namespace, backed by a virtualized control plane hosted on a control plane cluster. From the tenant's perspective it behaves exactly like a standard Kubernetes cluster.. Worker-node model: Shared nodes, trusted internal tenants only.
Typical stack: Platform on an existing Kubernetes cluster. Shared node pool with optional dedicated node pools for teams with elevated security or performance requirements.
What makes this path different: These clusters are long-lived and may host internal production services, not just dev workloads. Governance, isolation, and uptime are the priorities. If you also need ephemeral CI clusters, that is the CI/CD Platform path.
Day 0: Design decisions​
| Decision | Read next | Outcome |
|---|---|---|
| Define the tenancy model | Projects, templates | Decide whether teams get one cluster per team, one per project, or on-demand. Set a default template enforced across all teams. |
| Define access and governance model | SSO, RBAC, network policy | Map your identity provider to Platform roles. Define which teams can create clusters, how many, and with what resource limits. |
| Define resource quotas | Quotas, resource quota | Set per-team cluster count, CPU, and memory limits. Prevent runaway consumption without requiring ops approval for every cluster. |
| Plan sync configuration | Sync configuration | Decide which control plane cluster resources (storage classes, ingress controllers, secrets) are visible inside tenant clusters. |
| Define uptime requirements | HA, backing store | Determine if tenant clusters need HA control planes. Most internal platforms start single-replica and graduate to HA as adoption grows. |
Day 1: Stand up the platform​
- Install vCluster Platform on your existing Kubernetes cluster.
- Configure SSO and team permissions.
- Create projects aligned to your org structure (team, BU, or environment).
- Define templates that enforce your baseline: pod security standard, network policy, resource quota, and sync configuration.
- Apply quotas per project to cap resource consumption.
- Enable monitoring for the Platform layer and expose cluster-level metrics to Platform's fleet view.
- Validate self-service and isolation. A team lead creates a cluster, deploys a workload, and verifies that another team's project is not visible. Confirm the control plane cluster's CNI enforces NetworkPolicy. With
sync.toHost.networkPoliciesenabled, apply a default-deny policy in a tenant namespace and confirm the blocked connection is refused. If traffic still flows, shared-node network isolation isn't in effect. See the security baseline.
Day 2: Operate​
| Operation | Read next |
|---|---|
| Monitor cluster health and resource usage across teams | Fleet Observability, other architectures |
| Manage cluster lifecycle and upgrades | Upgrade vCluster, upgrade Platform |
| Respond to quota violations or runaway clusters | Quotas, resource quota |
| Back up and restore tenant clusters | Snapshots, restore |
| Rotate certificates | Certificate rotation |