KCD Bengaluru Docker + WASM workloads running side by side
You’ll complete the following steps:
- Build a K3d cluster
- Verify the runtime configuration
- Configure node labels
- Create a RuntimeClass
- Deploy an app
- Test the app
- Scale the app
- Inspect the containerd processes
Build a K3d Kubernetes cluster
$ k3d cluster create wasm-cluster2
--image ghcr.io/deislabs/containerd-wasm-shims/examples/k3d:v0.5.1
-p "8081:80@loadbalancer" --agents 2
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION k3d-wasm-cluster-server-0 Ready control-plane,master 2m v1.24.6+k3s1 k3d-wasm-cluster-agent-0 Ready 2m v1.24.6+k3s1 k3d-wasm-cluster-agent-1 Ready 2m v1.24.6+k3s1 The output shows a 3-node Kubernetes cluster with a single control plane node and two worker nodes. The command to build the cluster used an image with the spin and slight Wasm runtimes pre-installed. These are vital to running WebAssembly apps on Kubernetes.
The next step will verify the runtime configuration.
Verify the runtime configuration
Use docker exec to log on to the k3d-wasm-cluster-agent-0 node.
$ docker exec -it k3d-wasm-cluster-agent-0 ash Run all of the following commands from inside the exec session. Check the /bin directory for containerd shims named according to the containerd shim naming convention.
$ ls /bin | grep containerd-
containerd-shim-runc-v2 containerd-shim-slight-v1 containerd-shim-spin-v1
You can see the runc, slight, and spin shims. runc is the default low-level runtime for running containers on Kubernetes and is present on all worker nodes running containerd. spin and slight are Wasm runtimes for running WebAssembly apps on Kubernetes.
The next step is to label your nodes.
Configure node labels
Run the following command to check existing node labels. If you’re still logged in to one of the cluster nodes you’ll need to type exit to return to your terminal.
$ kubectl get nodes --show-labels
NAME STATUS ROLES VERSION LABELS k3d-wasm-cluster-server-0 Ready control-plane,master v1.24.6+k3s1 beta.kubernetes.io... k3d-wasm-cluster-agent-0 Ready v1.24.6+k3s1 beta.kubernetes.io... k3d-wasm-cluster-agent-1 Ready v1.24.6+k3s1 beta.kubernetes.io...
The nodes have a lot more labels than shown above and it can be hard to read them. However, if you look closely at your output, you’ll see that none of them have any labels indicating they are capable of running Wasm workloads. This is OK in scenarios like this where every node has the same runtimes installed. However, in environments where only a sub-set of nodes have a Wasm runtime you’ll need to label those nodes.
We’ll add a custom label to a single worker node and use it in a future step to force Wasm apps onto just that node.
Run the following command to add the spin=yes label to the k3d-wasm-cluster-agent-0 worker node.
$ kubectl label nodes k3d-wasm-cluster-agent-0 spin=yes
Verify the operation. Your output will be longer, but only the k3d-wasm-cluster-agent-0 should be displayed.
$ kubectl get nodes --show-labels | grep spin
NAME STATUS ROLES ... LABELS k3d-wasm-cluster-agent-0 Ready ... beta.kubernetes..., spin=yes At this point, k3d-wasm-cluster-agent-0 is the only node with the spin=yes label. In the next step, you’ll create a RuntimeClass that targets this node.
Create a RuntimeClass
The following YAML defines a RuntimeClass called spin-test. It selects on nodes with the spin=yes label and specifies the spin runtime as the handler.
Copy and paste the whole block into your terminal to deploy it. kubectl apply -f - <<EOF apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: spin-test handler: spin scheduling: nodeSelector: spin: "yes" EOF Copy The following command verifies the RuntimeClass was created and is available. $ kubectl get runtimeclass
NAME HANDLER AGE spin-test spin 10s At this point, you have a 3-node Kubernetes cluster and all three nodes have the spin runtime installed. You also have a RuntimeClass that can be used to schedule tasks against the k3d-wasm-cluster-agent-0 node. This means you’re ready to run WebAssembly apps on Kubernetes! In the next step, you’ll deploy a Kubernetes app.
Deploy an app The following YAML snippet is from the app you’re about to deploy. The only bit we’re interested in is the spec.template.spec.runtimeClassName = spin-test field. This tells Kubernetes to use the spin-test RuntimeClass you created in the previous step. This will schedule the app to the correct node and ensure it executes with the appropriate handler (runtime).
apiVersion: apps/v1 kind: Deployment metadata: name: wasm-spin spec: replicas: 1 ... template: ... spec: runtimeClassName: wasmtime-spin <<==== Targets the RuntimeClass containers:
Deploy it with the following command.
$ kubectl apply
-f https://raw.githubusercontent.com/nigelpoulton/spin1/main/app.yml
Verify the app was deployed. It might take a few seconds for it to enter the ready state and it will only work if you followed all previous steps.
$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE wasm-spin 1/1 1 1 14s
curl -v http://127.0.0.1:8081/spin/hello
kubectl scale --replicas 3 deploy/wasm-spin