docs(doc-1410): terminology — platform/administer/ batch 1

Replace "virtual cluster(s)" → "tenant cluster(s)" and "host cluster" →
"control plane cluster" across all 28 files in platform/administer/.
Also fixes two broken anchors created by heading renames:
- iam_database.mdx → database#use-tenant-cluster-with-shared-database
- how-to/use-go-template.mdx → parameters#connected-control-plane-cluster-parameter-values

Code blocks, inline code, Kubernetes API type names (VirtualCluster,
VirtualClusterInstance, virtualclusterinstances), and import lines are
unchanged.

Closes DOC-1410

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: djwfyi

platform/administer/authentication/access-keys.mdx

@@ -25,7 +25,7 @@ The platform supports limiting access key permissions by scoping them to specifi
 
 A single project within the platform, limiting actions to only that project's resources.
 
-A particular virtual cluster, constraining operations to just that virtual cluster's components.
+A particular tenant cluster, constraining operations to just that tenant cluster's components.
 
 A specific namespace, allowing actions only within that defined namespace boundary.
 
@@ -35,13 +35,13 @@ Scoping provides an important security control by restricting what an access key
 
 When implementing access keys in automated workflows, consider using scoped keys to improve security by limiting access to only the required resources.
 
-For example, an automated deployment process typically needs access to just one project or virtual cluster. By scoping the access key appropriately, you protect other resources in case the key is compromised.
+For example, an automated deployment process typically needs access to just one project or tenant cluster. By scoping the access key appropriately, you protect other resources in case the key is compromised.
 
 ## Example use cases
 
 CI/CD integration often requires access to platform resources. You can create project-scoped access keys for build pipelines to enable automated building and deployment while limiting potential security exposure.
 
-Automated deployment tools can use virtual cluster-scoped keys to manage deployments without gaining unnecessary access to other parts of your infrastructure.
+Automated deployment tools can use tenant cluster-scoped keys to manage deployments without gaining unnecessary access to other parts of your infrastructure.
 
 Monitoring applications need to gather metrics and status information. Configure namespace-scoped keys for these systems to allow monitoring without granting broader permissions.
 
@@ -79,7 +79,7 @@ Apply the principle of least privilege by using the most restrictive scope possi
     <b>Optional</b> If you'd like to limit the scope of the Access Key, expand
     the
     <Label>Limit Access Key Scope</Label> configuration section. In this section
-    you can select the clusters, namespaces, and virtual clusters of which to
+    you can select the clusters, namespaces, and tenant clusters of which to
     limit the Access Key scope to.
   </Step>
   <Step>
@@ -135,7 +135,7 @@ Replace the following placeholders:
 
 Save the modified template as `my-kube-config.yaml`. 
 
-You can access your virtual cluster using the newly created kube config file:
+You can access your tenant cluster using the newly created kube config file:
 
 ```bash
 KUBECONFIG=my-kube-config.yaml kubectl get users

platform/administer/bare-metal/overview.mdx

@@ -8,7 +8,7 @@ import FeatureTable from '@site/src/components/FeatureTable';
 
 <FeatureTable names="metal3" />
 
-vCluster Platform integrates [Metal3](https://metal3.io/) and [Ironic](https://ironicbaremetal.org/) for bare metal server lifecycle management. Physical servers are represented as `BareMetalHost` resources on a host cluster. The platform manages their detection, provisioning, configuration, and decommissioning for reuse.
+vCluster Platform integrates [Metal3](https://metal3.io/) and [Ironic](https://ironicbaremetal.org/) for bare metal server lifecycle management. Physical servers are represented as `BareMetalHost` resources on a control plane cluster. The platform manages their detection, provisioning, configuration, and decommissioning for reuse.
 
 ## When to use bare metal
 
@@ -21,12 +21,12 @@ Bare metal servers are a good fit when workloads need direct hardware access or
 
 ## Prerequisites
 
-Before managing bare metal servers, you need a [Metal3 node provider](../node-providers/metal3.mdx) configured on a host cluster.
+Before managing bare metal servers, you need a [Metal3 node provider](../node-providers/metal3.mdx) configured on a control plane cluster.
 The node provider can deploy Metal3, Ironic, and a DHCP server automatically, or you can install them yourself.
 
 ## Add servers
 
-Bare metal servers are added by creating `BareMetalHost` resources on the host cluster, either through the platform UI or by applying them directly with kubectl. Each BareMetalHost represents a physical server and requires BMC (Baseboard Management Controller) configuration for out-of-band management.
+Bare metal servers are added by creating `BareMetalHost` resources on the control plane cluster, either through the platform UI or by applying them directly with kubectl. Each BareMetalHost represents a physical server and requires BMC (Baseboard Management Controller) configuration for out-of-band management.
 
 ### BMC configuration
 

platform/administer/clusters/advanced/external-database/deploy.mdx

@@ -64,7 +64,7 @@ across failure domains.
 ### Install the Amazon EBS CSI driver
 
 The EBS CSI driver is required for dynamic provisioning of persistent volumes
-on EKS. Without it, virtual cluster StatefulSet pods remain in `Pending` state
+on EKS. Without it, tenant cluster StatefulSet pods remain in `Pending` state
 because the `gp2` storage class cannot provision volumes.
 
 <InterpolatedCodeBlock
@@ -76,7 +76,7 @@ because the `gp2` storage class cannot provision volumes.
   language="bash"
 />
 
-For more details on EKS prerequisites for running virtual clusters, see the
+For more details on EKS prerequisites for running tenant clusters, see the
 [EKS environment setup guide](/docs/vcluster/deploy/control-plane/kubernetes-pod/environment/eks).
 
 ### Note the EKS VPC ID and CIDR
@@ -538,7 +538,7 @@ configuration. Unlike multi-region, no `multiRegion` block is needed — only
 Create a values file (`platform-ha-values.yaml`):
 
 <InterpolatedCodeBlock
-  code={"admin:\n  email: [[VAR:ADMIN_EMAIL:admin@example.com]]\n\nreplicaCount: 3\n\nconfig:\n  loftHost: [[GLOBAL:PLATFORM_DOMAIN]]\n  database:\n    enabled: true\n    dataSource: \"mysql://kine@tcp([[VAR:DATABASE_URL:mariadb-ha-platform.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com]]:3306)/kine\"\n    identityProvider: \"aws\"\n    extraArgs:\n      - --datastore-max-open-connections=20\n      # Set to 0 because IAM auth tokens expire, making idle connections stale.\n      - --datastore-max-idle-connections=0\n\n  # Cost control requires the embedded single-region database and is not\n  # compatible with the external Kine backend.\n  costControl:\n    enabled: false\n\n# Run multiple agent replicas for resilience on the connected host cluster.\nagentValues:\n  replicaCount: 3"}
+  code={"admin:\n  email: [[VAR:ADMIN_EMAIL:admin@example.com]]\n\nreplicaCount: 3\n\nconfig:\n  loftHost: [[GLOBAL:PLATFORM_DOMAIN]]\n  database:\n    enabled: true\n    dataSource: \"mysql://kine@tcp([[VAR:DATABASE_URL:mariadb-ha-platform.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com]]:3306)/kine\"\n    identityProvider: \"aws\"\n    extraArgs:\n      - --datastore-max-open-connections=20\n      # Set to 0 because IAM auth tokens expire, making idle connections stale.\n      - --datastore-max-idle-connections=0\n\n  # Cost control requires the embedded single-region database and is not\n  # compatible with the external Kine backend.\n  costControl:\n    enabled: false\n\n# Run multiple agent replicas for resilience on the connected control plane cluster.\nagentValues:\n  replicaCount: 3"}
   language="yaml"
 />
 

platform/administer/clusters/advanced/external-database/external-database.mdx

@@ -28,7 +28,7 @@ Consider an external database deployment when you need one or more of the follow
 - **Control plane resilience**: If the platform pod or its node goes down,
   another replica takes over leadership automatically. Connected clusters
   continue operating through the surviving replicas.
-- **Strict RBAC environments**: Run the platform on a host cluster with
+- **Strict RBAC environments**: Run the platform on a control plane cluster with
   limited permissions, similar to
   [Least Privilege Mode](../../../../configure/agent-settings/least-privilege-mode.mdx)
   for agents. An external database lets the platform replicas use a shared

platform/administer/clusters/advanced/ingress-suffix.mdx

@@ -11,9 +11,9 @@ import Label from "@site/src/components/Label";
 import Input from "@site/src/components/Input";
 import Expander from "@site/src/components/Expander";
 
-As outlined in the 'Virtual Clusters -> Advanced Topics -> Ingress Access' section, you can enable the 'AccessPoint' feature to access a virtual cluster API server directly by avoiding the vCluster Platform proxy. This requires a valid ingress controller to be present on the host cluster and a valid domain to be set in the `loft.sh/ingress-suffix` annotation on the Cluster Object.
+As outlined in the 'Tenant Clusters -> Advanced Topics -> Ingress Access' section, you can enable the 'AccessPoint' feature to access a tenant cluster API server directly by avoiding the vCluster Platform proxy. This requires a valid ingress controller to be present on the control plane cluster and a valid domain to be set in the `loft.sh/ingress-suffix` annotation on the Cluster Object.
 
-Once this is done, vCluster Platform creates a connection to the virtual cluster through an ingress instead of the default vCluster Platform proxy. This can be useful, if you want to handout the virtual cluster kubeconfig to users that do not belong to vCluster Platform.
+Once this is done, vCluster Platform creates a connection to the tenant cluster through an ingress instead of the default vCluster Platform proxy. This can be useful, if you want to handout the tenant cluster kubeconfig to users that do not belong to vCluster Platform.
 
 The ingress name URL is calculated in the following way:
 
@@ -34,7 +34,7 @@ You can set the required ingress suffix in the vCluster Platform UI:
   <Step>
     In the drawer that appears from the right, click the{" "}
     <Label>Direct Access</Label> configuration pane. Provide the desired domain
-    under the <Label>Virtual Cluster Ingress Suffix</Label> field.
+    under the <Label>Tenant Cluster Ingress Suffix</Label> field.
   </Step>
   <Step>
     Click on the <Button>Save Changes</Button> button.

platform/administer/clusters/advanced/multi-region.mdx

@@ -148,7 +148,7 @@ eksctl create cluster \
 #### Install the Amazon EBS CSI driver
 
 The EBS CSI driver is required for dynamic provisioning of persistent volumes
-on EKS. Without it, virtual cluster StatefulSet pods remain in `Pending` state
+on EKS. Without it, tenant cluster StatefulSet pods remain in `Pending` state
 because the `gp2` storage class cannot provision volumes.
 
 Install the driver as an EKS managed add-on on **each** cluster:
@@ -163,7 +163,7 @@ eksctl create addon --name aws-ebs-csi-driver \
   --region eu-west-1
 ```
 
-For more details on EKS prerequisites for running virtual clusters, see the
+For more details on EKS prerequisites for running tenant clusters, see the
 [EKS environment setup guide](/docs/vcluster/next/deploy/control-plane/kubernetes-pod/environment/eks).
 
 ### Step 2 - Install AWS load balancer controller

platform/administer/clusters/advanced/networking.mdx

@@ -28,24 +28,24 @@ In private GKE clusters, Kubernetes control plane and worker nodes might reside
 
 ### Connect vCluster to the platform
 
-When vCluster and the platform are in the same host cluster, the platform exposes an in‑cluster Service that targets port `10443` on the platform pods, so vCluster in the same host cluster talk to the 
+When vCluster and the platform are in the same control plane cluster, the platform exposes an in‑cluster Service that targets port `10443` on the platform pods, so vCluster in the same control plane cluster talk to the 
 platform via that `ClusterIP` Service. You should allow egress from the vCluster namespace to platform pods on TCP port `10443`.
 
-When vCluster and the platform are in different host clusters, vCluster uses the `loftHost` value (your platform's load balancer or Ingress DNS) to establish a Tailscale-backed tunnel for API traffic.
+When vCluster and the platform are in different control plane clusters, vCluster uses the `loftHost` value (your platform's load balancer or Ingress DNS) to establish a Tailscale-backed tunnel for API traffic.
 You shoud allow egress traffic from vCluster pods to the `lostHost` domain and the egress traffic from platform agent to `loftHost`, if it participates in the handshake in your setup.
 
 
-### Enable DNS resolution in virtual clusters
+### Enable DNS resolution in tenant clusters
 
-vCluster runs a CoreDNS component inside each virtual cluster to handle internal DNS queries. To avoid conflicts with the host cluster's DNS, CoreDNS in vCluster listens on port `1053` instead of the default port `53`.
+vCluster runs a CoreDNS component inside each tenant cluster to handle internal DNS queries. To avoid conflicts with the control plane cluster's DNS, CoreDNS in vCluster listens on port `1053` instead of the default port `53`.
 
-If this port is blocked, DNS queries from virtual cluster pods might not work, especially when the querying pod and the CoreDNS pod are on different nodes. This issue commonly affects EKS clusters created with Terraform, which set up separate security groups for the control plane and worker nodes. By default, the node security group does not allow inbound traffic on port `1053`.
+If this port is blocked, DNS queries from tenant cluster pods might not work, especially when the querying pod and the CoreDNS pod are on different nodes. This issue commonly affects EKS clusters created with Terraform, which set up separate security groups for the control plane and worker nodes. By default, the node security group does not allow inbound traffic on port `1053`.
 
-To enable proper DNS resolution within virtual clusters, allow inbound traffic on port `1053` between nodes.
+To enable proper DNS resolution within tenant clusters, allow inbound traffic on port `1053` between nodes.
 
 | Port   | Description          | Purpose                                                                 |
 |--------|----------------------|-------------------------------------------------------------------------|
-| `1053` | CoreDNS for vCluster | Enables internal DNS resolution across nodes in virtual clusters        |
+| `1053` | CoreDNS for vCluster | Enables internal DNS resolution across nodes in tenant clusters        |
 
 :::note
 If you're using EKS with Terraform, check the default node security group and manually allow inbound traffic on TCP and UDP port `1053`. This ensures DNS queries between pods and CoreDNS can succeed even when scheduled on different nodes.

platform/administer/clusters/advanced/terraform-registration.mdx

@@ -13,11 +13,11 @@ import PageVariables from "@site/src/components/PageVariables";
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-Automate host cluster registration to vCluster Platform using Terraform. This guide shows you how to programmatically register clusters during infrastructure provisioning, eliminating manual registration steps.
+Automate control plane cluster registration to vCluster Platform using Terraform. This guide shows you how to programmatically register clusters during infrastructure provisioning, eliminating manual registration steps.
 
 ## Overview
 
-When provisioning infrastructure with Terraform, you can automate the complete cluster registration workflow. This approach registers the cluster in vCluster Platform and installs the agent, making the cluster immediately available for virtual cluster deployment.
+When provisioning infrastructure with Terraform, you can automate the complete cluster registration workflow. This approach registers the cluster in vCluster Platform and installs the agent, making the cluster immediately available for tenant cluster deployment.
 
 :::info Terraform provider deprecation
 The vCluster Platform Terraform provider is deprecated. This guide provides an alternative approach using the Kubernetes provider and vCluster Platform API to achieve the same automation goals.
@@ -598,7 +598,7 @@ The configuration requires two kubernetes provider contexts: one for the platfor
 
 After registering your cluster, you can:
 
-- [Create virtual clusters](../../../use-platform/virtual-clusters/add-virtual-clusters.mdx) on the registered host cluster
+- [Create tenant clusters](../../../use-platform/virtual-clusters/add-virtual-clusters.mdx) on the registered control plane cluster
 - [Configure agent settings](./agent-config.mdx) for advanced networking or security requirements
 - [Set up monitoring](../../../maintenance/monitoring/overview.mdx) for the agent and connected resources
 - [Implement policies](./policies.mdx) to control resource usage across clusters