Our latest update to vCluster brings powerful new capabilities, including customizable resource syncing, bi-directional sync support, and native integrations with key Kubernetes tools. Additionally, v0.21 introduces a FIPS-compliant edition to meet the stringent security needs of the public sector.

Custom Resource Syncing

You can now sync any custom resources in two simple steps:

1. Get the full name of the custom resources definition (CRD). For a full list of available CRDs in your cluster, run kubectl get crds

2. Specify the enabled: true for the resource under sync.toHost.customResources.[resourceName]

For syncing the Certificate resource of Cert Manager for example, you would specify the sync using the CRD name certificates.cert-manager.io as shown in the example below:

sync:
  toHost:
    customResources:
      certificates.cert-manager.io:
        enabled: true

Enabling the sync for custom resources in the toHost section means that:

1. The CRD is imported from the host cluster into the virtual cluster.

2. All custom resources of this kind will be synced from the virtual cluster to the host cluster.

Please note that the fromHost custom resource sync works similarly: First, the CRD will be synced into the virtual cluster, then the sync of custom resources from the host is started. However, please note that fromHost custom resources is limited to cluster-wide CRDs and the resources synced into the virtual cluster will be readonly within the virtual cluster. For additional details, please refer to the documentation for toHost.customResources and fromHost.customResources.

Sync Patches

You can now patch resources during the sync process. This feature works for any resource that vCluster is syncing, including the ones you specify via the newly introduced Custom Resource Syncing.

There are two types of patches:

• Patches that allow you to sync references to other objects (e.g. secretRef)

• Custom patches that you can define using JavaScript expressions

Patching References To Other Objects

Reference patches allow you to specify paths within objects that contain references to other objects. For example, let’s take the Certificates resource in Cert Manager:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
  namespace: sandbox
spec:
  secretName: example-com-tls

If you create this resource, you will have to specify secretName which defines where Cert Manager will store the secret that it will write the certificate into once its provisioned. If you use the new Custom Resource Syncing for this Certificate resource to reuse a shared Cert Manager that is running on the host cluster, vCluster will sync the Certificate resource down to the host cluster. However, given that multiple namespaces inside the virtual cluster sync to the same namespace in the host cluster, conflicts would arise pretty quickly and on top of that it’s almost impossible for vCluster to know that spec.secretName in the above example references a secret.

In order to solve this problem, you can now tell vCluster where references can be found in a custom resource and vCluster will enable syncing for these resource while automatically patching the names of resources accordingly - as it would do with any other resource during syncing. See the example configuration below to tell vCluster that the field spec.secretName contains a reference to a Kubernetes secret:

sync:
  toHost:
    customResources:
      certificates.cert-manager.io:
        enabled: true
        patches:
        - path: spec.secretName
          reference:
            apiVersion: v1
            kind: Secret

Custom Patching with JavaScript Expressions

With custom patches you can now introduce JavaScript expressions that modify resources during the sync process on-the-fly. The current value in the specified field is contained in the variable value and the JavaScript expression is supposed to return the value you would like the field to have once it’s synced. The following example, would modify all strings within the spec.dnsNames array to add the www. prefix if not already part of the string.

Additionally, you can use the reverseExpression field to make sure vCluster knows how to revert the change. Specifying this field allows you to retain bi-directional syncing, another new feature we are introducing in v0.21.

sync:
  toHost:
    customResources:
      certificates.cert-manager.io:
        enabled: true
        patches:
        - path: spec.dnsNames[*]
          expression: "value.startsWith('www.') ? value : `www.${value}`"
          # Optional. Specifies how to sync back changes. 
          # If empty, will disable bi-directional sync for this field.
          reverseExpression: "value.startsWith('www.') ? value.slice(4) : value"

Bi-Directional Sync

One of the most exiting features of v0.21 is that we are introducing bi-directional syncing. So far, vCluster sync has been one-directional. That means that if a resource was synced from the virtual cluster to the host cluster and a controller then modified the resource in the host cluster, these changes would be overwritten and reset by the syncer because it considers the original resource (i.e. the resource in the virtual cluster) as the source of truth.

With bi-directional syncing, vCluster keeps track of any changes to each individual field and is able to sync changes back and forth. This feature is not yet supported for all resources and fields but we aim to expand it to all resources and fields very soon. Currently, bi-directional sync is supported for:

• All fields on custom resources

• Annotations and labels on any resource

• Certain fields on the following core resources:

  • Pod, ServiceAccount

  • ConfigMap, Secret

  • Service, Ingress, PriorityClass

  • PersistentVolumeClaim, PersistentVolume, StorageClass

Please refer to the documentation for a full list of all fields that support bi-directional sync.

Integrations

While Custom Resource Sync enables you to sync any resource easily, some resources tend to be very complex and we decided to start an effort to build native integrations for major tools used in the Kubernetes ecosystem. Making these integrations part of vCluster will allow you to enable them with a simple true/false toggle without having to configure a lot of YAML. Additionally, this approach will give users confidence that vCluster maintainers will have their back if these controllers and resources evolve over time.

The first two integrations available as of today are:

• External Secrets Operator

• KubeVirt

External Secrets Operator

Please find an example of how to enable the External Secrets Operator integration below and refer to the documentation for additional details.

integrations:
  externalSecrets:
    enabled: true
    sync:
      externalSecrets:
        enabled: true
      stores:
        enabled: true
      clusterStores:
        enabled: true

KubeVirt

Please find an example of how to enable the KubeVirt integration below and refer to the documentation for additional details.

integrations:
  kubeVirt:
    enabled: true
    sync:
      dataVolumes:
        enabled: true

FIPS Compliance

Given the huge interest from the public sector, we are committed to work on security and compliance features that enable these users to confidently build on vCluster for mission-critical use cases. As part of this effort, vCluster v0.21 is now available as a FIPS 140-2 compliant edition. The FIPS compliant binaries require a valid license key and are part of our commercial vCluster offering only. If you are interested in deploying FIPS compliant virtual clusters, please contact us via gov@loft.sh.

Other Changes

Notable Improvements

• Kubernetes v1.31 is now supported except for k0s

Fixes & Other Changes

For a list of additional fixes and smaller changes, please refer to the release notes.