diff --git a/.github/styles/config/vocabularies/Loft/accept.txt b/.github/styles/config/vocabularies/Loft/accept.txt index 3e969ee0ab..5cfb431d53 100644 --- a/.github/styles/config/vocabularies/Loft/accept.txt +++ b/.github/styles/config/vocabularies/Loft/accept.txt @@ -1,6 +1,7 @@ [aA]dmin Alpine ArgoCD +Crossplane AWS [aA]pplication BareMetalHost[s]? diff --git a/README.md b/README.md index 799315bdbd..ea707c7534 100644 --- a/README.md +++ b/README.md @@ -51,6 +51,19 @@ Content locations: - vcluster: vCluster content - platform: vCluster Platform content +Shared content uses two folder conventions (goal — not yet fully enforced): + +- `_partials/`: intended for auto-generated content. Do not hand-edit generated files — changes will be overwritten on the next generation run. +- `_fragments/`: manually written content shared across multiple pages. Safe to edit directly. + +In practice, most `_partials/` content (e.g. all of `platform/_partials/`) is hand-maintained and safe to edit. The directories that are actually auto-generated are: + +- `vcluster/_partials/config/` — vCluster config reference, generated by `hack/vcluster/partials/main.go` +- `platform/api/_partials/resources/` — Platform API reference, generated by `hack/platform/partials/main.go` +- `vcluster_versioned_docs/version-X.Y.Z/cli/` — CLI command docs, generated by `hack/vcluster-cli/main.go` + +When in doubt, check `git log` on the file before editing. + ### Generate new vCluster version ```bash diff --git a/platform/_partials/install/install-next-steps.mdx b/platform/_partials/install/install-next-steps.mdx index f14308ccfc..cf1c08e980 100644 --- a/platform/_partials/install/install-next-steps.mdx +++ b/platform/_partials/install/install-next-steps.mdx @@ -10,7 +10,7 @@ clusters](../../use-platform/virtual-clusters/create/create-no-template.mdx) sec Otherwise, read more about some primary concepts: * [Projects](../../understand/what-are-projects.mdx) - How resources can be grouped together into different projects. -* [Tenant clusters](../../introduction/platform_intro.mdx) - How Platform deploys and manages tenant clusters. +* [Tenant clusters](../../introduction/vcluster_intro.mdx) - What tenant clusters are and how Platform manages them. * [Templates](../../understand/what-are-templates.mdx) - How to use templates to control what type of resources that can be made. * [Connected clusters](../../understand/what-are-clusters.mdx) - How to connect Control Plane Clusters to the platform. * [Auto sleep and wakeup](/vcluster/manage/sleep-wakeup) - How to temporarily scale down unused virtual clusters and bring them back up. diff --git a/platform/introduction/vcluster_intro.mdx b/platform/introduction/vcluster_intro.mdx index f3324d5ab2..30dfe9131e 100644 --- a/platform/introduction/vcluster_intro.mdx +++ b/platform/introduction/vcluster_intro.mdx @@ -6,8 +6,33 @@ description: Introduction to vCluster tenant clusters hide_table_of_contents: false --- -vCluster provisions fully isolated Kubernetes environments, called tenant clusters, on your infrastructure. Each tenant gets a dedicated API server, its own CRDs and RBAC, and a cluster experience indistinguishable from a dedicated Kubernetes cluster. +import GlossaryTerm from '@site/src/components/GlossaryTerm'; -vCluster Platform is the management layer on top: it handles deployment, access control, lifecycle, and governance across your tenant cluster fleet. +vCluster provisions fully isolated Kubernetes environments, called tenant clusters, on your existing infrastructure. Each tenant cluster has a dedicated API server, its own RBAC and CRDs, and a cluster experience indistinguishable from a dedicated Kubernetes cluster. Tenant clusters do not require dedicated physical nodes. -For the full vCluster architecture and deployment path guide, see the [vCluster documentation](/docs/vcluster/introduction/what-are-virtual-clusters). +## What a tenant cluster looks like + +From the perspective of a user or workload, a tenant cluster is a full Kubernetes cluster. They receive a `kubeconfig` scoped to their cluster and interact with it using any conformant tool: `kubectl`, Helm, Argo CD, `Crossplane`, and others. They cannot see or reach other tenant clusters or the underlying Control Plane Cluster. + +From the platform operator's perspective, the tenant cluster control plane runs as a pod in a namespace on the Control Plane Cluster. Creating one requires no additional infrastructure. + +## Isolation model + +Each tenant cluster enforces isolation at the API level. Tenants get their own API server, their own etcd, and their own resource namespace. A resource created inside one tenant cluster has no visibility into another. CRDs, admission webhooks, and RBAC policies scope fully to each tenant and cannot affect other tenants or the host. + +For workloads that require node-level isolation (GPU infrastructure, regulated industries, or paying external customers), tenant clusters support [private nodes](/docs/vcluster/deploy/worker-nodes/private-nodes/) where each tenant's workloads run on dedicated compute with no cross-tenant visibility at the infrastructure level. + +## How Platform manages tenant clusters + +vCluster Platform is the management layer for your tenant cluster fleet. It handles: + +- **Provisioning** — create tenant clusters from the UI, CLI, or API, with optional templates that enforce configuration baselines +- **Access control** — RBAC at the platform, project, and individual cluster level; SSO integration with any OIDC provider +- **Lifecycle** — sleep, wake, auto-delete, and version upgrades coordinated across the fleet +- **Multi-cluster** — manage tenant clusters across multiple Control Plane Clusters from a single Platform instance + +[Learn how Platform works →](./platform_intro.mdx) + +## Learn more + +For the full architecture, deployment options, and feature reference, see the [vCluster documentation](/docs/vcluster/introduction/what-are-virtual-clusters).