diff --git a/platform_versioned_docs/version-4.9.0/how-to/exposing-vCluster-platform-with-Istio.mdx b/platform_versioned_docs/version-4.9.0/how-to/exposing-vCluster-platform-with-Istio.mdx
index c2becbf4f..90fc34d35 100644
--- a/platform_versioned_docs/version-4.9.0/how-to/exposing-vCluster-platform-with-Istio.mdx
+++ b/platform_versioned_docs/version-4.9.0/how-to/exposing-vCluster-platform-with-Istio.mdx
@@ -22,7 +22,7 @@ Before exposing the platform with Istio, ensure you have:
## Install Istio {#install-istio}
-Install Istio on your platform host cluster:
+Install Istio on your platform control plane cluster:
```bash title="Install Istio on your cluster"
istioctl install
@@ -86,7 +86,7 @@ For more information about setting up TLS certificates, see the [Istio Secure Ga
## Enable Tailscale connectivity {#enable-tailscale-connectivity}
-For external virtual clusters or platform agents on connected clusters to communicate with the platform, apply this `EnvoyFilter`:
+For external tenant clusters or platform agents on connected clusters to communicate with the platform, apply this `EnvoyFilter`:
```yaml title="Apply EnvoyFilter for Tailscale connectivity"
apiVersion: networking.istio.io/v1alpha3
diff --git a/platform_versioned_docs/version-4.9.0/how-to/gitops-end-to-end.mdx b/platform_versioned_docs/version-4.9.0/how-to/gitops-end-to-end.mdx
index d47c1ddae..b18f28460 100644
--- a/platform_versioned_docs/version-4.9.0/how-to/gitops-end-to-end.mdx
+++ b/platform_versioned_docs/version-4.9.0/how-to/gitops-end-to-end.mdx
@@ -2,12 +2,12 @@
title: End-to-end GitOps with ArgoCD
sidebar_label: GitOps End-to-End
sidebar_position: 1
-description: Complete guide to managing vCluster Platform and virtual clusters with ArgoCD, from platform installation to virtual cluster deployment.
+description: Complete guide to managing vCluster Platform and tenant clusters with ArgoCD, from platform installation to tenant cluster deployment.
---
import InterpolatedCodeBlock from "@site/src/components/InterpolatedCodeBlock";
-This guide walks through the full lifecycle of managing platform resources with ArgoCD, covering platform installation, cluster connections, project creation, and virtual cluster deployment. Each section references the detailed documentation for that step and provides the ArgoCD-specific configuration needed.
+This guide walks through the full lifecycle of managing platform resources with ArgoCD, covering platform installation, cluster connections, project creation, and tenant cluster deployment. Each section references the detailed documentation for that step and provides the ArgoCD-specific configuration needed.
:::info
While this guide uses ArgoCD as the example, the same principles apply to other GitOps tools like Flux. Each section links to detailed documentation that includes tabs for alternative tooling.
@@ -79,9 +79,9 @@ ArgoCD does not deploy the Helm release secret. Platform configuration updates m
For the full set of Helm configuration options and alternative installation methods, see the [platform installation with ArgoCD guide](../install/gitops.mdx).
-## 2. Connect a host cluster
+## 2. Connect a control plane cluster
-After the platform is running, connect host clusters where virtual clusters will be deployed. In a GitOps workflow, you can manage connected clusters as Kubernetes resources alongside your platform installation.
+After the platform is running, connect control plane clusters where tenant clusters will be deployed. In a GitOps workflow, you can manage connected clusters as Kubernetes resources alongside your platform installation.
Each connected cluster requires two resources: a Cluster object and a Secret containing the cluster credentials.
@@ -181,7 +181,7 @@ For interactive setup methods using the UI or CLI, see the [connect a cluster gu
## 3. Create a project
-Projects organize virtual clusters and control access, templates, and quotas. In a GitOps workflow, define projects as Project custom resources.
+Projects organize tenant clusters and control access, templates, and quotas. In a GitOps workflow, define projects as Project custom resources.
`. The platform uses this convention to associate virtual clusters with projects.
+The namespace follows the pattern `loft-p-`. The platform uses this convention to associate tenant clusters with projects.
:::
### Option B: Deploy with Helm chart directly
-Deploy the vCluster Helm chart through an ArgoCD Application. This approach gives you direct control over the Helm release but does not provide platform lifecycle features unless you [register the virtual cluster afterward](../use-platform/virtual-clusters/add-virtual-clusters.mdx).
+Deploy the vCluster Helm chart through an ArgoCD Application. This approach gives you direct control over the Helm release but does not provide platform lifecycle features unless you [register the tenant cluster afterward](../use-platform/virtual-clusters/add-virtual-clusters.mdx).
Enable Argo CD Integration slider, select either{" "}
Clusters or
- Virtual Clusters from the dropdown box in the
+ Tenant Clusters from the dropdown box in the
Where is Argo CD running
dropdown. This tells vCluster Platform if your Argo CD instance lives
in a connected physical cluster, or if it is running inside of a virtual
@@ -92,7 +92,7 @@ under the 'Project Settings' button.
In the next drop down to the right, select the name of the cluster or
- virtual cluster that your Argo CD instance is deployed in.
+ tenant cluster that your Argo CD instance is deployed in.
If your Argo CD instance is deployed in a namespace other than `argocd`,
@@ -123,7 +123,7 @@ under the 'Project Settings' button.
In the new configurations that appeared under the{" "}
Enable Argo CD Integration slider, select either{" "}
Clusters or
- Virtual Clusters from the dropdown box in the
+ Tenant Clusters from the dropdown box in the
Where is Argo CD running
dropdown. This tells vCluster Platform if your Argo CD instance lives
in a connected physical cluster, or if it is running inside of a virtual
@@ -131,7 +131,7 @@ under the 'Project Settings' button.
In the next drop down to the right, select the name of the cluster or
- virtual cluster that your Argo CD instance is deployed in.
+ tenant cluster that your Argo CD instance is deployed in.
If your Argo CD instance is deployed in a namespace other than `argocd`,
@@ -146,7 +146,7 @@ under the 'Project Settings' button.
:::warning Disabling Argo CD Integration
-Upon disabling of Argo integration at the project, all virtual clusters will be removed from Argo
+Upon disabling of Argo integration at the project, all tenant clusters will be removed from Argo
CD, so be careful when disabling Argo CD at the project level.
:::
@@ -186,7 +186,7 @@ configured via with the Helm values, or in the `Admin` section of the UI on the
In the new configurations that appeared under the{" "}
Enable Argo CD Integration slider, select either{" "}
Clusters or
- Virtual Clusters from the dropdown box in the
+ Tenant Clusters from the dropdown box in the
Where is Argo CD running
dropdown. This tells vCluster Platform if your Argo CD instance lives
in a connected physical cluster, or if it is running inside of a virtual
@@ -194,7 +194,7 @@ configured via with the Helm values, or in the `Admin` section of the UI on the
In the next drop down to the right, select the name of the cluster or
- virtual cluster that your Argo CD instance is deployed in.
+ tenant cluster that your Argo CD instance is deployed in.
If your Argo CD instance is deployed in a namespace other than `argocd`,
@@ -259,25 +259,25 @@ App Project integration, can be enabled by editing a project manifest and settin
provide metadata fields to apply the Argo CD App Project object, Argo CD RBAC roles to apply,
and an array of permissible source repositories that may be accessed within the project.
-## Virtual Cluster Integration
+## Tenant cluster integration
-### Enable Virtual Cluster Import
+### Enable tenant cluster import
-Once a project has Argo CD enabled, virtual clusters within that project are eligible to be
-synced to the Argo instance as available clusters. You can enable virtual cluster import into
-Argo CD during the virtual cluster creation step, or by enabling this feature on existing
-virtual clusters.
+Once a project has Argo CD enabled, tenant clusters within that project are eligible to be
+synced to the Argo instance as available clusters. You can enable tenant cluster import into
+Argo CD during the tenant cluster creation step, or by enabling this feature on existing
+tenant clusters.
:::info Make Sure Your Project Has Argo CD Enabled.
-If the project your virtual cluster resides in does _not_ have Argo CD integration enabled, you
+If the project your tenant cluster resides in does _not_ have Argo CD integration enabled, you
will not see the Argo CD import option!
:::
@@ -286,16 +286,16 @@ will not see the Argo CD import option!
Select the project you intend to enable Argo CD from from the projects dropdown at the top of the left navigation bar.
- Click on Virtual Clusters and the{" "}
- New Virtual Cluster button.
+ Click on Tenant Clusters and the{" "}
+ New Tenant Cluster button.
- In the popup, optionally select the virtual cluster template, then click
+ In the popup, optionally select the tenant cluster template, then click
the
Create button.
- Find your desired virtual cluster in the virtual cluster list. Slide the
+ Find your desired tenant cluster in the tenant cluster list. Slide the
ArgoCD slider to enabled.
@@ -306,7 +306,7 @@ will not see the Argo CD import option!
Select the project you intend to enable Argo CD from from the projects dropdown at the top of the left navigation bar.
- Find your desired virtual cluster in the virtual cluster list. Slide the
+ Find your desired tenant cluster in the tenant cluster list. Slide the
ArgoCD slider to enabled.
@@ -314,13 +314,13 @@ will not see the Argo CD import option!
:::warning Integration Errors
-If there are any errors adding your virtual cluster to Argo CD, the virtual cluster status will
+If there are any errors adding your tenant cluster to Argo CD, the tenant cluster status will
show a warning, clicking on the warning will give you a message indicating the cause of the issues.
:::
## Disable the Argo CD Integration
-The Argo CD integration can be disabled on a per virtual cluster or per project level by toggling the same sliders
-used to enable it. Disabling the integration at the virtual cluster level simply removes it as a registered cluster
-in Argo CD. Disabling the integration at the project level removes all virtual clusters from Argo CD, so be careful
+The Argo CD integration can be disabled on a per tenant cluster or per project level by toggling the same sliders
+used to enable it. Disabling the integration at the tenant cluster level simply removes it as a registered cluster
+in Argo CD. Disabling the integration at the project level removes all tenant clusters from Argo CD, so be careful
when disabled Argo at this level.
diff --git a/platform_versioned_docs/version-4.9.0/integrations/gitlab-ci.mdx b/platform_versioned_docs/version-4.9.0/integrations/gitlab-ci.mdx
index c37742c5e..c4211c727 100644
--- a/platform_versioned_docs/version-4.9.0/integrations/gitlab-ci.mdx
+++ b/platform_versioned_docs/version-4.9.0/integrations/gitlab-ci.mdx
@@ -8,9 +8,9 @@ When using vCluster Platform with GitLab you can use the
official image `ghcr.io/loft-sh/vcluster-cli` as either a base image or
directly. If additional tooling is needed for your CI/CD process, a custom image can be created.
-## Virtual Clusters for Merge Requests
+## Tenant clusters for merge requests
-This example shows how to create and delete a Virtual Cluster for running end-to-end tests for
+This example shows how to create and delete a Tenant Cluster for running end-to-end tests for
the default branch and merge requests. It assumes you have configured CI/CD variables `VCLUSTER_PRO_URL`,
`VCLUSTER_PRO_ACCESS_KEY`, and `VCLUSTER_PRO_PROJECT`.
@@ -55,15 +55,15 @@ or add the `--namespace` flag to the `vcluster platform create` command.
2. The `before_script` first logs in to vCluster Platform using the `$VCLUSTER_PRO_URL` and `$VCLUSTER_PRO_ACCESS_KEY`
variables that you defined in GitLab.
[See the GitLab docs for more information](https://docs.gitlab.com/ee/ci/variables/)
-3. The `before_script` then creates a virtual cluster using
+3. The `before_script` then creates a tenant cluster using
[predefined GitLab variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
- to create a unique name. Optionally, the `--upgrade` flag can be used to reuse an existing virtual cluster instead of creating a new one.
+ to create a unique name. Optionally, the `--upgrade` flag can be used to reuse an existing tenant cluster instead of creating a new one.
4. Next `before_script` installs some additional tooling needed to run the end-to-end tests. For
more complex scenarios creating a custom image is recommended.
5. Then the `script` section uses `kubectl` to deploy the application to the space and waits for
the `my-app` deployment to become ready. `make` is then used to run an end-to-end test suite.
-6. Finally `after_script` deletes the virtual cluster, and passes `--delete-namespace` to ensure the
- corresponding namespace for the virtual cluster is deleted. By using `after_script` we can ensure the virtual cluster
- is deleted even if the tests fail. You may wish to skip this step if reusing the virtual cluster with the `--upgrade` flag when creating the virtual cluster.
+6. Finally `after_script` deletes the tenant cluster, and passes `--delete-namespace` to ensure the
+ corresponding namespace for the tenant cluster is deleted. By using `after_script` we can ensure the tenant cluster
+ is deleted even if the tests fail. You may wish to skip this step if reusing the tenant cluster with the `--upgrade` flag when creating the tenant cluster.
diff --git a/platform_versioned_docs/version-4.9.0/integrations/karpenter.mdx b/platform_versioned_docs/version-4.9.0/integrations/karpenter.mdx
index 7d1080a61..6215ae4b3 100644
--- a/platform_versioned_docs/version-4.9.0/integrations/karpenter.mdx
+++ b/platform_versioned_docs/version-4.9.0/integrations/karpenter.mdx
@@ -13,7 +13,7 @@ further reduce infrastructure costs.
This article will explain how to [Create Designated Node Pool for a vCluster's Workload Pods](#create-designated-node-pool-for-a-vclusters-workload-pods), [Create Designated Node Pool for a Project](#create-designated-node-pool-for-a-project), and [Target Node Pool Based on vCluster Pod Labels](#target-node-pool-based-on-vcluster-pod-labels). All
three of which can be powerful cost saving tools.
-This article assumes you are using a host cluster provisioned on one of the following managed Kubernetes services: EKS (Elastic Kubernetes Service) or AKS (Azure Kubernetes Service).
+This article assumes you are using a control plane cluster provisioned on one of the following managed Kubernetes services: EKS (Elastic Kubernetes Service) or AKS (Azure Kubernetes Service).
The pattern `` repeatedly occurs in this documentation and is meant to imply that the user should replace the value, angular brackets included, with their own.
@@ -21,7 +21,7 @@ Much of this article borrows and builds upon the [Getting Started with Karpenter
### Pre-requisites
1. Either an [EKS Kubernetes cluster](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter) or an [AKS Kubernetes cluster](https://github.com/Azure/karpenter-provider-azure).
-2. vCluster Platform installed on host cluster. Read [Deploy the vCluster Platform docs](https://www.vcluster.com/docs/platform/install/quick-start-guide#2-deploy-the-vcluster-platform).
+2. vCluster Platform installed on control plane cluster. Read [Deploy the vCluster Platform docs](https://www.vcluster.com/docs/platform/install/quick-start-guide#2-deploy-the-vcluster-platform).
3. EKS specific requirements for vCluster Platform compatibility:
1. EBS driver installed. [Get the Amazon EBS CSI driver add-on](https://docs.aws.amazon.com/eks/latest/userguide/managing-ebs-csi.html#adding-ebs-csi-eks-add-on).
2. Delete the gp2 StorageClass with `kubectl delete storageclass gp2` and replace with gp3 by applying following yaml:
@@ -154,9 +154,9 @@ kubectl logs -f -n "kube-system" -l app.kubernetes.io/name=karpenter -c controll
-## Configure Host Cluster Kubernetes RBAC permissions
+## Configure control plane cluster Kubernetes RBAC permissions
-To deploy the manifests presented in the remainder of this article you will need certain permissions in the Kubernetes host cluster. The following Kubernetes permissions will be required in the host cluster for the user:
+To deploy the manifests presented in the remainder of this article you will need certain permissions in the Kubernetes control plane cluster. The following Kubernetes permissions will be required in the control plane cluster for the user:
- * Create `NodePools.karpenter.sh/v1beta1` in host cluster.
- * Create `EC2NodeClass.karpenter.sh/v1beta1` in host cluster.
+ * Create `NodePools.karpenter.sh/v1beta1` in control plane cluster.
+ * Create `EC2NodeClass.karpenter.sh/v1beta1` in control plane cluster.
- * Create `NodePools.karpenter.sh/v1beta1` in host cluster.
- * Create `AKSNodeClass.karpenter.sh/v1beta1` in host cluster.
+ * Create `NodePools.karpenter.sh/v1beta1` in control plane cluster.
+ * Create `AKSNodeClass.karpenter.sh/v1beta1` in control plane cluster.
@@ -182,13 +182,13 @@ To deploy the manifests presented in the remainder of this article you will need
vCluster Platform Permissions
The following permissions will be required in vCluster Platform:
- * Create virtual clusters
+ * Create tenant clusters
Create Node Pool
-This section utilizes taints and tolerations to guide virtual cluster pods to the desired node. This works best if every node pool or node utilizes a taint. Otherwise, the pods may be scheduled on non-tainted nodes.
-1. Select "Create Virtual Cluster"
-2. Select "Configure" and add a toleration to virtual cluster pods using the yaml editor. If the below yaml is out of date then see the [applying tolerations docs](https://www.vcluster.com/docs/v0.19/architecture/scheduling#automatically-applying-tolerations-to-all-pods-synced-by-vcluster).
+This section utilizes taints and tolerations to guide tenant cluster pods to the desired node. This works best if every node pool or node utilizes a taint. Otherwise, the pods may be scheduled on non-tainted nodes.
+1. Select "Create Tenant Cluster"
+2. Select "Configure" and add a toleration to tenant cluster pods using the yaml editor. If the below yaml is out of date then see the [applying tolerations docs](https://www.vcluster.com/docs/v0.19/architecture/scheduling#automatically-applying-tolerations-to-all-pods-synced-by-vcluster).
```yaml
sync:
@@ -368,7 +368,7 @@ The following permissions will be required in vCluster Platform:
Create Node Pool
-1. Using the vCluster Platform add a template: Templates -> Virtual Clusters -> Add Virtual Cluster Template.
+1. Using the vCluster Platform add a template: Templates -> Tenant Clusters -> Add Tenant Cluster Template.
2. In the yaml editor box, which contains the vcluster.yaml, add the following:
```yaml
sync:
@@ -497,14 +497,14 @@ EOF
-4. Create a new project that only allows templates with set tolerations. Go to project dropdown and create a new project. In the Allowed Templates section, remove the All Templates option. Select the templates that include tolerations for the node pool created in step 3. Now, all pods created in virtual clusters belonging to this project will deploy to the designated node pools.
+4. Create a new project that only allows templates with set tolerations. Go to project dropdown and create a new project. In the Allowed Templates section, remove the All Templates option. Select the templates that include tolerations for the node pool created in step 3. Now, all pods created in tenant clusters belonging to this project will deploy to the designated node pools.
### Target Node Pool Based on vCluster Pod Labels
vCluster Platform Permissions
The following permissions will be required in vCluster Platform:
- * Create virtual clusters
+ * Create tenant clusters
Create Node Pool
@@ -624,9 +624,9 @@ EOF
-2. Create a virtual cluster.
+2. Create a tenant cluster.
-3. Add nodeSelector to deployments in your virtual cluster using a nodeSelector that targets the label from step 1 with the desired value.
+3. Add nodeSelector to deployments in your tenant cluster using a nodeSelector that targets the label from step 1 with the desired value.
```bash
cat <
- Click the New Virtual Cluster button above the list of tenant clusters
+ Click the New Tenant Cluster button above the list of tenant clusters
[Optional] select the cluster in which to create the tenant
@@ -70,7 +70,7 @@ This feature is only configurable from the UI for tenant clusters created withou
Finish configuring anything else on your tenant cluster,
then click
- Create Virtual Cluster .
+ Create Tenant Cluster .
diff --git a/platform_versioned_docs/version-4.9.0/maintenance/uninstall.mdx b/platform_versioned_docs/version-4.9.0/maintenance/uninstall.mdx
index 6941c302c..369463ea7 100644
--- a/platform_versioned_docs/version-4.9.0/maintenance/uninstall.mdx
+++ b/platform_versioned_docs/version-4.9.0/maintenance/uninstall.mdx
@@ -34,7 +34,7 @@ There are two ways to uninstall the platform.
Note that the
[VirtualClusterInstances](/docs/platform/api/resources/virtualclusterinstance)
-CRDs managed with driver Helm are deleted, but the underlying virtual clusters
+CRDs managed with driver Helm are deleted, but the underlying tenant clusters
are not uninstalled.
On the Kubernetes cluster where the platform is installed, and all connected clusters, run:
diff --git a/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/migrate-to-hostcluster.mdx b/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/migrate-to-hostcluster.mdx
index 7ec2024a5..4485c2b06 100644
--- a/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/migrate-to-hostcluster.mdx
+++ b/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/migrate-to-hostcluster.mdx
@@ -35,11 +35,11 @@ Review the following factors before migrating. These scenarios require a differe
- **Automated deployment tools**
If the platform is managed by an automated deployment tool such as `ArgoCD`, migration must be coordinated with GitOps workflows. Changes to cluster configuration must be reflected in the repository before deployment. Skipping this step can lead to drift between the declared and actual state of the platform.
-- **Virtual cluster dependencies**
- If the platform has virtual cluster instances running on the same Kubernetes host cluster, these instances do not migrate automatically. They require a separate migration process after the platform has been moved. Migrating only the platform without considering virtual clusters can cause service disruptions and dependency issues.
+- **Tenant cluster dependencies**
+ If the platform has tenant cluster instances running on the same Kubernetes control plane cluster, these instances do not migrate automatically. They require a separate migration process after the platform has been moved. Migrating only the platform without considering tenant clusters can cause service disruptions and dependency issues.
-- **Virtual cluster agent on the destination cluster**
- If the destination Kubernetes cluster has a virtual cluster agent, it must be decommissioned before migration. The agent can interfere with the new platform installation, potentially leading to scheduling conflicts and unexpected behavior.
+- **Tenant cluster agent on the destination cluster**
+ If the destination Kubernetes cluster has a tenant cluster agent, it must be decommissioned before migration. The agent can interfere with the new platform installation, potentially leading to scheduling conflicts and unexpected behavior.
Not addressing these considerations before migration can lead to DNS misconfigurations, deployment failures, and conflicts with existing workloads.
@@ -53,7 +53,7 @@ Not addressing these considerations before migration can lead to DNS misconfigur
- Ensure at least 1 GB of available storage space for the backup.
- Confirm that you have access to DNS management for the platform's domain.
-- Only one platform instance can run in a single Kubernetes cluster. Do not install the platform more than once in the same host cluster.
+- Only one platform instance can run in a single Kubernetes cluster. Do not install the platform more than once in the same control plane cluster.
- Plan for 15–30 minutes of downtime during the migration process. Communicate this downtime to end users in advance.
- Use the same platform version for both the source and destination installations. Migration does not support version changes.
@@ -86,7 +86,7 @@ Send downtime communication to end users.
-Optional: Stop `ArgoCD` sync of any virtual clusters.
+Optional: Stop `ArgoCD` sync of any tenant clusters.
@@ -156,7 +156,7 @@ When using the original cluster as a connected cluster, connect it to the new pl
Log in to the platform UI and verify object presence:
- Check for all expected projects.
- Verify user access and permissions.
- - Confirm virtual cluster listings.
+ - Confirm tenant cluster listings.
Verify license status in the platform UI:
@@ -173,8 +173,8 @@ kubectl rollout restart deployment loft -n vcluster-platform
Validate the core capabilities of the platform:
- Single sign-on: Test logging in with all configured providers.
- - Log access: Verify log retrieval from multiple virtual clusters.
- - Virtual cluster creation: Create a test cluster.
+ - Log access: Verify log retrieval from multiple tenant clusters.
+ - Tenant cluster creation: Create a test cluster.
- Auto sleep: Test the sleep/wake feature.
diff --git a/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/upgrade.mdx b/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/upgrade.mdx
index 188d3527c..8192fd032 100644
--- a/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/upgrade.mdx
+++ b/platform_versioned_docs/version-4.9.0/maintenance/upgrade-migrate/upgrade.mdx
@@ -32,15 +32,15 @@ Review the [older upgrade docs](https://loft.sh/docs/admin/upgrade-loft) on how
1. Read through the v4.0 release notes. Review the [release notes for v4.0](https://github.com/loft-sh/loft-enterprise/releases/tag/v4.0.0) to read the updates in the release and understand any behavior changes.
-2. vCluster versions are required on virtual clusters and virtual cluster templates One of the breaking changes in v4.0 is the requirement of a vCluster version defined on your virtual cluster. Previously if you deployed a vCluster version or used a vCluster version without editing the version field, the version was not set in the `spec` of the resource. With each upgrade of the Platform,
-the vCluster would automatically upgrade these virtual clusters to the latest default vCluster version. Due to the [breaking changes introduced in v0.20](https://roadmap.vcluster.com/changelog/vcluster-v020-ga),
-automatic upgrades of vCluster version are no longer supported and a vCluster version must be set in the spec of a virtual cluster or virtual cluster template.
+2. vCluster versions are required on tenant clusters and tenant cluster templates One of the breaking changes in v4.0 is the requirement of a vCluster version defined on your tenant cluster. Previously if you deployed a vCluster version or used a vCluster version without editing the version field, the version was not set in the `spec` of the resource. With each upgrade of the Platform,
+the vCluster would automatically upgrade these tenant clusters to the latest default vCluster version. Due to the [breaking changes introduced in v0.20](https://roadmap.vcluster.com/changelog/vcluster-v020-ga),
+automatic upgrades of vCluster version are no longer supported and a vCluster version must be set in the spec of a tenant cluster or tenant cluster template.
- Confirm that the resource yaml includes the versions of your virtual clusters and virtual cluster templates before upgrading.
- Otherwise, your virtual clusters might encounter errors that require you to define these versions after the upgrade.
+ Confirm that the resource yaml includes the versions of your tenant clusters and tenant cluster templates before upgrading.
+ Otherwise, your tenant clusters might encounter errors that require you to define these versions after the upgrade.
Because it is not known which version you upgraded from, it cannot set the correct version automatically, and you must manually determine and set it.
-3. Define the vCluster version on existing virtual clusters. In the UI, for each virtual cluster, edit the configuration and type the version of the virtual cluster or virtual cluster template in the textbox and the resource yaml automatically updates the spec to include the version. If the resource yaml of your virtual cluster or virtual cluster template has `spec.template.helmRelease.chart.version` set, then the virtual cluster version is defined.
+3. Define the vCluster version on existing tenant clusters. In the UI, for each tenant cluster, edit the configuration and type the version of the tenant cluster or tenant cluster template in the textbox and the resource yaml automatically updates the spec to include the version. If the resource yaml of your tenant cluster or tenant cluster template has `spec.template.helmRelease.chart.version` set, then the tenant cluster version is defined.
```yaml title="Example of spec"
spec:
template: