Our newest release provides two new features to make managing and scheduling workloads inside virtual clusters even easier, along with several important updates.

Namespace Syncing

In a standard vCluster setup, when objects are synced from the virtual cluster to the host cluster their names are translated to ensure no conflicts occur. However some use cases have a hard requirement that names and namespaces must be static. Our new Namespace Syncing feature has been built specifically for this scenario. The namespace and any objects inside of it will be retained 1:1 when synced from the virtual cluster context to the host cluster if they follow user-specified custom mapping rules. Let’s look at an example:

sync:
  toHost:
    namespaces:
      enabled: true 
      mappings:
        byName:
          "team-*": "host-team-*"

If I use the vcluster.yaml shown above and then create a namespace called team-one-application, it will be synced to the host as host-team-one-application. Any objects inside of this namespace which have toHost syncing enabled will then be synced 1:1 without changing the names of these objects. This allows users to achieve standard naming conventions for namespaces no matter the location, allowing for an alternative way of operating virtual clusters.

Several other configurations, patterns, and restrictions exist. Please see the documentation for more information. Also note that this feature replaces the experimental multi-namespace-mode feature with immediate effect.

Hybrid-Scheduling

Our second headline feature focuses on scheduling. Currently we allow scheduling using the host or virtual scheduling, but not both at the same time. This was restrictive for users who wanted a combination of both, allowing a pod to be scheduled by a custom scheduler on either the virtual cluster or the host, or falling back to the host. Enter hybrid-scheduling:

sync:
  toHost:
    pods:
      hybridScheduling:
        enabled: true
        hostSchedulers:
        - kai-scheduler

The above config informs vCluster that if a pod would like to use the kai-scheduler, it exists on the host cluster, and will be forwarded to it. Any specified scheduler not listed in the config is assumed to be running and operating directly inside the virtual cluster and pods remain pending there to be scheduled before being synced to the host cluster.

Finally any pod which does not specify a scheduler will use the host’s default scheduler. Therefore if a new custom scheduler is needed, you only need to deploy the scheduler inside the virtual cluster and set its name on the pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  schedulerName: my-new-custom-scheduler

Alternatively if the virtual scheduler option is enabled, the virtual cluster’s default scheduler will be used instead of the hosts, which means all scheduling will occur inside the virtual cluster. Note that his configuration has moved from advanced.virtualScheduler to controlPlane.distro.k8s.scheduler.enabled .

This feature and it’s various options give greater scheduling freedom to both users who only have access to the virtual cluster and to platform teams who would like to extend certain schedulers to their virtual clusters.

Other Changes

Notable Improvements

• Class objects synced from the host can now be filtered by selectors or expressions. More notably, they are now restricted based on that filter. If a user attempts to create an object referencing a class which doesn’t match with the selectors or expressions, meaning it was not imported into their virtual cluster, then syncing it to the host will now fail. This includes ingress-class, runtime-class, priority-class, and storage-classes.

• Our embedded etcd feature will now attempt to auto-recover in situations where possible. For example if there are three etcd-nodes and one fails, but there are still two to maintain quorum, the third node will be auto-replaced.

Breaking Changes

• The k0s distro has been fully removed from vCluster. See the announcement in our v0.25 changelog for more information.

• As noted above, the experimental multi-namespace-mode feature has been removed.

Fixes & Other Changes

• Please note that the location of the config.yaml in the vCluster pod has moved from /var/vcluster/config.yaml to /var/lib/vcluster/config.yaml.

• v0.25 introduced a slimmed down images.txt asset on the release object, with a majority of images moving into images-optional.txt In v0.26 we have additionally moved etcd, alpine, and k3s images into the optional list, leaving the primary list as streamlined as possible.

• The background-proxy image can now be customized, as well as the syncer’s liveness and readiness probes.

• Several key bugs have been fixed, including issues surrounding vcluster connect, creating custom service-cidrs, and using vcluster platform connect with a direct cluster endpoint.

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