spin-mqtt-booth-volume-app VS containerd-shim-spin

In this blog, we will learn how to compose a full-stack, IoT Spin application and deploy it to Kubernetes via SpinKube. First, we will dissect our full-stack Spin application, that not only consumes data from the MQTT sound sensors but also contains a frontend to visualize the collected data. Next, we will deploy our Spin application to Kubernetes using SpinKube which now supports the MQTT trigger. We will use a mock MQTT device for our demo, but the repository that hosts the example contains steps for configuring a WiFi enabled arduino board in case you want to bring this to your booth.

With our Spin application completed, we can now deploy it to Kubernetes by configuring the cluster with SpinKube. SpinKube is an open source project that enables running Spin applications on Kubernetes alongside containers. The project consists of 4 sub-projects, the Spin Operator, the spin kube plugin, the runtime class manager, and the Spin containerd shim. The latter is what contains the Spin runtime and executes the Spin applications on your nodes. The v0.16.0 release of the shim added support for the MQTT trigger, enabling us to run our application on SpinKube! You can use one of SpinKube’s installation guides to install SpinKube on your distribution of Kubernetes.

containerd-shim-spin

Thanks for the question!

For context, the shim is just an implementation detail of how containerd runs workloads; some come pre-built by default on some systems (like runc), and others you configure (like kata-containers, or in this case, the Spin shim); and some Kubernetes distros already have built-in shims (or will have soon), like k3s.

Your setup seems to work really well for you (and as a side note, I'm curious to learn more about the kinds of workloads you are running) — I'll note that you can also set the runtime class on a regular Kubernetes deployment / pod spec and you can run the workload like this with the Spin shim (for reference https://github.com/spinkube/containerd-shim-spin/blob/main/d...).

For Spin, we focused on the end-to-end developer experience, and on building a set of tools that take advantage of the benefits you get from Wasm, while integrating with a lot of cloud native tools — while allowing you to more easily build APIs and event-driven functions.

Our goal with SpinKube is to integrate with how organizations run workloads on in their infrastructure, and to make building, distributing, and running Wasm as seamless as possible.

Happy to dive into details for any of the points above, and would love to learn more about what you are running as Wasm.

Thanks!

Containerd Shim Spin - the containerd shim implementation for Spin