docs(doc-1334): terminology sweep — third-party integrations + anchor fixes

vcluster/introduction/architecture.mdx

@@ -194,4 +194,4 @@ With vCluster Pro, [CoreDNS can be embedded](../configure/vcluster-yaml/control-
 
 #### Communication from the underlying cluster
 
-* **Underlying cluster pod to tenant cluster service** — Pods on the underlying cluster can access services within a tenant cluster by [replicating](../configure/vcluster-yaml/networking/replicate-services.mdx#virtual-cluster-to-host-cluster) tenant cluster services to any namespace on the underlying cluster.
+* **Underlying cluster pod to tenant cluster service** — Pods on the underlying cluster can access services within a tenant cluster by [replicating](../configure/vcluster-yaml/networking/replicate-services.mdx#tenant-cluster-to-control-plane-cluster) tenant cluster services to any namespace on the underlying cluster.

vcluster/third-party-integrations/github-actions/preview-environments.mdx

@@ -11,7 +11,7 @@ import TenancySupport from '../../_fragments/tenancy-support.mdx';
 
 <TenancySupport hostNodes="true" privateNodes="true" />
 
-This guide shows how to use vCluster and GitHub Actions to deploy preview environments for an application on every pull request. This example creates a new virtual cluster for each pull request and deploy ArgoCD into it. It makes use of the sleep mode feature of the platform to make sure the environments are not using any resources if they are unused.
+This guide shows how to use vCluster and GitHub Actions to deploy preview environments for an application on every pull request. This example creates a new tenant cluster for each pull request and deploy ArgoCD into it. It makes use of the sleep mode feature of the platform to make sure the environments are not using any resources if they are unused.
 
 ## Prepare the platform
 
@@ -52,7 +52,7 @@ Next create a new project `preview` to host the preview environments by pressing
 
 ## Create a GitHub deploy action
 
-After having the vCluster project configured correctly, write the actual GitHub workflow that creates the preview environments. On every pull request this action creates a new virtual cluster that hosts the example application (ArgoCD in this case) and can be accessed through an Ingress.
+After having the vCluster project configured correctly, write the actual GitHub workflow that creates the preview environments. On every pull request this action creates a new tenant cluster that hosts the example application (ArgoCD in this case) and can be accessed through an Ingress.
 
 The GitHub workflow looks like this:
 
@@ -113,7 +113,7 @@ jobs:
 
 ## Create a destroy action
 
-Environments must be cleaned up if they are not needed anymore. In order to accomplish this, create a separate workflow to cleanup the virtual cluster created for the preview environment as soon as the pull request is closed or merged:
+Environments must be cleaned up if they are not needed anymore. In order to accomplish this, create a separate workflow to cleanup the tenant cluster created for the preview environment as soon as the pull request is closed or merged:
 
 ```yaml
 name: Destroy Preview Environment

vcluster/third-party-integrations/github-actions/pull-requests.mdx

@@ -26,9 +26,9 @@ GitHub Actions can be created for the following workflows:
 - [Setup DevSpace](https://github.com/loft-sh/setup-devspace): Installs the `DevSpace` CLI
 - [Setup vind](https://github.com/loft-sh/setup-vind): Provisions a Kubernetes cluster via the [Docker driver (vind)](../../configure/vcluster-yaml/experimental/docker.mdx) for [CI testing](../../integrations/setup-vind.mdx)
 
-## Deploy virtual clusters on pull requests
+## Deploy tenant clusters on pull requests
 
-Virtual clusters provide isolated Kubernetes environments for each pull request, enabling:
+Tenant clusters provide isolated Kubernetes environments for each pull request, enabling:
 
 - Parallel testing without resource conflicts between PRs
 - Clean environments that don't accumulate state from previous test runs
@@ -37,7 +37,7 @@ Virtual clusters provide isolated Kubernetes environments for each pull request,
 
 ### Deploy with host nodes
 
-When using [host nodes](../../deploy/worker-nodes/host-nodes/overview.mdx), virtual cluster workloads run on the existing host cluster nodes. This is the simplest setup for CI/CD pipelines.
+When using [host nodes](../../deploy/worker-nodes/host-nodes/overview.mdx), tenant cluster workloads run on the existing control plane cluster nodes. This is the simplest setup for CI/CD pipelines.
 
 <Tabs
     defaultValue="manual"

vcluster/third-party-integrations/pod-identity/aks-workload-identity.mdx

@@ -22,9 +22,9 @@ import TenancySupport from '../../_fragments/tenancy-support.mdx';
 
 [Workload Identity](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview) allows Kubernetes workloads to securely access Azure resources without storing credentials in the cluster. It federates a Kubernetes Service Account with a Microsoft Entra identity, which improves security and simplifies identity management.
 
-To configure Workload Identity in a virtual cluster, you must link the Kubernetes Service Account (KSA) used by your workload with a Microsoft Entra Workload ID. This KSA must exist in the host cluster where the virtual cluster runs. 
+To configure Workload Identity in a tenant cluster, you must link the Kubernetes Service Account (KSA) used by your workload with a Microsoft Entra Workload ID. This KSA must exist in the control plane cluster where the tenant cluster runs. 
 
-Use the [`sync.toHost`](/vcluster/configure/vcluster-yaml/sync/to-host/) feature to expose the KSA to the host cluster.
+Use the [`sync.toHost`](/vcluster/configure/vcluster-yaml/sync/to-host/) feature to expose the KSA to the control plane cluster.
 
 ## Prerequisites
 
@@ -85,9 +85,9 @@ sync:
 
 </Step>
 
-<Step title="Deploy the virtual cluster">
+<Step title="Deploy the tenant cluster">
 
-Run the following command to deploy the virtual cluster:
+Run the following command to deploy the tenant cluster:
 
 ```bash
  vcluster create $VCLUSTER_NAME --namespace $VCLUSTER_NAMESPACE --values vcluster.yaml
@@ -97,7 +97,7 @@ Run the following command to deploy the virtual cluster:
 
 <Step title="Create a service account">
 
-Create a Kubernetes `ServiceAccount` that can be used to interact with the virtual cluster:
+Create a Kubernetes `ServiceAccount` that can be used to interact with the tenant cluster:
 
 ```bash
  cat <<EOF | kubectl apply -f -

vcluster/third-party-integrations/pod-identity/eks-pod-identity.mdx

@@ -31,7 +31,7 @@ This tutorial guides you through the process of integrating AWS Service Accounts
 Setting up Pod Identity requires you to link an AWS Service Account with the Kubernetes Service Account (KSA) used by your workloads.
 This KSA needs to be available in the <GlossaryTerm term="host-cluster">Control Plane Cluster</GlossaryTerm> in which your vCluster instance runs.
 
-To achieve this setup, use the [sync.toHost feature][sync-toHost-docs] to expose the KSA in the host cluster together with the <GlossaryTerm term="platform">platform</GlossaryTerm> API to retrieve the updated name of the KSA in the host cluster.
+To achieve this setup, use the [sync.toHost feature][sync-toHost-docs] to expose the KSA in the control plane cluster together with the <GlossaryTerm term="platform">platform</GlossaryTerm> API to retrieve the updated name of the KSA in the control plane cluster.
 
 ### Prerequisites
 This guide assumes you have the following prerequisites:

vcluster/third-party-integrations/pod-identity/gke-workload-identity.mdx

@@ -24,9 +24,9 @@ import TenancySupport from '../../_fragments/tenancy-support.mdx';
 This tutorial guides you through the process of integrating GCP Service Accounts with your vCluster using Workload Identity.
 
 Setting up Workload Identity requires you to link a GCP Service Account with the Kubernetes Service Account (KSA) used by your workloads.
-This KSA needs to be available in the host cluster in which your vCluster instance runs.
+This KSA needs to be available in the control plane cluster in which your vCluster instance runs.
 
-To achieve this setup, we'll need to use the [sync.toHost feature][sync-toHost-docs] in order to expose the KSA in the host cluster together with the vCluster Platform API to retrieve the updated name of the KSA in the host cluster.
+To achieve this setup, we'll need to use the [sync.toHost feature][sync-toHost-docs] to expose the KSA in the control plane cluster together with the vCluster Platform API to retrieve the updated name of the KSA in the control plane cluster.
 
 ### Prerequisites
 This guide assumes you have the following prerequisites:

vcluster/third-party-integrations/rancher/install-rancher-integration.mdx

@@ -24,7 +24,7 @@ Ensure you have the following before installing the vCluster Rancher Operator:
 - At least one connected downstream cluster where tenant clusters are deployed.
 
 ### Network policies
-If you are using [network policies](../../configure/vcluster-yaml/policies/network-policy.mdx), Rancher Operator traffic into the virtual cluster control plane must be allowed.
+If you are using [network policies](../../configure/vcluster-yaml/policies/network-policy.mdx), Rancher Operator traffic into the tenant cluster control plane must be allowed.
 
 ```yaml title="vcluster.yaml"
 policies:

vcluster/third-party-integrations/scheduler/kai-scheduler.mdx

@@ -24,7 +24,7 @@ NVIDIA KAI scheduler is the open source version of NVIDIA Run:ai's scheduler tec
 
 ## Understand the challenge {#understand-the-challenge}
 
-By default, when syncing workload pods from a vCluster to the host cluster, vCluster sets ownership references on the synced pods. When using custom schedulers like KAI, this causes issues because:
+By default, when syncing workload pods from a vCluster to the control plane cluster, vCluster sets ownership references on the synced pods. When using custom schedulers like KAI, this causes issues because:
 
 - KAI's pod-grouper controller watches for pods with `schedulerName: kai-scheduler`
 - The pod-grouper controller traverses the owner references to group related pods
@@ -47,7 +47,7 @@ experimental:
 # highlight-end
 ```
 
-This configuration prevents owner reference traversal issues by not setting them on synced pods. The KAI scheduler's pod-grouper controller automatically creates PodGroup resources in the host cluster.
+This configuration prevents owner reference traversal issues by not setting them on synced pods. The KAI scheduler's pod-grouper controller automatically creates PodGroup resources in the control plane cluster.
 
 Apply this configuration when creating or updating your vCluster:
 
@@ -196,14 +196,14 @@ The KAI scheduler's pod-grouper component is a controller that:
 - Groups related pods for optimal scheduling decisions
 - Applies custom scheduling logic based on workload type
 
-When vCluster syncs pods to the host cluster, it sets an owner reference to the vCluster service by default. By disabling this with `setOwner: false`, the pod-grouper can process the pods normally without needing to follow service references.
+When vCluster syncs pods to the control plane cluster, it sets an owner reference to the vCluster service by default. By disabling this with `setOwner: false`, the pod-grouper can process the pods normally without needing to follow service references.
 
 ## Limitations and considerations {#limitations-and-considerations}
 
 - The `experimental.syncSettings.setOwner: false` configuration is marked as experimental and may change in future vCluster releases
 - If you have other features that rely on pod ownership in vCluster, disabling owner references may affect those features
 - The KAI scheduler might require additional configuration for advanced features like GPU sharing and queue management
-- For GPU workloads, ensure that the host cluster has the necessary GPU drivers and device plugins installed
+- For GPU workloads, ensure that the control plane cluster has the necessary GPU drivers and device plugins installed
 
 ## Troubleshoot common issues {#troubleshooting}
 

vcluster_versioned_docs/version-0.34.0/introduction/architecture.mdx

@@ -194,4 +194,4 @@ With vCluster Pro, [CoreDNS can be embedded](../configure/vcluster-yaml/control-
 
 #### Communication from the underlying cluster
 
-* **Underlying cluster pod to tenant cluster service** — Pods on the underlying cluster can access services within a tenant cluster by [replicating](../configure/vcluster-yaml/networking/replicate-services.mdx#virtual-cluster-to-host-cluster) tenant cluster services to any namespace on the underlying cluster.
+* **Underlying cluster pod to tenant cluster service** — Pods on the underlying cluster can access services within a tenant cluster by [replicating](../configure/vcluster-yaml/networking/replicate-services.mdx#tenant-cluster-to-control-plane-cluster) tenant cluster services to any namespace on the underlying cluster.