Skip to main content

Isolated Control Plane

This feature provides the flexibility to deploy the vCluster control plane on one cluster, while hosting the actual workloads on a separate cluster.

Key Benefits​

  • Optimized Resource Allocation: Deploy control planes on cost-effective clusters and direct heavy-duty tasks, such as GPU-intensive workloads, to higher-performance clusters.

  • Simplified Management: Offers a straightforward, enforceable, alternative to each developer managing increasingly complex amounts of Taints/Tolerations or node affinities to schedule workloads to the appropriate clusters.

  • Enhanced Security with Control: Developers can manage workloads via the control plane, even if the workloads reside in a secure zone. This eliminates the need to provide developers with direct cluster access, firewall configurations, permissions management, and more.

  • Divided Responsibilities: Allows for a clear separation of duties, where one team oversees the control plane cluster and other teams handle the workload clusters.

Pre-Requisites

Currently this feature only works through a LoadBalancer. Hence the user needs to make sure that their control plane is able to schedule LoadBalancers that fills the status.Ingress field correctly with either an IP or a hostname. Compatibility has been tested in Google Cloud and AWS.

Another requirement for this feature is that it expects a kube config to a headless vCluster installation, hence the target vCluster must be deployed as a headless vCluster.

Setup Guide​

This feature allows you to deploy the vCluster control plane in one cluster and the actual workloads into another cluster.

Pre-Requisites

Currently this feature only works through a LoadBalancer. Hence the user needs to make sure that their control plane is able to schedule LoadBalancers that fill the status.Ingress field correctly with either and IP or a hostname. Compatibility has been tested in Google Cloud and AWS.

Another requirement for this feature is that it expects a kube config to a headless vcluster installation, hence the target vcluster must be deployed as a headless vcluster.

Create the remote vcluster​

Put the following configuration in VirtualClusterInstance resource:

apiVersion: management.loft.sh/v1
kind: VirtualClusterInstance
...
...
spec:
  template:
    helmRelease:
      chart:
        name: vcluster
        repo: https://charts.loft.sh
      # add any other values you want here
      values: |-
        service:
          type: LoadBalancer
    # This field is required to make sure Loft knows about deploying the workloads into a separate cluster
    workloadVirtualClusterTemplate: {}
    # You can specify specific workload cluster helm values via
    # helmRelease:
    #   values: ...
  # This is the reference to the cluster where the control-plane is running
  clusterRef:
    namespace: vcluster-control-plane
    virtualCluster: my-vcluster
    cluster: cluster-1              # the k8s cluster where the vcluster control plane runs
  # This is the reference to the cluster where the workloads are running
  workloadClusterRef:
    namespace: vcluster-workloads
    virtualCluster: my-vcluster
    cluster: cluster-2              # the k8s cluster where the actual workloads run

This will deploy the control-plane into cluster-1 and the workloads into cluster-2.

Important Points
  • The workloadVirtualClusterTemplate field is mandatory for vCluster.Pro to deploy workloads into the separate cluster.
  • The clusterRef provides a reference to the Kubernetes cluster where the control plane of the vCluster runs.
  • The workloadClusterRef points to the cluster where the actual workloads will run.
Last updated on