Kuasar is an efficient container runtime that provides cloud-native, all-scenario container solutions by supporting multiple sandbox techniques. Written in Rust, it offers a standard sandbox abstraction based on the sandbox API. Additionally, Kuasar provides an optimized framework to accelerate container startup and reduce unnecessary overheads.

Supported Sandboxes
Why Kuasar?
Kuasar Architecture
Performance
Quick Start
Contact
Contributing
License

Supported Sandboxes

| Sandboxer | Sandbox | Status | |------------|------------------|-----------------| | MicroVM | Cloud Hypervisor | Supported | | | QEMU | Supported | | | Firecracker | Planned in 2025 | | | StratoVirt | Supported | | Wasm | WasmEdge | Supported | | | Wasmtime | Supported | | App Kernel | Quark | Supported | | runC | runC | Supported |

Why Kuasar?

In the container world, a sandbox is a technique used to separate container processes from each other, and from the operating system itself. After the introduction of the Sandbox API, sandbox has become the first-class citizen in containerd. With more and more sandbox techniques available in the container world, a management service called "sandboxer" is expected to be proposed.

Kuasar supports various types of sandboxers, making it possible for users to select the most appropriate sandboxer for each application, according to application requirements.

Compared with other container runtimes, Kuasar has the following advantages:

Unified Sandbox Abstraction: The sandbox is a first-class citizen in Kuasar as the Kuasar is entirely built upon the Sandbox API, which was previewed by the containerd community in October 2022. Kuasar fully utilizes the advantages of the Sandbox API, providing a unified way for sandbox access and management, and improving sandbox O&M efficiency.
Multi-Sandbox Colocation: Kuasar has built-in support for mainstream sandboxes, allowing multiple types of sandboxes to run on a single node. Kuasar is able to balance user's demands for security isolation, fast startup, and standardization, and enables a serverless node resource pool to meet various cloud-native scenario requirements.
Optimized Framework: Optimization has been done in Kuasar via removing all pause containers and replacing shim processes by a single resident sandboxer process, bringing about a 1:N process management model, which has a better performance than the current 1:1 shim v2 process model. The benchmark test results showed that Kuasar's sandbox startup speed 2x, while the resource overhead for management was reduced by 99%. More details please refer to Performance.
Open and Neutral: Kuasar is committed to building an open and compatible multi-sandbox technology ecosystem. Thanks to the Sandbox API, it is more convenient and time-saving to integrate sandbox technologies. Kuasar keeps an open and neutral attitude towards sandbox technologies, therefore all sandbox technologies are welcome. Currently, the Kuasar project is collaborating with open-source communities and projects such as WasmEdge, openEuler and QuarkContainers.

Kuasar Architecture

arch

Sandboxers in Kuasar use their own isolation techniques for the containers, and they are also external plugins of containerd built on the new sandbox plugin mechanism. A discussion about the sandboxer plugin has been raised in this Containerd issue, with a community meeting record and slides attached in this comment. Now this feature has been put into 2.0 milestone.

Currently, Kuasar provides three types of sandboxers - MicroVM Sandboxer, App Kernel Sandboxer and Wasm Sandboxer - all of which have been proven to be secure isolation techniques in a multi-tenant environment. The general architecture of a sandboxer consists of two modules: one that implements the Sandbox API to manage the sandbox's lifecycle, and the other that implements the Task API to handle operations related to containers.

Additionally, Kuasar is also a platform under active development, and we welcome more sandboxers can be built on top of it, such as Runc sandboxer.

MicroVM Sandboxer

In the microVM sandbox scenario, the VM process provides complete virtual machines and Linux kernels based on open-source VMMs such as Cloud Hypervisor, StratoVirt, Firecracker and QEMU. All of these vm must be running on virtualization-enabled node, otherwise, it won't work!. Hence, the vmm-sandboxer of MicroVM sandboxer is responsible for launching VMs and calling APIs, and the vmm-task, as the init process in VMs, plays the role of running container processes. The container IO can be exported via vsock or uds.

The microVM sandboxer avoids the necessity of running shim process on the host, bringing about a cleaner and more manageable architecture with only one process per pod.

vmm

Please note that only Cloud Hypervisor, StratoVirt and QEMU are supported currently.

App Kernel Sandboxer

The app kernel sandbox launches a KVM virtual machine and a guest kernel, without any application-level hypervisor or Linux kernel. This allows for customized optimization to speed up startup procedure, reduce memory overheads, and improve IO and network performance. Examples of such app kernel sandboxes include gVisor and Quark.

Quark is an application kernel sandbox that utilizes its own hypervisor named QVisor and a customized kernel called QKernel. With customized modifications to these components, Quark can achieve significant performance.

The quark-sandboxer of app kernel sandboxer starts Qvisor and an app kernel named Qkernel. Whenever containerd needs to start a container in the sandbox, the quark-task in QVisor will call Qkernel to launch a new container. All containers within the same pod will be running within the same process.

quark

Please note that only Quark is currently supported.

Wasm Sandboxer

The wasm sandbox, such as WasmEdge or Wasmtime, is incredibly lightweight, but it may have constraints for some applications at present. The wasm-sandboxer and wasm-task launch containers within a WebAssembly runtime. Whenever containerd needs to start a container in the sandbox, the wasm-task will fork a new process, start a new WasmEdge runtime, and run the Wasm code inside it. All containers within the same pod will share the same Namespace/Cgroup resources with the wasm-task process. wasm

Runc Sandboxer

Except secure containers, Kuasar also has provide the ability for runC containers. In order to generate a separate namespace, a slight process is created by the runc-sandboxer through double folked and then becomes the PID 1. Based on this namespace, the runc-task can create the container process and join the namespace. If the container need a private namespace, it will unshare a new namespace for itself.

wasm

Performance

The performance of Kuasar is measured by two metrics:

End-to-End containers startup time.
Process memory consumption to run containers.

We used the Cloud Hypervisor in the benchmark test and tested the startup time of 100 PODs under both serial and parallel scenario. The result demonstrates that Kuasar outperforms open-source Kata-containers in terms of both startup speed and memory consumption.

For detailed test scripts, test data, and results, please refer to the benchmark test.

Quick Start

Prerequisites

1. OS

The minimum versions of Li

Kuasar

Install / Use

README

Contents