Skip to main content

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.

Informational limitations​

The following limitations apply to the runtime itself and serve informational purposes:

  • Devices /dev/random and /dev/urandom are directly mapped into containers. This doesn't have a security impact and is just an informational limitation.
  • Certain paths within the container e.g. /proc/config.gz or /proc/buddyinfo are not emulated and might expose certain host information.
  • Certain paths are shared between a vNode and the actual workload inner container, e.g. /dev/shm in the inner container and /run/containerd/io.containerd.grpc.v1.cri/sandboxes/[...]/shm in the outer container. This is done by design since the paths are first mounted to the outer and then inner container.