Deis Labs has released Krustlet, an open-source Kubernetes kubelet written in Rust to run web assembly workloads within Kubernetes. Krustlet's initial version is somewhat of a proof of concept, as it doesn't have support for features like pod events or Init Containers yet. Applications must implement the WebAssembly system interface (WASI) as Krustlet only runs WebAssembly containers.
WebAssembly, also known as WASM, is a binary instruction format for a stack-based virtual machine
that is optimized for execution speed with a small footprint and is also an open web standard. Although WASM is known for its applications in the browser like the Blazor Framework from Microsoft, Mozilla recently has launched WASI so that compilers target this interface and not the operating system. Having WASM on the server-side gives users another alternative to Docker as a container runtime in Kubernetes, and this is what Krustlet is offering.
Additionally, from the security perspective, Lin Clark explained at the Mozilla blog that if you're calling a function that needs to access a file, you have to pass in a file descriptor, which has permissions attached to it.
Thus, WASI makes it possible to have sandbox environments with explicit permissions only, which improves security in containers.
Source: "Standardizing WASI: A system interface to run WebAssembly outside the web."
Krustlet's initial version includes support for a basic pod lifecycle, downward API to expose pod or container fields, environment variables, and volumes from the host, secrets, or configMaps. However, Kurstlet isn't ready for production use yet. For instance, Krustlet doesn't have support for ARM processors, Init Containers, cloud provider volumes, pod events, pod conditions, and runs partially in Windows. Additionally, Krustlet uses providers to interact with a given runtime, supporting waSCC and WASI initially from the growing list of WASM runtimes.
At its core, Kubelet is an implementation of the Kubernetes kubelet in Rust. It listens to the Kubernetes API for any new pod request to run a WASI-based application to the cluster, as long as it matches a node selector. Therefore, to run applications on a Krustlet node users can use taints, tolerations, and node selectors. Additionally, users must generate a WebAssembly binary for the application like using clang if the application is written in C or cargo if it's written in Rust. Then, users have to pack and push the container image to a container registry using the wasm-to-oci open-source project. To deploy the application, users need to define a Kubernetes manifest that includes the tolerations, like the following example:
apiVersion: v1
kind: Pod
metadata:
name: wasm-app
spec:
containers:
- name: wasm-app
image: registry/wasm-app:v1.0.0
tolerations:
- key: "krustlet/arch"
operator: "Equal"
value: "wasm32-wasi"
effect: "NoExecute"
A typical workflow to build, push, and deploy applications to a Kurstlet node would be as follows:
clang main.c -o demo.wasm
wasm-to-oci push demo.wasm registry/wasm-app:v1.0.0
kubectl apply -f wasm-app.yaml
For anyone who wants to use Krustlet in an existing Kubernetes cluster, the project has guides on how to spin up a worker node in different cluster deployments like Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), MicroK8s, Minikube, and others.
Krustlet is in active development, and every release comes with a full list of issues they plan to fix next. For instance, Krustlet's latest version is v0.3.0, and in this release, users can see what's new, what's coming next, and the list of known issues they plan to fix. Currently, for upcoming versions, Krustlet is working on supporting missing features for networking, cloud storage volume providers, and certain pod conditions, among others.
If the community is interested in learning or contributing to the project, they can open an issue in GitHub or join the weekly call on Zoom on Mondays.
