Combining Kubernetes And wasmCloud

With every new iteration of technology, platforms, and deployment methodologies, the goal is simple - faster and more efficient practices.

The problem is that although the goal is simple, getting there never is. In fact, one could argue that engineers and organizations have been trying to get there since the beginning of tech. Luckily, Wasm gets us a step closer.

In this blog post, you’ll learn a bit about how Wasm works, the benefits of wasmCloud, and how to get wasmCloud up and running on Kubernetes.

Prerequisites

If you’d like to follow along from a hands-on perspective, you’ll need a Kubernetes cluster running v1.24 or above. If you’d like to just hang out and read along, that works too!

A Quick Wasm Definition Overview

Before diving into the benefits and the “how” of running wasmCloud on Kubernetes, let’s briefly touch on a few necessary definitions.

A Module is like a shared library. Think about a library in an application stack. It contains not only other libraries that are used but pieces of the application stack that are called upon to make the entire stack work.

A Component wraps around the Module that specifies its imports, exports, and interfaces (think Types).

In Wasm by default, it can only understand the most basic of types (strings and integers). Because of that, when you create a Component that holds the interfaces created (or that you created) for your application stack, Wasm won't be able to understand them. So Wasm knows what interfaces/imports/exports are needed for your stack, you create a file that contains them called a "WIT".

A Wasm runtime is like any other runtime. For example, if you want containers to run on Kubernetes, you have to use a container runtime like containerd or CRI-O. The same rules apply for Wasm. If you want to run Wasm on Kubernetes, a runtime must exist.

When dealing with Wasm, you’ll often hear the “Components” part a lot. The Component is like an extension of your application (perhaps “extension isn’t the right verbiage, but it’s the best I could come up with) that allows other applications to interact with it and adds capabilities to the application.

The Benefits Of wasmCloud On Kubernetes

In the last section, you learned about Components. With Components and NATS (an open-source network messaging system that gears towards scalable microservices), a Wasm binary can be running anywhere, at any time, in multiple locations. For example, let’s say you have a Wasm binary running on a VM and you want to transfer the traffic to the same Wasm binary running on Kubernetes. Because of Components and NATS, you can. More specifically, Lattice, which is based off of NATS, is how you can transfer the traffic between wherever the Wasm binary is running.

Now, how does that translate to the benefits of running on k8s?

The benefits are directly correlated to how Kubernetes works. Wasm allows you to run Wasm-based workloads anywhere, across any architecture, and in multiple places at once. Kubernetes allows you to not only have an extendable API that can interact with any API that already exists, but it gives you a place to run decoupled applications with shared resources (memory, CPU, GPU) across a pool of Nodes.

Wasm gives you extensibility for an application and Kubernetes gives you an extensible place to run it.

Installing wasmCloud On Kubernetes

As mentioned in the previous section, one of the key benefits of Kubernetes is its extendable API. Without it, many stacks wouldn’t be able to run, including wasmCloud. wasmCloud gets installed on Kubernetes via the wasmCloud Kubernetes Operator.

The “best practice” method of deployment right now is:

1. Deploying the prerequisites (the Operator, NATS, and wadm).
2. wasmCloud Host which is the runtime.

Helm, which is a Kubernetes package manager, is the best way to get step number 1 configured. The following Helm Chart takes care of all of it for you.

helm upgrade --install \
    wasmcloud-platform \
    --values https://raw.githubusercontent.com/wasmCloud/wasmcloud/main/charts/wasmcloud-platform/values.yaml \
    oci://ghcr.io/wasmcloud/charts/wasmcloud-platform \
    --dependency-update

Wait for all of the prerequisites to be deployed successfully. You can check each of the statuses with the three following commands:

kubectl rollout status deploy,sts -l app.kubernetes.io/name=nats

kubectl wait --for=condition=available --timeout=600s deploy -l app.kubernetes.io/name=wadm

kubectl wait --for=condition=available --timeout=600s deploy -l app.kubernetes.io/name=wasmcloud-operator

Once all of the above commands pass successfully, you can create the wasmCloud Host using another Helm Chart.

helm upgrade --install \
    wasmcloud-platform \
    --values https://raw.githubusercontent.com/wasmCloud/wasmcloud/main/charts/wasmcloud-platform/values.yaml \
    oci://ghcr.io/wasmcloud/charts/wasmcloud-platform \
    --dependency-update \
    --set "hostConfig.enabled=true"

You’ll see an output similar to the screenshot below if the creation of the wasmCloud Host was successful.

If you have your own wasmCloud Component, you can now run it on the Kubernetes cluster. If you don’t have a Component but want to see if it still works, you can use the example below:

kubectl apply -f https://raw.githubusercontent.com/wasmCloud/wasmcloud-operator/main/examples/quickstart/hello-world-application.yaml

Once it’s deployed, run kubectl get application to see the deployed Component.

kubectl get application
APPLICATION   DEPLOYED VERSION   LATEST VERSION   STATUS
hello-world   v0.0.1             v0.0.1           Deployed

Congrats! You’ve successfully configured wasmCloud on Kubernetes and ensured that Components can be run.