Open Source Rust Container Management Software

Kata Containers is an open source container runtime, building lightweight virtual machines that seamlessly plug into the container ecosystem. Kata Containers is an open source community working to build a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense. Since launching in December 2017, the community successfully merged the best parts of Intel Clear Containers with Hyper.sh RunV and scaled to include support for major architectures including AMD64, ARM, IBM p-series, and IBM z-series in addition to x86_64. Kata Containers also supports multiple hypervisors including QEMU, Cloud-Hypervisor, and Firecracker, and integrates with the containerd project among others.

Microsoft eXecution Containers, or MXC, is a sandboxed code execution system for running untrusted code across Windows, Linux, and macOS. It is designed for model outputs, plugins, tools, and other code that needs controlled execution boundaries. The project provides a unified JSON configuration schema and a TypeScript SDK while supporting multiple containment backends. Its backends include process containers, Windows Sandbox, LXC, Bubblewrap, Seatbelt, microVM-based options, Hyperlight, IsolationSession, and WSL-related containment. MXC focuses on policy-driven isolation for filesystems, networking, process execution, and runtime behavior. It is especially useful for AI tool platforms, plugin ecosystems, agent runtimes, and developer products that need safer execution of generated or third-party code.

youki is an implementation of the OCI runtime-spec in Rust, similar to runc. Rust is one of the best languages to implement the oci-runtime spec. Many very nice container tools are currently written in Go. However, the container runtime requires the use of system calls, which requires a bit of special handling when implemented in Go. This is too tricky (e.g. namespaces(7), fork(2)); with Rust, it's not that tricky. And, unlike in C, Rust provides the benefit of memory safety. While Rust is not yet a major player in the container field, it has the potential to contribute a lot: something this project attempts to exemplify. youki has the potential to be faster and use less memory than runc, and therefore works in environments with tight memory usage requirements. Here is a simple benchmark of a container from creation to deletion.

A simple terminal dashboard for Kubernetes built with Rust. KDash only offers a view of the resources with a focus on speed and UX. Really, if something is slow or has bad UX then please raise a bug. Hence the UI/UX is designed to be more user-friendly and easier to navigate with contextual help everywhere and a tab system to switch between different resources easily.

kubie is an alternative to kubectx, kubens, and the k on prompt modification script. It offers context switching, namespace switching, and prompt modification in a way that makes each shell independent from others. It also has support for split configuration files, meaning it can load Kubernetes contexts from multiple files. You can configure the paths where Kubie will look for contexts, see the settings section. Kubie also has other nice features such as kubie exec which allows you to execute commands in a context and a namespace without having to spawn a shell and kubie lint which scans your k8s config files for issues and informs you of what they are.

A Rust client for Kubernetes in the style of a more generic client-go, a runtime abstraction inspired by controller-runtime, and a derive macro for CRDs inspired by kubebuilder. Hosted by CNCF as a Sandbox Project. These crates build upon Kubernetes API machinery + API concepts to enable generic abstractions. These abstractions allow Rust reinterpretations of reflectors, controllers, and custom resource interfaces so that you can write applications easily.

A small command-line utility to wait for other docker images to be started while using docker-compose (or Kubernetes or docker stack or whatever). This utility should be used in the docker build process and launched before your application starts. Your application "MySuperApp" uses MongoDB, Postgres and MySql and you want to be sure that, when it starts, all other systems are available.