Architecture

vNode executes each pod within a lightweight vNode sandbox, similar to how Kubernetes executes pods in a pod sandbox. This vNode sandbox basically wraps the workload in another vm-like layer, which is secured by seccomp filters and a linux user namespace to improve isolation and security.

The vNode itself stays empty and for the pod the vNode looks like the actual node running it. A pod can use typically insecure features such as hostPID, hostPaths or privileged now only within the vNode without actually gaining any additional capabilities on the actual host node. Since the vNode is mostly a logical wrapper for the pod there is basically no overhead running it and since no actual virtualization technology such as KVM or Hyper-V is used everything stays bare-metal and has native speed.

On the linux namespace level, the vNode is just adding another set of layers in between the pod and the actual node. It's also possible to share a single vNode for multiple pods, which is useful in scenarios such as vCluster, where multiple pods belong to the same tenant. Using privileged workloads such as prometheus or fluentd can then only see the pods they should see instead of having full access to the actual underlying node.

Components

vNode runtime consists of multiple components:

• vNode Manager
• vNode RunC
• vNode Containerd Shim

vNode Manager

This is the main binary of vnode-runtime and is a multi-call binary (similar to busybox) that serves the following commands:

1. vnode-cni:
   • Is called by containerd and is used to remount the network namespace into the vNode usernamespace
   • Calls the vNode CNI after the host CNI is finished
2. containerd-shim-vnode-v2:
   • Is called by containerd directly and just returns the socket path of the vnode-manager
   • Also has a delete command that does nothing, but is needed for containerd
3. vnode-manager:
   • Coordinator of vNode runtime
   • Embeds sysbox-fs and allows custom proc & sys filesystems. Also intercepts syscalls via a seccomp filter
   • Acts as a central shim for vNode and vNode workloads and manages the vnode shim
   • Manages uid & gid mappings

vNode RunC

This binary is used to start a vNode container:

containerd -> vnode-manager -> vnode-containerd-shim-runc-v2 -> vnode-runc

vNode runc is a fork of RunC that changes the following:

• Integrate vNode manager into runc
• Fix problems with linux user namespaces
• Removed support for cgroups v1

vNode Containerd Shim

This is the shim that is used to spin up new vNodes:

containerd -> vnode-manager -> vnode-containerd-shim-runc-v2 -> vnode-runc