The Benefits of Containerless Kubernetes: A Deep Dive into WebAssembly Workloads
Containerless Kubernetes is a relatively new concept that has gained significant attention in recent times. It refers to the ability to run Kubernetes workloads without the need for containers. Instead, workloads are compiled directly to machine code using WebAssembly (WASM), which provides a lightweight, portable, and load-time-efficient way to run code.
WebAssembly
WebAssembly is a binary instruction format that can run on any platform that supports it. It is designed to be fast, portable, secure, and interoperable. WebAssembly can be compiled from various programming languages, such as C/C++, Rust, Go, and more. WebAssembly can also run in web browsers, as well as standalone environments like Wasmtime or Wasmer.
Benefits of Using WebAssembly on Kubernetes
WebAssembly has some advantages over containers when it comes to running workloads on Kubernetes:
- Smaller size: are typically much smaller than container images, which means faster downloads, deployments, and scaling
- Faster startup: can start executing almost instantly, unlike containers that need to pull images, unpack layers, and run initialization scripts
- Better isolation: runs in a sandboxed environment that prevents them from accessing the host system or other modules. This improves security and reduces the attack surface
- Higher density: runs on the same host without interfering with each other, which means more efficient resource utilization and lower costs
- Easier portability: runs on any platform that supports WebAssembly, regardless of the underlying architecture or operating system. This simplifies cross-platform compatibility and migration
Challanges
- Lack of tooling: There are not many tools available for building, testing, debugging, and monitoring WebAssembly workloads on Kubernetes. This makes the development and operation process more difficult and time-consuming
- Limited compatibility: Not all Kubernetes features and APIs are compatible with WebAssembly workloads. For example, you may not be able to use health checks, probes, secrets, config maps, or volumes with WebAssembly pods
- Limited functionality: WebAssembly modules have limited access to system resources and capabilities. For example, you may not be able to use networking, file system, or threading APIs with WebAssembly modules
- Limited performance: WebAssembly modules may not be able to achieve the same level of performance as native or containerized applications. For example, you may experience higher latency, lower throughput, or higher memory consumption with WebAssembly modules
Workflow
In the context of containerization, a container image typically consists of several layers. The base image provides the foundation for the container, containing the runtime dependencies necessary for the application to function properly. The application layer, on the other hand, holds the source code and any other application-specific dependencies.
To optimize the container image, we can create a separate runtime image that only contains the runtime dependencies. This allows us to attach the application layer as a volume, enabling us to rebuild the application layer independently of the container image. This approach ensures that we can update the application layer without the need to rebuild the entire container image, promoting efficiency and streamlining the development process.
Steps
- Install Krustlet on a node in the cluster: use a script provided by the Krustlet project to install it as a systemd service, or we can run it manually as a binary. Also register the node with the Kubernetes API server, using a bootstrap token and a certificate signing request (CSR)
- Build a WebAssembly module: using any language and toolchain that supports Wasm compilation: Rust, C/C++, Go, AssemblyScript, or any other language that can target Wasm. Also package the module as an OCI image, using a tool like
wasm-to-ocior ORAS - Deploy the WebAssembly module: as a pod on the cluster, using a
YAMLmanifest file that specifies the image name, the resources, and the environment variables. Usekubectlor any other Kubernetes client to apply the manifest file to the cluster - Monitor and troubleshoot: WebAssembly pod using the standard Kubernetes tools, such as
kubectl logs,kubectl exec,kubectl describe, andkubectl get
Deployment Options
Wasm-Compatible Container Runtime
Use a container runtime that supports running Wasm modules as containers, such as Krustlet or WasmEdge. This way, you can use the same tools and workflows that you use for regular containers, such as kubectl, Helm.
You can also leverage the existing Kubernetes features and resources, such as pods, services, deployments.
Wasm Host Runtime
Use a host runtime that can execute Wasm modules directly on the host system, such as Wasmer or Wasmtime. This way, you can avoid the overhead of running a container engine and benefit from the native integration with the host OS and hardware.
You can also use tools like KubeVirt or K3s to run a lightweight Kubernetes cluster on top of the host runtime.
Wasm Application Framework
Use a framework that provides a high-level abstraction for developing and deploying Wasm applications on Kubernetes, such as Suborbital Reactor.
This way, you can focus on the business logic of your application and let the framework handle the details of packaging, distributing, and running your Wasm modules.
Custom Runtime Class
Use a custom runtime class that leverages a Wasm runtime like Wasmtime or Wasmer. A runtime class is a Kubernetes feature that allows you to specify how a pod should be executed on a node.
By using a custom runtime class, you can bypass the container runtime interface (CRI) and run WebAssembly modules directly on the node.
Service Mesh
Use a service mesh like Istio or Linkerd. A service mesh is a layer of infrastructure that provides observability, security, and reliability for microservices.
By using a service mesh, you can inject WebAssembly modules into the data plane of your cluster and perform various tasks like routing, filtering, logging, tracing, and more.
Use Cases
- Serverless Computing: WebAssembly workloads can be used in serverless computing environments. By running WebAssembly workloads on Kubernetes, organizations can leverage the scalability and cost efficiency of serverless architectures while benefiting from the performance and security advantages of WebAssembly
- Edge Computing: WebAssembly workloads can be deployed at the edge of the network, closer to end-users or devices. By running WebAssembly workloads on Kubernetes clusters deployed at the edge, organizations can process data and execute code in real-time, reducing latency and enhancing the overall user experience
- Isolation and Security: WebAssembly workloads are executed within a sandboxed environment, ensuring strong isolation and security. By running WebAssembly workloads on Kubernetes, organizations can take advantage of Kubernetes’ built-in security features, such as container isolation and resource limits, to further enhance the security of their workloads
- Language Flexibility: WebAssembly supports multiple programming languages, allowing organizations to leverage existing codebases and libraries. By running WebAssembly workloads on Kubernetes, organizations can choose the most suitable programming language for their use case, enabling developers to work with familiar tools and frameworks
Conclusion
WebAssembly is a promising technology that can enable containerless Kubernetes. It offers some benefits like smaller size, faster startup, better isolation, higher density, and easier portability. However, it also has some challenges and limitations like lack of tooling, limited compatibility, limited functionality, and limited performance. Therefore, it is important to evaluate your use case and requirements before adopting WebAssembly on Kubernetes.
