diff --git a/vcluster/introduction/architecture.mdx b/vcluster/introduction/architecture.mdx index 38c54f091a..fc8b18eda6 100644 --- a/vcluster/introduction/architecture.mdx +++ b/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. diff --git a/vcluster/third-party-integrations/git-operations/flux.mdx b/vcluster/third-party-integrations/git-operations/flux.mdx index a3970d034f..f7f6b51101 100644 --- a/vcluster/third-party-integrations/git-operations/flux.mdx +++ b/vcluster/third-party-integrations/git-operations/flux.mdx @@ -16,7 +16,7 @@ import BasePrerequisites from '@site/docs/_partials/base-prerequisites.mdx' # Deploy with Flux -This guide shows how to manage virtual clusters using [Flux](https://fluxcd.io/), a GitOps tool for Kubernetes. Flux uses GitOps to keep your Kubernetes clusters in sync with the desired state defined in your Git repository. +This guide shows how to manage tenant clusters using [Flux](https://fluxcd.io/), a GitOps tool for Kubernetes. Flux uses GitOps to keep your Kubernetes clusters in sync with the desired state defined in your Git repository. ## Prerequisites @@ -31,15 +31,15 @@ Additionally, you'll need: ## Architecture options {#architecture-options} -When using Flux with virtual clusters, choose an architecture that aligns well with your GitOps workflow. You can configure Flux to work with virtual clusters in several ways, each offering different benefits and limitations. +When using Flux with tenant clusters, choose an architecture that aligns well with your GitOps workflow. You can configure Flux to work with tenant clusters in several ways, each offering different benefits and limitations. -Unlike ArgoCD, which treats other clusters as first-class objects, Flux manages workloads on other clusters through kubeconfig references in `HelmRelease` and `Kustomization` resources. This difference in design influences how you'll structure your GitOps workflows when working with virtual clusters. +Unlike ArgoCD, which treats other clusters as first-class objects, Flux manages workloads on other clusters through kubeconfig references in `HelmRelease` and `Kustomization` resources. This difference in design influences how you'll structure your GitOps workflows when working with tenant clusters. -The following are common approaches for integrating Flux with virtual clusters, each suited to different use cases: +The following are common approaches for integrating Flux with tenant clusters, each suited to different use cases: -### 1. Flux instance per host cluster {#flux-per-host} +### 1. Flux instance per control plane cluster {#flux-per-host} -When running Flux on each host cluster, it can manage the virtual clusters within that environment. This approach is recommended if you already use Flux for each traditional cluster and want to maintain a similar management pattern. +When running Flux on each control plane cluster, it can manage the tenant clusters within that environment. This approach is recommended if you already use Flux for each traditional cluster and want to maintain a similar management pattern. ```mermaid flowchart TD @@ -53,17 +53,17 @@ flowchart TD ``` Architecture characteristics: -- One Flux instance per host cluster -- Each Flux instance manages multiple virtual clusters on that host -- Virtual cluster kubeconfig Secret management is simplified since Secrets are local to the cluster -- Clear separation of responsibilities by host cluster +- One Flux instance per control plane cluster +- Each Flux instance manages multiple tenant clusters on that host +- Tenant cluster kubeconfig Secret management is simplified since Secrets are local to the cluster +- Clear separation of responsibilities by control plane cluster - Recommended if you already use a Flux instance per traditional cluster - Provides better resource utilization since the Flux controllers are shared ### 2. Hub and spoke model {#hub-and-spoke} -With this approach, a central Flux instance manages multiple virtual clusters across different host clusters. This is a good option if you already use a single Flux instance with multiple Kubernetes clusters or if you want centralized control of all virtual environments. +With this approach, a central Flux instance manages multiple tenant clusters across different control plane clusters. This is a good option if you already use a single Flux instance with multiple Kubernetes clusters or if you want centralized control of all virtual environments. ```mermaid flowchart TD @@ -75,16 +75,16 @@ flowchart TD ``` Architecture characteristics: -- One central Flux instance manages multiple virtual clusters across different hosts +- One central Flux instance manages multiple tenant clusters across different hosts - Works well with existing hub and spoke Flux setups - Requires secure kubeconfig Secret management between clusters -- More efficient for large numbers of virtual clusters -- Provides a single control point for all virtual cluster management +- More efficient for large numbers of tenant clusters +- Provides a single control point for all tenant cluster management - Can simplify GitOps workflows by having a single source of truth -### 3. Flux inside virtual clusters {#flux-inside-vclusters} +### 3. Flux inside tenant clusters {#flux-inside-vclusters} -While possible, running Flux inside every virtual cluster adds resource overhead and management complexity. This approach might be suitable when virtual clusters need complete isolation and independent GitOps workflows. +While possible, running Flux inside every tenant cluster adds resource overhead and management complexity. This approach might be suitable when tenant clusters need complete isolation and independent GitOps workflows. ```mermaid flowchart TD @@ -98,19 +98,19 @@ flowchart TD ``` Architecture characteristics: -- Each virtual cluster runs its own Flux instance +- Each tenant cluster runs its own Flux instance - Provides complete isolation between environments - Teams can manage their own GitOps workflows independently - Increased resource overhead (each vCluster needs its own Flux controllers) - More complex to manage at scale - Suitable for environments where strict isolation is required -The standalone approach—deploying Flux in each virtual cluster—might not scale effectively when managing large numbers of virtual clusters, particularly in ephemeral environments like pull request previews. In these cases, a hub-and-spoke model or a Flux instance per host cluster is typically more resource-efficient and can reduce the overhead of running multiple Flux controllers. +The standalone approach of deploying Flux in each tenant cluster might not scale effectively when managing large numbers of tenant clusters, particularly in ephemeral environments like pull request previews. In these cases, a hub-and-spoke model or a Flux instance per control plane cluster is typically more resource-efficient and can reduce the overhead of running multiple Flux controllers. ## Enable kubeconfig export {#enable-kubeconfig-export} -To enable Flux to deploy to virtual clusters, you must create a kubeconfig Secret that Flux can reference. +To enable Flux to deploy to tenant clusters, you must create a kubeconfig Secret that Flux can reference. ```yaml title="Configure kubeconfig export in vcluster.yaml" exportKubeConfig: @@ -130,7 +130,7 @@ controlPlane: ``` This configuration: -- Exports the virtual cluster kubeconfig as a Secret in the host namespace +- Exports the tenant cluster kubeconfig as a Secret in the host namespace - Makes the Secret available for Flux to use with the `spec.kubeConfig` field - Uses a server URL that is accessible from the Flux controllers (replace `vcluster-name` and `vcluster-namespace` with your actual values) - Sets `insecure: true` to automatically skip TLS certificate verification @@ -169,9 +169,9 @@ exportKubeConfig: See the [Troubleshooting](#tls-certificate-verification-errors) section for solutions to certificate issues. ::: -## Deploy applications to virtual clusters +## Deploy applications to tenant clusters -After the vCluster is up and running, use Flux to deploy applications directly into the virtual cluster. +After the vCluster is up and running, use Flux to deploy applications directly into the tenant cluster. @@ -234,10 +234,10 @@ spec: ``` :::tip Handling TLS certificate verification -The `kubeConfig` section references the Secret created by the vCluster using the `exportKubeConfig` setting. To allow Flux to connect to the virtual cluster with a self-signed certificate, you must configure both Flux and vCluster to permit insecure TLS connections: +The `kubeConfig` section references the Secret created by the vCluster using the `exportKubeConfig` setting. To allow Flux to connect to the tenant cluster with a self-signed certificate, you must configure both Flux and vCluster to permit insecure TLS connections: - **Flux Helm Controller configuration**: - Add the `--insecure-kubeconfig-tls` flag to the [Helm Controller configuration](https://fluxcd.io/flux/components/helm/options/). This allows Flux to honor `insecure-skip-tls-verify: true` in the referenced kubeconfig and skip certificate verification when connecting to the virtual cluster. + Add the `--insecure-kubeconfig-tls` flag to the [Helm Controller configuration](https://fluxcd.io/flux/components/helm/options/). This allows Flux to honor `insecure-skip-tls-verify: true` in the referenced kubeconfig and skip certificate verification when connecting to the tenant cluster. > **Warning:** This approach skips TLS certificate verification and is not recommended for production environments. - **vCluster configuration**: @@ -269,7 +269,7 @@ git push -Virtual Cluster Verify deployment +Tenant Cluster Verify deployment After Flux reconciles the changes, you can connect to your vCluster and verify the application is deployed: @@ -285,9 +285,9 @@ kubectl get ingress -n podinfo -## Manage multiple virtual clusters {#manage-multiple-vclusters} +## Manage multiple tenant clusters {#manage-multiple-vclusters} -When managing multiple virtual clusters with Flux, you can use Kustomize to organize your configurations. +When managing multiple tenant clusters with Flux, you can use Kustomize to organize your configurations. ```yaml title="clusters/kustomization.yaml" --- @@ -302,11 +302,11 @@ resources: ## Bootstrap review environments with pre-installed Flux {#bootstrapping-review-environments} -A common scenario is having Flux already installed on the host cluster and wanting to use it for ephemeral review environments with virtual clusters. This approach follows GitOps principles while avoiding the need to install Flux separately for each environment. +A common scenario is having Flux already installed on the control plane cluster and wanting to use it for ephemeral review environments with tenant clusters. This approach follows GitOps principles while avoiding the need to install Flux separately for each environment. ### Use ResourceSet feature for review environments {#flux-resource-sets} -For later versions of Flux, you can use the native Flux Operator `ResourceSet` capability to manage ephemeral environments efficiently. This is a feature for creating review environments that include virtual clusters. +For later versions of Flux, you can use the native Flux Operator `ResourceSet` capability to manage ephemeral environments efficiently. This is a feature for creating review environments that include tenant clusters. ```yaml title="pr-resource-set.yaml" apiVersion: resourcesets.toolkit.fluxcd.io/v1alpha2 @@ -382,11 +382,11 @@ For more details, see the [Flux Operator `ResourceSet` documentation](https://fl ### Use existing Flux for review environments -When Flux is already installed on your host cluster, you can create a GitOps workflow for review environments that: +When Flux is already installed on your control plane cluster, you can create a GitOps workflow for review environments that: -1. Uses the existing Flux installation on the host cluster -2. Deploys virtual clusters for each review environment -3. Use Flux to deploy applications to these virtual clusters +1. Uses the existing Flux installation on the control plane cluster +2. Deploys tenant clusters for each review environment +3. Use Flux to deploy applications to these tenant clusters 4. Reduces overhead and speeds up environment bootstrapping @@ -472,14 +472,14 @@ steps: git push ``` -With this approach, your CI/CD pipeline creates the necessary configuration in your GitOps repository, and Flux (already running on the host cluster) automatically provisions the vCluster and deploys applications to it. +With this approach, your CI/CD pipeline creates the necessary configuration in your GitOps repository, and Flux (already running on the control plane cluster) automatically provisions the vCluster and deploys applications to it. -Host Cluster Existing Flux detects and applies changes +Control Plane Cluster Existing Flux detects and applies changes -The Flux controllers already running on your host cluster is going to: +The Flux controllers already running on your control plane cluster is going to: - Detect the new vCluster configuration - Create the required namespace @@ -499,13 +499,13 @@ In production environments, implement automatic cleanup of preview environments This pattern allows you to use an existing Flux installation rather than deploying Flux separately for each review environment. This significantly reduces overhead and bootstrap time. :::tip Advanced management with vCluster Platform -For organizations managing many virtual clusters—especially in dynamic, ephemeral environments—vCluster Platform offers advanced lifecycle management capabilities that integrate smoothly with GitOps workflows. It supports automatic creation of kubeconfig `Secrets`, access control management, and simplified bootstrapping of virtual clusters with Flux. +For organizations managing many tenant clusters, especially in dynamic, ephemeral environments, vCluster Platform offers advanced lifecycle management capabilities that integrate smoothly with GitOps workflows. It supports automatic creation of kubeconfig `Secrets`, access control management, and simplified bootstrapping of tenant clusters with Flux. ::: ## Troubleshoot -Host Cluster -- Verify the virtual cluster kubeconfig Secret exists with the correct format +Control Plane Cluster +- Verify the tenant cluster kubeconfig Secret exists with the correct format - Check Flux controller logs for errors - Ensure Flux has the necessary permissions to access the Secret @@ -517,12 +517,12 @@ kubectl logs -n flux-system deployment/source-controller kubectl logs -n flux-system deployment/helm-controller ``` -Virtual Cluster -- Verify that resources are being created in the virtual cluster +Tenant Cluster +- Verify that resources are being created in the tenant cluster - Check that the `exportKubeConfig` setting is properly configured - Ensure the server URL is reachable from the Flux controllers -```bash title="Check virtual cluster configuration" +```bash title="Check tenant cluster configuration" kubectl get configmap -n vcluster-namespace vcluster-flux-demo -o yaml ``` @@ -628,7 +628,7 @@ spec: ##### Solution 3: Use Flux's built-in TLS verification options -To allow Flux (v2+) to connect to a virtual cluster with a self-signed certificate, you must configure the Flux Helm Controller to permit insecure TLS connections: +To allow Flux (v2+) to connect to a tenant cluster with a self-signed certificate, you must configure the Flux Helm Controller to permit insecure TLS connections: - **Add `--insecure-kubeconfig-tls` to the Helm Controller** Ensure the Helm Controller is started with the `--insecure-kubeconfig-tls` flag. This enables Flux to honor `insecure-skip-tls-verify: true` inside the referenced kubeconfig Secret and skip certificate verification for the target (virtual) cluster. @@ -653,9 +653,9 @@ patches: #### Connection refused errors If you see "connection refused" errors in the Flux controller logs, it might indicate: -1. The virtual cluster's API server is not accessible from Flux +1. The tenant cluster's API server is not accessible from Flux 2. Network policies are blocking the communication -3. The virtual cluster is not running or healthy +3. The tenant cluster is not running or healthy 4. The server URL in the kubeconfig is not correctly configured You might see errors in the Flux controller logs like: @@ -666,7 +666,7 @@ connect: connection refused To troubleshoot: -1. Check if the virtual cluster is running and ready: +1. Check if the tenant cluster is running and ready: ```bash title="Verify vCluster status" kubectl get pods -n ``` diff --git a/vcluster/third-party-integrations/github-actions/preview-environments.mdx b/vcluster/third-party-integrations/github-actions/preview-environments.mdx index 89b2283c4c..9ba62637a9 100644 --- a/vcluster/third-party-integrations/github-actions/preview-environments.mdx +++ b/vcluster/third-party-integrations/github-actions/preview-environments.mdx @@ -11,7 +11,7 @@ import TenancySupport from '../../_fragments/tenancy-support.mdx'; -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 diff --git a/vcluster/third-party-integrations/github-actions/pull-requests.mdx b/vcluster/third-party-integrations/github-actions/pull-requests.mdx index f1b2eaec51..931443ecee 100644 --- a/vcluster/third-party-integrations/github-actions/pull-requests.mdx +++ b/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. - + -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: -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 <Control Plane Cluster 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 platform 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 platform API to retrieve the updated name of the KSA in the control plane cluster. ### Prerequisites This guide assumes you have the following prerequisites: diff --git a/vcluster/third-party-integrations/pod-identity/gke-workload-identity.mdx b/vcluster/third-party-integrations/pod-identity/gke-workload-identity.mdx index 87172bcf9a..9c9d696622 100644 --- a/vcluster/third-party-integrations/pod-identity/gke-workload-identity.mdx +++ b/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: diff --git a/vcluster/third-party-integrations/rancher/install-rancher-integration.mdx b/vcluster/third-party-integrations/rancher/install-rancher-integration.mdx index 76e43b2e8a..1b8a0df2db 100644 --- a/vcluster/third-party-integrations/rancher/install-rancher-integration.mdx +++ b/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: diff --git a/vcluster/third-party-integrations/scheduler/kai-scheduler.mdx b/vcluster/third-party-integrations/scheduler/kai-scheduler.mdx index 9f86673bb2..b5871baa9d 100644 --- a/vcluster/third-party-integrations/scheduler/kai-scheduler.mdx +++ b/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} diff --git a/vcluster_versioned_docs/version-0.34.0/introduction/architecture.mdx b/vcluster_versioned_docs/version-0.34.0/introduction/architecture.mdx index b0560fb930..6d56bb60b2 100644 --- a/vcluster_versioned_docs/version-0.34.0/introduction/architecture.mdx +++ b/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.