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. Shared nodes keep operational overhead low while tenant isolation prevents noisy-neighbor effects across teams.
Large enterprises use this model to replace shared cluster namespaces with stronger tenant isolation. Each team gets their own control plane, their own RBAC, and their own view of Kubernetes, without owning the infrastructure underneath.
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: a team lead creates a cluster, deploys a workload, and verifies that another team's project is not visible.
Day 2: Operate​
| Operation | Read next |
|---|---|
| Monitor cluster health and resource usage across teams | Fleet monitoring, monitoring overview |
| 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 |