VirtualNode customizations

Since Liqo 1.0 it is possible to granularly customize each virtualnodes (and their associated virtual-kubelets), thanks to the VirtualNode CR. This page will describe how to tune the VirtualNode resource according to the user’s needs or use cases.

Offloading Patch

The VirtualNode CR allows to configure a set of patches to apply to all offloaded pods or reflected resources by its virtual-kubelet. We call this feature OffloadingPatch and it is configurable directly on the VirtualNode spec.

In particular, it is possible to specify custom NodeSelector, Tolerations, and Affinity that will applied to remote offloaded pods. For example, with node selectors, you can target specific pools of nodes on the provider cluster. Another feature is the possibility to disable the reflection of specific labels and annotations on all reflected resources, as described here. The virtual-kubelet enforces the effective offloading patch, published by the controller in the status.effectiveOffloadingPatch field: the spec’s one, with the labels and annotations not to be reflected merged with the ones specified in the referenced VkOptionsTemplate.

Note

If any field of the offloading patch changes, the virtual-kubelet deployment is restarted.

Virtual-kubelet options

To allow maximum flexibility, it is possible to configure the option to pass to the virtual-kubelet, for each VirtualNode CR. By default it is created in the namespace liqo a default VkOptionsTemplate CR, containing the default settings for the virtualnodes (some fields are templated from Helm values). When a user creates a new VirtualNode it can customize the virtual-kubelet options by referencing a custom template in the .spec.vkOptionsTemplateRef field. If not specified, the default template installed by Liqo is used.

The VkOptionsTemplate contains a lot of possible customizations. Some of the most important allows to:

Note

The virtual-kubelet deployment is deterministically rendered by the virtualnode controller from the referenced VkOptionsTemplate. Any change to the template (e.g., a new pod image released during a Liqo upgrade) is automatically propagated to all the virtual nodes referencing it, and their virtual-kubelet deployment is updated accordingly.

Note

The .spec.template field of the VirtualNode CR (which used to embed the rendered virtual-kubelet deployment) is deprecated and ignored: if set, it is removed by the controller.

Disable creation of the k8s Liqo node

When you create a VirtualNode CR, automatically an associated K8s node to schedule workloads is created. In some use cases, the user may want to only use the resource reflection to propagate resources (e.g., Services, ConfigMaps, Secrets, etc..) on remote clusters, while not needing a node to schedule workloads. Even if the k8s node is absent, the virtual-kubelet pod is able to reflect on the remote cluster the above-mentioned resource, as they are not tied to a local k8s node. In this case, it may be convenient to completely disable the creation of the K8s node.

This feature can be set by customizing the createNode field in the VirtualNode CR or by referencing a VkOptionsTemplate with the createNode modified. When the field is not set on the VirtualNode CR, the value specified in the referenced VkOptionsTemplate is used, and changes to the template are automatically propagated.

Disable network condition check

By default, Liqo checks periodically if the networking between the consumer and provider is established correctly. When there are network issues, the virtual-kubelet detects this problem and will update the NetworkUnavailable node conditions. This event makes the k8s scheduler prevent scheduling pods on this node. If you do not need this check you can completely disable the update of this condition, and the condition will be always ready, allowing the user to schedule pods independently from the state of the network.

This feature can be set by customizing the disableNetworkCheck field in the VirtualNode CR or by referencing a VkOptionsTemplate with the disableNetworkCheck modified. When the field is not set on the VirtualNode CR, the value specified in the referenced VkOptionsTemplate is used, and changes to the template are automatically propagated.

Note

In case the network module is not enabled for this pair of clusters (or disabled globally), Liqo will always set the network condition to ready (or equivalently not putting it at all). As a consequence pods can always be scheduled on the virtual node indipendently from the underlying network technology or connectivity.