Spring is just around the corner and you know what that means, KubeCon Europe is almost here! We have some exciting features to announce, and not just in vCluster. Swing by our booth to find out all the details, but here’s a little preview of what just shipped a few weeks before KubeCon London:

Snapshot & Restore

Backing up and restoring a virtual cluster has been possible for some time with Velero but that solution has it’s drawbacks. The restore paradigm doesn’t work seamlessly while the virtual cluster pod is running, it can be slow, and has limited use cases. Several users have requested a more full-featured backup process, and today we are happy to announce a solution.

Snapshots are now a built-in feature of vCluster. These are quick, lightweight bundles created directly through the vCluster CLI, with a variety of options to make your life easier. Taking a snapshot and exporting it directly to an OCI compliant registry, for example, is done with a simple command:

vcluster snapshot my-vcluster oci://ghcr.io/my-user/example-repo:snap-one 

Each snapshot includes the etcd database content, the helm release, and the vcluster.yaml configuration. Restoring is just as easy:

vcluster restore my-vcluster oci://ghcr.io/my-user/my-repo:my-tag 

You can use snapshot and restore for the the following use cases:

1. Restoring in-place, i.e. reverting a virtual cluster to a previous state based on a previous snapshot

2. Migrating between config options that don’t have a direct migration path such as changing the backing store of a virtual cluster

3. Making several copies of the same virtual cluster using the same snapshot (almost as if you were using a snapshot to package a virtual cluster for distribution)

4. Migrating a virtual cluster to from one Kubernetes cluster to another one (please note that snapshots currently don’t support PV migrations)

We anticipate the flexibility this feature provides will create many unique implementations. As of today this feature supports saving to an OCI registry, S3, or to it’s local storage with the container protocol. Please see the docs for more information, including current limitations, and further configuration.

Sleep Mode Parity

In our v0.22 release we announced vCluster-Native Sleep Mode. This feature allowed virtual clusters which were deployed outside of our platform, and without an agent, the ability to take advantage of sleep mechanisms by putting workloads to sleep while leaving the control plane running.

With v0.24 and our upcoming Platform 4.3 release, this vCluster-Native Sleep Mode will be combined with our original Platform-based Sleep Mode in order to make a single unified solution which contains the best of both worlds. Once your virtual cluster is configured with Sleep Mode (see example below), it and the Platform will work together to shut down as many components as possible. Without an agent it will shut down only workloads, and with an agent it will also sleep the control plane.

sleepMode:
  enabled: true
  autoSleep:
    afterInactivity: 1h
    exclude:
      selector:
        labels:
          dont: sleep

This new feature will once again be known simply as Sleep Mode. Please see the docs for instructions on how to migrate your configuration, and how to upgrade both the Platform (once it is available in the Platform 4.3 release) and your virtual cluster.

Other Changes

Notable Improvements

The Export Kube-Config feature has been improved to allow for more than one secret to be added. This change also aims to remove confusion, as the config itself clarifies how both the default secret and the additionalSecrets are set. In the below example you can see the default secret and multiple additional secrets being configured. The original exportKubeConfig.secret option is now deprecated, and will be removed in a future version.

exportKubeConfig:
  context: domain-context
  server: https://domain.org:443
  additionalSecrets:
  - namespace: alternative-namespace
    name: vc-alternative-secret
    context: alternative-context
    server: https://domain.org:443
  - namespace: ...

Fixes & Other Updates

• In the announcement for version v0.20 we noted that **ghcr.io/loft-sh/vcluster-pro** would be the default image in vCluster. To avoid confusion the loft-sh/vcluster image is now deprecated, and in future versions will no long be updated. Instead the loft-sh/vcluster-oss will continue to be built for public use and can be used as a replacement.

• As stated in our v0.23 announcement, deploying multiple virtual clusters per-namespace is now deprecated. When using v0.24, the virtual cluster pod will not start unless you enable the reuseNamespace option in your vCluster’s config.yaml. This functionality will soon be removed entirely.

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