Skip to content

vCluster

vCluster is an advanced feature of the DSH platform designed for users who need a more Kubernetes-native environment to deploy and manage complex applications.

Using vCluster rather than the regular DSH services setup allows a tenant more direct Kubernetes capabilities. However, with this additional control comes increased responsibility. Some capabilities that are normally provided and managed by the DSH platform become your responsibility when using vCluster. See the section below for more details.

Before using vCluster, make sure you understand these additional responsibilities and have the necessary knowledge and processes in place to manage them.

For more information about the technology behind vCluster and how it works, see the vCluster documentation.

Some restrictions still apply in order to keep the DSH platform KSP compliant. For more information on those see the section on Restrictions and Limitations.

Requesting a vCluster

If you want to request a vCluster, you need to create a ticket in the DSH Support Portal and fill out the following fields:

  • Tenant: Enter the name of your tenant.
  • Tenant owner: Enter the name of your tenant owner.
  • Platform: In the drop-down menu, select the platform you want.
  • CPU limit: CPU limit for vCluster workloads.
  • Memory limit: Memory limit for vCluster workloads.
  • Ingress needed: Yes or no. If your vCluster workloads do not require external access, this functionality will be disabled.

Accessing your vCluster

Once your request has been approved and the vCluster has been created for your tenant, you can find the kubeconfig required to connect to your vCluster in your tenant secrets.

The kubeconfig is stored in the secret named vcluster-kubeconfig.

Note

The kubeconfig file itself is not considered information-security sensitive. Access to the vCluster is secured through OIDC authentication.

Authentication

To authenticate and connect to your vCluster, you must use the kubelogin tool. found at:
https://github.com/int128/kubelogin

Kubelogin handles the OIDC authentication required to access your cluster.

After installing the plugin for kubectl (see kubelogin setup instructions), you will be prompted to log in through your browser once you run your first kubectl command.
E.g. k get ns --kubeconfig configfile.yaml
Where the content of your vCluster’s kubeconfig, from the vcluster-kubeconfig secret, has been put in configfile.yaml

Using Kafka from your vCluster

Workloads deployed in a tenant vCluster are granted the same Kafka access as regular DSH services; see Getting started.

Volumes in your vCluster

To use Volumes in your vCluster, your PVC’s must use the storage class vcluster-standard-v1

Setting up ingress in your vCluster

To use Ingress with your vCluster, make sure your services meet the following requirements:

  • Service label: Add the label vclusterIngressController: "true" to each service that should be exposed through Ingress.
  • Port: Your service must listen on port 443.
  • Proxy Protocol: Your service must have Proxy Protocol enabled.
  • Host name: The host name used for vCluster Ingress must conform to the following format <tenantName>-vc.<platformDomainName> e.g. yourtenant-vc.example.kpn.dsh.com
  • TLS certificate: A wildcard certificatevcluster-ingress-cert is provided as a Secret in the vCluster ingress namespace.

vCluster Tenant Responsibilities

Backups

The platform provides the vCluster infrastructure, which includes the etcd component used by the vCluster. However, the platform does not perform backups of the vCluster etcd.

Tenants are responsible for creating backups of all workloads running within their vCluster; implementing a GitOps workflow is highly recommended. Furthermore, any backups of data stored in volumes must be transferred to out-of-cluster persistent storage.

Monitoring

Tenants are responsible for setting up monitoring and alerting for their respective workloads. Please note that workloads operate with restricted Kubernetes access, which may impact certain monitoring configurations. Workload logs can be accessed via the dedicated tenant Grafana instance.

Security

Tenants are responsible for performing security scanning and ensuring that all workloads within their vCluster are KSP compliant.

Networking

Tenants are responsible for the creation and renewal of all certificates required for use within their vCluster.

Additionally, tenants must configure an ingress controller to route traffic to services within the vCluster. Traefik is the only ingress controller that has been tested and verified by the platform; compatibility with other ingress controllers cannot be guaranteed.

Restrictions and Limitations

Labels and Annotations

To ensure the correct functioning of the platform, certain Kubernetes labels and annotations are reserved. Tenants are not permitted to use these reserved labels within their vCluster. If a tenant attempts to apply a reserved label, the platform will block the action and return an error message.

Connectivity

A vCluster is a tenanted environment. Workloads within a vCluster are permitted to connect to:

  • Other workloads within the same vCluster.
  • Regular services of your tenant.
  • Services running within the enclave of your tenant.

Resource Labeling

The platform automatically applies specific labels to components to maintain tenant isolation:

  • Pods & PVCs: dsh/tenant

Service and Registry Constraints

  • Service Types: Only ClusterIP service types are permitted.
  • Container Registry: Usage is restricted to the tenant’s assigned container registry.
  • Network Access: Tenants are unable to restrict cross-namespace network access within the vCluster.

Pod Disruption Budgets (PDB)

Due to the underlying architecture of vCluster, PDB configurations are limited:

  • Supported: PDB configurations using minAvailable are tested and confirmed to work.
  • Unsupported: Percentage-based configurations and maxUnavailable configurations are blocked and will not function.