What is a Krustlet? This article explains a new approach to running your applications in Kubernetes using WebAssembly instead of containers.
Kubernetes System Architecture
Kubernetes is essentially a tool that allows scaling applications by mapping containers, executable software units, onto a number of hosts, so-called worker nodes. Usually, a Kubernetes cluster is controlled by one or more master nodes, which is the brain of the cluster.
The master node is the interface for the software engineer to provide a desired state to the cluster via the API server. At the same time, the master node requires the possibility to run containers on the worker nodes in order to fulfill the config provided by the software engineer. It does this by passing a pod specification to the worker node.
The worker node needs to interpret the configuration and implement it in its container runtime, which means pulling the container image, running it, and checking the health of the container. The worker node does this by running a component called Kubelet. The Kubelet is a component that acts like a translator, it translates the pod specification into the actions that need to be executed on the container runtime.
Recap: The Kubelet is a component installed on a worker node. It receives pod specifications and runs the container accordingly in the container runtime.
From Kubelet to Krustlet
WebAssembly is a binary format that allows low-level access to the browser. You can take a programming language and compile it into a powerful portable binary format that runs almost at native speed. WebAssembly was built to run alongside JavaScript in the browser. Every developer who has worked on the Web knows a key feature of developing browser applications is to sandbox your application, meaning your application does only interact and access data within your application.
You would not want your banking website to share the data with your Chat provider for instance. This idea of sandboxing was built into WebAssembly and has been battle-tested extensively. The potential of creating portable software packages that can be created from many different programming languages is not only helpful in the browser. However, to build applications outside of the browser, you need the capabilities to interact with the underlying system. Those capabilities were specified in the WebAssembly System interface, short WASI. One WASI implementation is wasmtime, a standalone runtime for WebAssembly. Instead of the browser, you use wasmtime to run your code and interact with the underlying system, e.g. accessing files, and networking (even though this is still tricky).
Recap: The Krustlet is a component installed on a worker node. It receives pod specifications and runs a WebAssembly binary accordingly in the WebAssembly Runtime. WebAssembly is a powerful sandboxed portable binary format that aims to achieve the slogan “build once, run anywhere“.
WebAssembly vs Containers
Based on the information above, we can see that WebAssembly is a way of building portable software units and running them isolated in their sandbox, which is essentially something that containers already offer. Containers allow packing software and sandboxing on an operating system level. While this gives developers a lot of flexibility, it comes with an overhead.
The packaging of WebAssembly is much more lightweight, as containers unfortunately often include unnecessary system dependencies, which increase the image size and create a bigger attack surface for hackers. In addition to the smaller memory and storage footprint, it promises faster startup and shutdown times. It should be noted that Krustlet is still under heavy development, but it has the potential to be particularly interesting in IoT because the lightweight, portable character fits fantastically into a resource-constrained problem domain.
Summary: Since Krustlets can be swapped out for Kubelets and vice versa, the question in the future will not be should I run my Kubernetes cluster with containers or WebAssembly, instead it will depend on the context. Those are complementary solutions that can run alongside each other. Based on the requirements of the underlying hardware and the use case you might extend your cluster with a Krustlet or replace a Krustlet with a Kubelet, when you need more control on the OS side.
