vNode limitations

vNode has some limitations based on its design and dependency on kernel and container runtime features.

Kernel and runtime compatibility

vNode depends on certain Linux kernel features and direct integration with containerd. It does not support older kernels or alternative runtimes:

• Requires Linux kernel 6.1 or later. Older kernels, including any using cgroups v1, are not supported.
• Supports only the containerd runtime. Requires containerd version 1.7 or 2.0.
• Does not support cri-o, cri-dockerd, or Docker Engine.

Kubernetes API limitations

vNode currently does not support a few Kubernetes features that depend on privileged or low-level host interactions.

• spec.containers[*].hostPort and hostIP are not supported. Pods cannot expose host ports via vNode.
• Installing device drivers or loading eBPF programs inside a vNode is not supported.
• Running an NFS server within a vNode is not supported.
• The mknod system call is not supported inside vNodes. Pods that attempt to create special device files will fail.
• Nested user namespaces are not supported.

Host device access

When accessing host-mounted devices inside a vNode:

• Devices appear owned by nobody:nogroup
• These devices require read/write permissions for non-owners to be usable by workloads

You must manually adjust permissions on the host if workloads need to interact with these devices.

Runtime behavior

The internal runtime model for vNode impacts how workloads are managed and restarted.

• Restarting the vNode runtime causes all vNodes and their workloads to restart
  • This applies even if only one vNode or workload needs to be updated
  • Plan for this limitation in production or highly available environments