Kuasar: An efficient multi-sandbox container runtime | Hacker News Reader

Kuasar: An efficient multi-sandbox container runtime

github.com

4 pointskwang01264 comments

The link to containerd Sandbox API was super interesting & helpful. https://github.com/containerd/containerd/issues/4131

Interestingly had a bunch of different Sandboxerd within. Wasm, microvm with common best-in-class tech (Firecracker, Cloud Hypervisor, qemu), & full KVM for unikernel systems (specifically atm a project Quark). runC is shown but not listed as an implementation. I had kind of thought this was specifically for Rust payloads but they just means written in Rust.

I am a bit surprised to hear the wasm model is forking. This system definitely values security & manageability so it shouldn't be surprising I guess. But it still feels like it might entail more loading & re-loading code to spawn than what I think of as wasm's strong point, where a new isolate can be created from a snapshot easily. Maybe the wasm runtime is more primed before forking than i realize, but the way they talk about forking then creating a runtime makes me think this isn't targeting lots of shortived instances.

Performance is exceedingly good versus the industry standard & very well tuned Kata Containers. 360ms Vs 850ms boot. Even better in parallel boots. Huge wins on memory overhead since there's a single manager process instead of per instance shims.

Neat project. I hope we see more of this & others. I'm curious who the team is & what else they are up to. Whoa... Huawei, Agricultural Bank of China, OpenEuler, are among the top listed users.

It is very insightful to point out that forking a wasm runtime may not be the best choice, actually this is because we chose the WasmEdge as our first supported wasm runtime, and it do not support redirecting the standard io fds, so we can only fork a new process and redefine the stdin/stdout/stderr to the named pipe. we already submit an issue to WasmEdge community, we may change the fork way to starting directly. For Wasmtime (we will support it later), there is no such constraint, and we will start runtime directly.

As someone in the industry, I'm aware that Shim V2 is no longer the best option for pod management due to its poor reliability and high memory and CPU consumption. The long call-chain often results in data inconsistency, jammed IO or dead shim. Despite these challenges, it's difficult to push for a new approach. That's why I'm excited to see this extraordinary project that addresses the pain points of Shim V2 with its Sandbox API extension. The architecture description promised better performance, and the benchmarks in the repo exceeded my expectations. Well done, folks!

I'm also glad that the framework is open, allowing for engagement with various sandbox technologies. Additionally, the removal of the pause container is a significant improvement. Cheers!

Really intresetd in the management model that Kuasar has proposed.

It's fascinating to see how the shim process has evolved over time with the container form, from one container corresponding to one shim, to one Pod corresponding to one shim, and now to Kuasar's innovative proposal of one type of Pod corresponding to one sandboxer process, meaning N pods corresponding to one process. The evolution of the model has reduced the number of processes to only one, which has consequently reduced the memory consumption and helped with startup time.

Overall, I find this project to be quite exciting, and I'm hoping that the model put forward by Kuasar can be widely adopted and applied in production.

Reply on news.ycombinator.com