Over a year ago, we introduced Krustlet, a kubelet implementation that enables users to run both WebAssembly and traditional container workloads in the same Kubernetes cluster. If WebAssembly is new to you, check out this section below.
We started the project with two clear goals in mind:
- make it easy to deploy WebAssembly (and WASI) workloads on Kubernetes
- contribute to the cloud native ecosystem by building core architectural pieces of Kubernetes in Rust, a memory-safe systems programming langauge.
Today we are extremely excited to announce that Krustlet was accepted in the Cloud Native Computing Foundation (CNCF) as a Sandbox project, alongside Krator, a Kubernetes Rust state machine operator framework written in Rust. In addition, we’re celebrating the first alpha release of Krustlet 1.0 – v1.0.0-alpha.1.
As we approach the final 1.0 release, this marks the start of API and feature stability for Krustlet and strong backwards compatibility guarantees.
The 1.0 roadmap
Krustlet enables developers to build and run WebAssembly and WASI modules on Kubernetes. Today, you can take advantage of Kubernetes features such as pods, secrets, init containers, or volume mounts, and in the next couple of weeks, we will continue to stabilize the current API and feature set. Here are the specific guarantees for each type of release:
- Alpha: No backwards compatibility or API guarantees. However, we do not intend to do any major breaking changes, but we reserve the right to should the need arise
- Beta: Similar to alpha, we will not likely be breaking anything. The one exception would be to solve any bugs, security issues, or missing features found during beta releases
- RC: Backwards compatibility and API stability guarantees will go into effect. Breaking changes will only be considered for showstopper bugs or security issues
- 1.0.0+: No breaking changes will be allowed nor anything that changes backwards compatibility. The major exception to this is for security issues where breaking changes can be allowed based on maintainer consensus. Any other breaking changes will be deferred to a future 2.0 release
You can get started with Krustlet by following the official documentation.
What does 1.0 even mean?
“But wait,” you might ask, “how is this 1.0 when you are still missing things like full Kubernetes networking?” We chose to move Krustlet to 1.0 because using it as a Kubelet is now stable enough to actually build real things on top of. WebAssembly is still rapidly evolving and so there are still rough edges and other problems to work through. It would be a disservice to the community to not stabilize what we have so other people can keep learning about and innovating with WebAssembly. Additionally, there are others in the Rust community who are building other types of Kubelets that have nothing to do with WebAssembly and we owe it to them to have a stable version on which to build their own projects.
So, what does this being 1.0 actually mean? First and foremost, it means stability and backwards compatibility guarantees, as mentioned above. This means that people can start to build applications built to run on Krustlet (or with tooling from Krustlet) without fear of a constantly evolving API. This includes ourselves, where we have plans to create a WAGI Krustlet provider. It also means that the WebAssembly bits are to the point you can build something with them – not everything you can build with containers, but you can build something real. We will continue to update and add features as WebAssembly and WASI mature.
The tl;dr? The APIs are stable and the project is mature enough to use without it falling over on itself constantly. WebAssembly? Not fully featured yet, but ready to be experimented with and used, even if it is a bit bumpy at times.
WebAssembly, WASI, and containers
WebAssembly (Wasm) is an open standard for a new binary instruction format, and can used as a compilation target for several popular programming languages, such as C and C++, Rust, Go (and TinyGo), Swift, or C# (Blazor), as well as new languages specifically built to target WebAssembly, such as Grain or AssemblyScript (with multiple ongoing efforts to add support for WebAssembly for other extremely popular ecosystems, such as Python, with Pyodide, or Kotlin). Wasm implements a sandboxed execution environment – specifically, a running instance has no access to the host runtime’s memory or to another instance’s memory, nor does it have access to any host API without the runtime explicitly providing it.
While originally built for the browser, WebAssembly provides a fast, scalable,
and portable way of executing the same code regardless of operating system or
CPU architecture. The new WebAssembly System Interface (WASI) provides a
capability-oriented set of APIs designed to standardize the execution of
WebAssembly outside the browser, together with a common layer and set of
primitives that running instances can use to interact with their runtimes, while
maintaining the sandbox promised by WebAssembly. For example, the included
Krustlet provider (krustlet-wasi) is built using the reference implementation
for WASI, Wasmtime. There are also other providers out in the
community and new providers we are working on (or are polishing) such as the
wasmCloud provider and the WAGI provider.
While containers and WebAssembly modules can be used for some of the same workloads, we believe they are complementary technologies – WebAssembly’s true OS and architecture portability, compact format, and extremely fast startup, together with the flexibility of containers as a full operating system sandbox, used together through Krustlet, allow developers to choose the right tool for the job.
Bridging the cloud native and Rust ecosystems
Besides running WebAssembly modules in Kubernetes, the other major goal we set out for this project was to contribute to the cloud native ecosystem by building core Kubernetes components in a programming language other than Go.
Krustlet and Krator, together with other libraries and components we are building with the community (such as a library for handling OCI artifacts from Rust), show how Rust can be a great alternative for building high performance and secure cloud native components.
So what now?
We need your help to test things out. Download Krustlet, give it a whirl in your different clusters, or file bugs. Any of these things will help us put the final polish on the 1.0 release!
We want to thank the many people who have contributed to the project, alongside the CNCF and the WebAssembly community – your help and excitement have been invaluable!
Appendix: What? No Networking?!
After many discussions, we have decided that CNI and 100% native Kubernetes network support will not be part of the 1.0 release. Networking implementations vary wildly between different Krustlet providers and it would be difficult and unwise to try and define a common abstraction at this time. For example, wasmCloud connects using a system called a “lattice” which can consist of an arbitrary graph of connected hosts. Whereas the CRI provider relies on the CNI spec implementations built in to many Kubernetes distributions. Not only are we at a point where we need to understand how more complex networking should work, but the same discussions involve things like sidecars, service meshes, and so on. As a result, we decided to let you handle your own networking here, which you can do, while the community understands what's the best path forward with these more complex interactions.
Our hope is that once we have several different networking examples from various providers, it will be easier to add in a common abstraction at this time. Waiting on that information would only introduce additional delay for releasing Krustlet as an otherwise stable and production-ready (though still bleeding edge) project.