WASM en Kubernetes: AKS.

Como ya os contó mi compañero Juan Mas en profundidad en un excelente post, WebAssembly (WASM) está cobrando cada vez más relevancia para ejecutar aplicaciones en servidores. Vemos como grandes de la industria (Microsoft, Docker, Red Hat, VMWare, etc.) y nuevos actores (Fermyon, Deislabs, etc.) aúnan fuerzas para estandarizar y facilitar la adopción de esta prometedora tecnología en ebullición.

En este post, vamos a ver cómo ejecutar workloads de tipo WASM en AKS.

¡Comencemos!

Conceptos

Por si aún no habéis leído el post anterior sobre WebAssembly en el servidor (¡a qué esperáis! 😀), recordamos un par de conceptos descritos en él e introducimos otros nuevos para comprender mejor lo que comentaremos a lo largo del post:

• WASI: WebAssembly System Interface. Es un proyecto asociado al proyecto Wasmtime en la que se diseña una interfaz modular de sistema o API que brinda acceso a módulos WASM a varias funciones similares a las de un sistema operativo (como archivos y sistemas de archivos, sockets, relojes y números aleatorios) propuestos para su estandarización. Está diseñada para ser independiente de los navegadores, por lo que no depende de las API web ni de JavaScript.
• Containerd: es un entorno de ejecución de contenedores estándar con énfasis en la simplicidad, robustez y portabilidad. Está disponible como un daemon para Linux y Windows, que puede gestionar el ciclo de vida completo de contenedores en su sistema host: transferencia y almacenamiento de imágenes, ejecución y supervisión de contenedores, almacenamiento de bajo nivel y conexiones de red, entre otros.
• Shim: software auxiliar o puente que actúa como una capa de compatibilidad para facilitar la interoperabilidad entre diferentes componentes o tecnologías como containerd y runc.
• Runc: ejecutor de contenedores de bajo nivel que se utiliza para lanzar y ejecutar contenedores basados en el estándar de Open Container Initiative (OCI). Es una herramienta fundamental para el entorno de contenedores y es compatible con varios proyectos de contenedores, incluido containerd.
• RuntimeClass: recurso de Kubernetes que permite a los administradores de clúster especificar y configurar runtimes de contenedores alternativos para ejecutar los pods en un clúster. Un "runtime", en este contexto, se refiere al componente de software responsable de ejecutar y gestionar los contenedores dentro de un pod. Antes de la introducción de RuntimeClass, Kubernetes asumía que todos los pods en un clúster se ejecutarían en el mismo tipo de runtime, generalmente Docker. Sin embargo, a medida que aumentó la diversidad de runtimes de contenedores, se volvió necesario admitir diferentes runtimes dentro de un clúster.

¿Qué vamos a hacer?

Vamos a crear un microservicio web en Rust, utilizando un framework de Web Assembly llamado SPIN, creado por Fermyon. Crearemos una imagen con Docker y la subiremos a un ACR. Crearemos un WASI NodePool (con runtime WASI habilitado) en AKS y crearemos un pod asociado a ese pool y un servicio de tipo LoadBalancer para acceder a nuestra aplicación. Aquí podéis encontrar el código de lo que veremos.

Se han elegido estas tecnologías por su compatibilidad. En un próximo posts analizaremos otras como podman y OpenShift, estad atentos 😉.

Si seguimos la documentación para crear el nodepool en AKS y el ejemplo de creación y ejecución de un workload WebAssembly todo parece sencillo porque se usan imágenes ya probadas, pero si queremos crear nuestras propias POCs o desarrollar aplicaciones necesitamos empezar desde el desarrollo del código pasando por crear un contenedor hasta ejecutarlo. Para ello debemos tener en cuenta las limitaciones que hay todavía en estas tecnologías incipientes.

Limitaciones

Hay diversos puntos a tener en cuenta en varios pasos del ciclo de vida de la aplicación que hacen que tareas habituales hoy en día se nos puedan atascar y acabemos perdidos en océanos de documentación intentando solucionar errores causados en su mayoría por la etapa temprana de las integraciones que hay entre herramientas.

Vamos a allanar el camino de quien quiera comenzar a probar WASM en AKS comentando todas las limitaciones que nos hemos encontrado en Spin, Docker y AKS:

1. SPIN

a) Fermyon acaba de sacar la v2 de este framework (por defecto se instala esta última versión) que no está soportada por AKS.

b) AKS usa una versión antigua del shim para SPIN, por lo que necesitamos cambiar el spin_manifest_version a spin_version en el fichero spin.toml si usamos un proyecto generado por template desde la spin cli.

2. Docker

a) Ejecutar WASM workloads en Docker es Beta/Technical Preview.

b) io.containerd.spin.v1 no se instala y falla si se usa para ejecutando ‘docker run -i --runtime=io.containerd.spin.v1 …’

3. AKS

a) Los WASM Nodepools son una AKS preview feature.

b) Los WASI Nodepools de AKS solo tienen containerd-shims disponibles para aplicaciones construidas con SPIN y SLIGHT (que usan por debajo el wasmtime runtime).

c) El os-type para los WASM/WASI node pools debe ser Linux (importante a la hora de construir las imágenes). Esto se consigue a la hora de construir la imagen de docker con el parámetro - - provenance=false (lo veremos más adelante).

d) Los runtimeClass disponibles en AKS de momento son los siguientes y las referencias en AKS no equivalen a las versiones de SPIN:

• Wasmtime-spin-v1 en Azure es la versión v0.3.0 de SPIN.
• Wasmtime-spin-v0-5-1 es la versión v1.0.0 de SPIN.

Una vez en contexto de las limitaciones de las tecnologías que usaremos, comencemos con la diversión 😀.

Spin

Spin es un framework opensource para construir y ejecutar microservicios rápidos, seguros y compuestos por módulos WebAssembly. Su objetivo es ser la manera más sencilla de comenzar con microservicios de WebAssembly usando el runtime de Wasmtime.

Hemos elegido usar este framework, ya que es uno de los 2 soportados por AKS (limitación 3.b⚠️).

Vamos a instalar la versión 1.5.1 de Spin que es la última release de la versión 1 de SPIN debido a la limitación 1.a ⚠️ (la versión 2 no está soportada por AKS).

 ~/spin $ sudo curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash -s -- -v v1.5.1
Step 1: Downloading: https://github.com/fermyon/spin/releases/download/v1.5.1/spin-v1.5.1-linux-amd64.tar.gz
Done...
.
.
.
Step 5: Installing default plugins
Plugin information updated successfully
Plugin 'js2wasm' is already installed with version 0.6.1.
Plugin 'py2wasm' is already installed with version 0.3.2.
Plugin 'cloud' is already installed with version 0.5.1.
You're good to go. Check here for the next steps: https://developer.fermyon.com/spin/quickstart
Run './spin' to get started

 ~/spin $ sudo mv ./spin /usr/bin

 ~/spin $ spin --version
spin 1.5.1 (8d4334e 2023-09-26)

También debemos tener previamente instalado Rust, ya que para construir componentes en Spin, necesitamos el target wasm32-wasi para Rust. Conseguimos este target con:

 ~/spin/hello-paradigma-world $ rustup target add wasm32-wasi
info: downloading component 'rust-std' for 'wasm32-wasi'
info: installing component 'rust-std' for 'wasm32-wasi'

También deberemos tener instalado el compilador de C (llamado gcc):

 ~/spin/hello-paradigma-world $ sudo apt install gcc

Vamos ahora a crear nuestra aplicación y para ello ejecutamos spin new y elegimos http-rust, le damos la base ”/” y un path “/paradigma” para un endpoint donde nuestra aplicación pueda responder:

 ~/spin $ spin new
Pick a template to start your application with:
 http-c (HTTP request handler using C and the Zig toolchain)
 http-empty (HTTP application with no components)
 http-go (HTTP request handler using (Tiny)Go)
 http-grain (HTTP request handler using Grain)
 http-js (HTTP request handler using Javascript)
 http-php (HTTP request handler using PHP)
 http-py (HTTP request handler using Python)
> http-rust (HTTP request handler using Rust)
 http-swift (HTTP request handler using SwiftWasm)
 http-ts (HTTP request handler using Typescript)
 http-zig (HTTP request handler using Zig)
 redirect (Redirects a HTTP route)
 redis-go (Redis message handler using (Tiny)Go)
 redis-rust (Redis message handler using Rust)
 static-fileserver (Serves static files from an asset directory)

Pick a template to start your application with: http-rust (HTTP request handler using Rust)
Enter a name for your new application: hello-paradigma-world
Description: spin test
HTTP base: /
HTTP path: /paradigma

Veremos que spin ha creado los siguientes ficheros de sus templates:

 ~/spin $ cd hello-paradigma-world/
 ~/spin/hello-paradigma-world $ tree
.
├── Cargo.toml
├── spin.toml
└── src
    └── lib.rs

1 directory, 3 files

Vamos a personalizar la respuesta y un header de la aplicación en el código Rust que se ha generado:

También editamos en el spin.toml la propiedad spin_manifest_version dejando spin_version debido a la limitación 1.b ⚠️ comentada en el apartado de limitaciones:

Una vez hechos los cambios ya podemos hacer build de la aplicación con spin build:

~/spin/hello-paradigma-world $ spin build
Building component hello-paradigma-world with `cargo build --target wasm32-wasi --release`
  Compiling proc-macro2 v1.0.70
  Compiling anyhow v1.0.75
  .
  .
  .
  Compiling wit-bindgen v0.8.0
  Compiling hello-paradigma-world v0.1.0 (/home/daniel/spin/hello-paradigma-world)
   Finished release [optimized] target(s) in 10.26s
Finished building all Spin components

Esta compilación ejecuta el command que vemos en el spin.toml y es la que creará nuestro módulo wasm dentro del fichero target/wasm32-wasi/release/hello_paradigma_world.wasm

Una vez compilado con éxito, podemos levantar nuestra app web en Rust con el comando spin up:

 ~/spin/hello-paradigma-world $ spin up
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
 hello-paradigma-world: http://127.0.0.1:3000/paradigma

{"host": "127.0.0.1:3000", "user-agent": "curl/7.68.0", "accept": "*/*", "spin-path-info": "", "spin-full-url": "http://127.
0.0.1:3000/paradigma", "spin-matched-route": "/paradigma", "spin-base-path": "/", "spin-raw-component-route": "/paradigma","spin-component-route": "/paradigma", "spin-client-addr": "127.0.0.1:39230"}

Y comprobar su funcionamiento con un curl (nótese también el header “company: Paradigma”):

 ~/spin/hello-paradigma-world $ curl http://127.0.0.1:3000/paradigma -v
*   Trying 127.0.0.1:3000...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0)
> GET /paradigma HTTP/1.1
> Host: 127.0.0.1:3000
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< company: Paradigma
< content-length: 24
< date: Wed, 13 Dec 2023 10:27:37 GMT
<
Hello, Paradigma World!

A partir de aquí podríamos hacer los cambios que queramos y desarrollar nuestra aplicación.

Docker

Una vez tenemos una versión de nuestra aplicación con la que estemos conformes podemos containerizar la aplicación.

Construcción de la imagen del contenedor WASM

En este caso, Docker ofrece soporte en Beta para los siguientes Runtimes, incluyendo spin:

• io.containerd.slight.v1
• io.containerd.spin.v2
• io.containerd.wasmedge.v1
• io.containerd.wasmtime.v1
• io.containerd.lunatic.v1
• io.containerd.wws.v1
• Io.containerd.wasmer.v1

Para activar esta característica en Docker, debemos ir a Settings > Features in development y activamos Use containerd for storing and pulling images y Enable Wasm.

Una vez activada esta característica, podemos crear un Dockerfile como el siguiente:

# Dockerfile
FROM scratch
COPY spin.toml /spin.toml
COPY target/wasm32-wasi/release/hello_paradigma_world.wasm /target/wasm32-wasi/release/hello_paradigma_world.wasm
ENTRYPOINT ["/spin.toml"]

Observemos que usamos una imagen mínima reservada de docker llamada “scratch”, la cual indica al build process que queremos que el siguiente comando en el Dockerfile sea la primera capa del sistema de ficheros de nuestra imagen. Es decir, no hay ningún fichero en nuestra imagen, ni siquiera de sistema operativo, exceptuando los archivos que estamos copiando en el Dockerfile con “COPY”.

Vamos ahora a construir la imagen de nuestra app con este Dockerfile y para ello ejecutamos el siguiente comando:

docker buildx build --platform wasi/wasm --provenance=false -t ydguala/hello-paradigma-world-provenance:latest .

[+] Building 0.2s (6/6) FINISHED                                                                                                              docker:default
 => [internal] load build definition from Dockerfile                                                                                                    0.0s
 => => transferring dockerfile: 217B                                                                                                                    0.0s
 => [internal] load .dockerignore                                                                                                                       0.0s
 => => transferring context: 2B                                                                                                                         0.0s
 => [internal] load build context                                                                                                                       0.0s
 => => transferring context: 216B                                                                                                                       0.0s
 => CACHED [1/2] COPY spin.toml /spin.toml                                                                                                              0.0s
 => CACHED [2/2] COPY target/wasm32-wasi/release/hello_paradigma_world.wasm /target/wasm32-wasi/release/hello_paradigma_world.wasm                      0.0s
 => exporting to image                                                                                                                                  0.0s
 => => exporting layers                                                                                                                                 0.0s
 => => exporting manifest sha256:367aee43d10b4114da7e6e200e3712e7d7783b25d480cd5894515d4ca6bd220a                                                       0.0s
 => => exporting config sha256:2faafd1e2df9184281a10ccf13f9a27933b0741b8494378c1919c624f9c89fe6                                                         0.0s
 => => naming to docker.io/ydguala/hello-paradigma-world-provenance:latest

Notemos los argumentos:

• --platform wasi/wasm que especifica la arquitectura de la imagen que se desea utilizar. El Runtime de Wasm se encarga del paso final de convertir el binario de Wasm en instrucciones de máquina.
• --provenance=false : relacionado con la limitación 3.c ⚠️ indica que queremos deshabilitar los atestados de procedencia que incluyen facts sobre el build process como, Build timestamps, Build parameters y environment, Version control metadata, detalles del Source code, Materials (ficheros, scripts) consumidos durante la build, etc. Está relacionado también con el manifiesto de la imagen en ACR que veremos más adelante.
• Si no usamos este parámetro, nos encontraremos que nuestros pods en AKS no se levantan debido al error : “failed to pull and unpack image "poc.azurecr.io/ydguala/hello-paradigma-world:latest": no match for platform in manifest: not found”.

Vamos a confirmar ahora una de las ventajas de WebAssembly. Podemos ver en este caso que los binarios junto con todas sus dependencias utilizan muy poco espacio en disco.

La imagen del contenedor que acabamos de crear ocupa tan solo 2.84MB frente a las imágenes sin código ni dependencias de busybox (6.61MB ), alpine (11.5MB) o ubuntu (117MB):

Ejecución del contenedor en Docker

Una vez construida la imagen, vamos a ejecutarla teniendo en cuenta:

• La limitación 2.b ⚠️ que nos dice que aunque estemos desarrollando en la versión 1 del framework de spin y la documentación de spin y docker diga que el parámetro es --runtime=io.containerd.spin.v1 debemos usar la v2.
• Que debemos indicar también la plataforma con el parámetro --platform=wasi/wasm.

El comando sería:

$ docker run -d --runtime=io.containerd.spin.v2 --platform=wasi/wasm -p 80:80 ydguala/hello-paradigma-world:latest

5915bab96ee684d8f82e96b12b8ebe8b95c11b03095922f94affcab3c24224a5

Y vamos a comprobar que funciona correctamente con un curl:

$ curl http://127.0.0.1:80/paradigma -v
*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /paradigma HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< company: Paradigma
< content-length: 24
< date: Wed, 13 Dec 2023 12:01:19 GMT
<
Hello, Paradigma World!

Con esto hemos confirmado que nuestro Contenedor funciona.

Push de la imagen a Azure Container Registry

Vamos, pues, a pushear la imagen a un ACR (Azure Container Registry) que está atachado al AKS donde crearemos nuestro WASI Nodepool para que en la siguiente sección podamos ejecutar nuestro contenedor en Azure.

Nos logueamos en el ACR:

$ az acr login -n poc 
Login Succeeded

Tagueamos nuestra imagen y hacemos push al registry:

$ docker tag ydguala/hello-paradigma-world:latest poc.azurecr.io/ydguala/hello-paradigma-world:latest

$ docker push poc.azurecr.io/ydguala/hello-paradigma-world:latest
The push refers to repository [poc.azurecr.io/ydguala/hello-paradigma-world]
16bf8ad9674e: Pushed 
34f94b9fe8b6: Pushed 
228ecb7de3b8: Pushed 
latest: digest: sha256:7c654532a8f226868ec6de4b18e69462907e98dcae6ccb5d93a975b9ee1332e8 size: 853

Podemos ver en ACR que el manifiesto de nuestra imagen no contiene información sobre la arquitectura y sistema operativo relacionados con WASM/WASI:

A diferencia de otras imágenes comunes como la de busybox que sí tienen “arquitectura: amd64” y “os: linux”:

ARM ComeBack

Antes de pasar a la siguiente sección, recordemos otra ventaja de WebAssembly relacionada con el punto anterior. Y es que puede correr realmente sobre cualquier arquitectura.

No solo AMD, sino también ARM. Esto es de especial relevancia hoy en día, ya que vuelve a traer a la escena de Servidores a arquitecturas de chipset como ARM que están optimizadas para consumir poco y ser más baratas (chips móviles), ideales en escenarios de IoT (Internet of Things) e incluso para Inteligencia Artificial.

No es casualidad que desde Microsoft se esté impulsando tecnologías que puedan aprovechar las arquitecturas ARM, como veremos en la siguiente sección, ya que ellos mismos han anunciado que fabricarán sus propios chips ARM llamados Microsoft Azure Cobalt CPU.

No solamente Microsoft está en ello, sino también AWS está sacando nuevas versiones de sus procesadores ARM (AWS Graviton4 and AWS Trainium2) e incluso grandes fabricantes como Intel están estableciendo colaboraciones con ARM (“The collaboration will focus on mobile SoC designs first, but allows for potential design expansion into automotive, Internet of Things (IoT), data center, aerospace and government applications”).

AKS

Crear WASI Nodepool

AKS es uno de los flavors de Kubernetes que está desarrollando su soporte para contenedores WASM, aunque de momento solo soporta aplicaciones construidas con SPIN y SLIGHT (limitación 3.b ⚠️ ).

Para comenzar la construcción de un WASI Nodepool en AKS debemos instalar la extensión de az cli de aks-preview:

$ az extension add --name aks-preview

Y registrar la feature WasmNodePoolPreview para lo cual ejecutamos:

$ az feature register --namespace "Microsoft.ContainerService" --name "WasmNodePoolPreview"
Once the feature 'WasmNodePoolPreview' is registered, invoking 'az provider register -n Microsoft.ContainerService' is required to get the change propagated
{
 "id": "/subscriptions/0000000-0000-0000-0000-000000000/providers/Microsoft.Features/providers/Microsoft.ContainerService/features/WasmNodePoolPreview",
 "name": "Microsoft.ContainerService/WasmNodePoolPreview",
 "properties": {
   "state": "Registering"
 },
 "type": "Microsoft.Features/providers/features"
}

Para confirmar el progreso (tarda unos 5 minutos o más) e instalación, podemos ejecutar el siguiente comando y revisar el campo .properties.state:

$ az feature show --namespace "Microsoft.ContainerService" --name "WasmNodePoolPreview"
{
 "id": "/subscriptions/0000000-0000-0000-0000-000000000/providers/Microsoft.Features/providers/Microsoft.ContainerService/features/WasmNodePoolPreview",
 "name": "Microsoft.ContainerService/WasmNodePoolPreview",
 "properties": {
   "state": "Registered"
 },
 "type": "Microsoft.Features/providers/features"
}

Una vez instalada la característica, podemos crear un WASI Nodepool en nuestro cluster de AKS con:

$ az aks nodepool add --resource-group wasi-rg --cluster-name wasi-test --name wasipool --node-count 1 --workload-runtime WasmWasi

Cuando acabe de crearse el pool podemos ver que tiene las siguientes etiquetas, entre otras:

$ k describe no aks-wasipool-17141169-vmss000000 | grep wasmtime
                    kubernetes.azure.com/wasmtime-slight-v0-3-0=true
kubernetes.azure.com/wasmtime-slight-v0-5-1=true
kubernetes.azure.com/wasmtime-slight-v0-8-0=true
kubernetes.azure.com/wasmtime-slight-v1=true
kubernetes.azure.com/wasmtime-spin-v0-3-0=true
kubernetes.azure.com/wasmtime-spin-v0-5-1=true                    kubernetes.azure.com/wasmtime-spin-v0-8-0=true
kubernetes.azure.com/wasmtime-spin-v1=true
kubernetes.azure.com/wasmtime-wws-v0-8-0=true

Y que se han instalado los siguientes RuntimeClasses:

$ k get runtimeclass
NAME                     HANDLER         AGE
wasmtime-slight-v0-3-0   slight-v0-3-0   18m
wasmtime-slight-v0-5-1   slight-v0-5-1   18m
wasmtime-slight-v0-8-0   slight-v0-8-0   18m
wasmtime-slight-v1       slight          18m
wasmtime-spin-v0-3-0     spin-v0-3-0     18m
wasmtime-spin-v0-5-1     spin-v0-5-1     18m
wasmtime-spin-v0-8-0     spin-v0-8-0     18m
wasmtime-spin-v1         spin            18m
wasmtime-wws-v0-8-0      wws-v0-8-0      18m

Aquí podemos ver cómo es un objeto runtimeClass:

$ k get runtimeclass wasmtime-slight-v0-5-1 -o yaml
apiVersion: node.k8s.io/v1
handler: slight-v0-5-1
kind: RuntimeClass
metadata:
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
  name: wasmtime-slight-v0-5-1
scheduling:
  nodeSelector:
    kubernetes.azure.com/wasmtime-slight-v0-5-1: "true"

Crear recursos k8s en AKS

Por fin vamos a crear un pod y un servicio para exponer nuestra aplicación.

Utilizaremos los siguientes manifiestos:

# pod-svc.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    app: spin-paradigma-world
  name: spin-paradigma-world
spec:
  runtimeClassName: wasmtime-spin-v0-8-0
  containers:
  - image: poc.azurecr.io/ydguala/hello-paradigma-world:latest
    imagePullPolicy: Always
    name: spin-paradigma-world
    resources:
      requests:
        cpu: 10m
        memory: 10Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
— — —
apiVersion: v1
kind: Service
metadata:
  name: spin-paradigma-world-svc
spec:
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  selector:
    app: spin-paradigma-world

Aunque por intuición quizás hubiésemos usado el runtimeClass wasmtime-spin-v1 (porque llevamos hablando todo el post de que estamos usando Spin v1) recordemos las limitaciones 3.d ⚠️ que nos dicen ese runtimeClass está asociada a la versión v0.3.0 de SPIN.

Hemos intentado utilizar el runtimeClass wasmtime-spin-v0-5-1, pero nos daba el error: failed to start containerd task "spin-paradigma-world": Cannot read manifest file from "/run/containerd/io.containerd.runtime.v2.task/k8s.io/spin-paradigma-world/rootfs/spin.toml": unknown

Finalmente, el runtimeClass que funciona con nuestra versión de SPIN es el que hemos puesto en el manifiesto anterior en el pod : wasmtime-spin-v0-8-0.

Para crear este pod y el servicio crearemos un namespace y aplicaremos el manifiesto:

$ k create ns wasi-workloads
namespace/wasi-workloads created

$ k -n wasi-workloads create -f pod-svc.yaml 
pod/spin-paradigma-world created
service/spin-paradigma-world-svc created

Comprobamos que el pod está corriendo y la ip externa del servicio que acabamos de crear:

$ k -n wasi-workloads get po,svc 
NAME                               READY   STATUS    RESTARTS   AGE
pod/spin-paradigma-world           1/1     Running   0          13m

NAME                               TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
service/spin-paradigma-world-svc   LoadBalancer   10.0.167.58   20.30.40.50   80:31561/TCP   13m

Vamos a lanzar una petición contra nuestro pod para confirmar que funciona como esperamos:

$ curl -v http://20.30.40.50:80/paradigma
*   Trying 20.30.40.50:80...
* Connected to 20.30.40.50 (20.30.40.50) port 80 (#0)
> GET /paradigma HTTP/1.1
> Host: 20.30.40.50
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< company: Paradigma
< content-length: 24
< date: Thu, 14 Dec 2023 09:21:05 GMT
< 
Hello, Paradigma World!
* Connection #0 to host 20.30.40.50 left intact

Podemos ver en los logs del pod también que nuestra petición ha sido respondida por el pod en cuestión:

$ k -n wasi-workloads logs spin-paradigma-world | jq
{
  "host": "20.30.40.50",
  "user-agent": "curl/7.81.0",
  "accept": "*/*",
  "spin-path-info": "",
  "spin-full-url": "http://20.30.40.50/paradigma",
  "spin-matched-route": "/paradigma",
  "spin-base-path": "/",
  "spin-raw-component-route": "/paradigma",
  "spin-component-route": "/paradigma",
  "spin-client-addr": "10.224.0.7:20281"
}

Finicky Whiskers

Si queréis conocer una aplicación más real, los creadores de Spin han desarrollado un juego de ejemplo en el que hay que alimentar un gatito o un perrito a contrarreloj, llamado Finicky Whiskers en el que muestran cómo se pueden aprovechar al máximo las ventajas de webAssembly en una aplicación real. Han hecho una serie de post (e incluso un video) donde explican entre varios elementos importantes relacionados con la arquitectura de microservicios con webAssembly, y obviamente su producto Spin, que usa esta App.

Valoraciones

Las fases del ciclo de vida de una aplicación con WebAssembly parecen funcionar bien por separado. Es decir, cada tecnología se cierne a su dominio:

• El lenguaje tiene amplio soporte a WebAssembly (RUST).
• Tenemos un framework que nos facilita la creación de aplicaciones.
• Tenemos herramientas que nos permiten construir y ejecutar contenedores con runtimes WASI (Docker).
• Y tenemos flavors de Kubernetes que nos permiten ejecutar contenedores construidos en WASI/WASM (AKS).

Cuando probamos estas fases por separado y con ejemplos ya provistos por las mismas tecnologías, es fácil que cada una haga lo que se le presupone. Pero cuando intentamos integrar todos estos pasos es cuando surgen los inconvenientes y limitaciones. Es aquí donde vemos que la productivización de estas tecnologías está todavía en etapas iniciales y no es algo que esté todavía estandarizado.

Tanto SPIN como AKS tienen componentes (RuntimeClass wasmtime-spin-v0-8-0) o versiones nuevas (SPIN v2) que no están soportadas todavía o no aparecen en la documentación propia o de la tecnología que integran. Recordemos que todo está en Beta/Tech Preview.

Todo esto, sin embargo, debe darnos una visión del esfuerzo y peso que la industria está poniendo en WebAssembly. Tenemos eventos tech como el wasmio en los que vemos estos esfuerzos y podemos ver las últimas novedades sobre WebAssembly.

Debemos valorar también que todas estas limitaciones que hemos visto se deben principalmente por la gran velocidad de desarrollo que se está poniendo en la adopción de WebAssembly.

Conclusión

WebAssembly está en un momento de ebullición y nos brinda varias ventajas de serie y posibilidades a la hora de ejecutar aplicaciones en Servidor.

En Kubernetes, y como en muchas ocasiones en nuestro mundillo, si puedes esperar 6 meses o un año a adoptar o poner una nueva tecnología en producción, espera.