WebAssembly en Kubernetes: más seguro que los contenedores, más rápido de arrancar

La primera vez que escuchas "WebAssembly en producción para infraestructura", el cerebro lo categoriza automáticamente como hype de conferencia. Igual que cuando escuchaste serverless en 2014, o service mesh en 2018. Algunos de esos hypes se materializaron; otros siguen siendo diapositivas bonitas.

Wasm en Kubernetes es real, está en producción en empresas como Cloudflare, Fastly y Microsoft, y resuelve dos problemas concretos que los contenedores no resuelven bien: arranque en menos de un milisegundo y aislamiento sin privilegios de kernel. Este post explica cómo funciona, qué puedes hacer hoy, y cuándo Wasm no es la respuesta.

¿Qué es WASI y por qué importa en infraestructura?

WebAssembly nació en el navegador como formato de bytecode portable y seguro. El problema para usarlo en infraestructura era evidente: los módulos Wasm no podían hablar con el sistema operativo. No había acceso a ficheros, red, hora del sistema ni variables de entorno. Era una caja sellada.

WASI (WebAssembly System Interface) es la especificación que rompe esa caja de forma controlada. Define una API estándar y basada en capacidades que permite a los módulos Wasm interactuar con el sistema operativo solo con los permisos que se les conceden explícitamente, siguiendo el principio de mínimo privilegio desde el diseño.

La diferencia con los contenedores es fundamental:

| Mecanismo | Aislamiento | Superficie de ataque | |-----------|-------------|---------------------| | Contenedor (Docker/OCI) | Namespaces + cgroups del kernel Linux | Syscalls disponibles del host | | Máquina virtual | Hypervisor completo | Muy reducida, overhead alto | | Wasm + WASI | Sandbox de bytecode + capability model | Mínima por diseño |

WASI 0.2, estabilizado en enero de 2024, introduce el Component Model: la capacidad de componer módulos Wasm de distintos lenguajes como si fueran bloques independientes con interfaces tipadas. Esto es lo que hace posible que un componente escrito en Rust llame a uno escrito en Python sin FFI ni serialización manual.

Wasm vs contenedores: arranque, aislamiento y tamaño

La comparativa no es "uno vs otro". Es entender cuándo cada modelo es el instrumento correcto.

Tiempo de arranque

El tiempo de arranque de un contenedor OCI incluye: pull de imagen (si no está en caché), creación de namespaces, setup de cgroups, inicialización del runtime (runc/crun) y el inicio del proceso. En condiciones óptimas, con imagen en caché local: 150–500ms.

Un módulo Wasm arranca en 0.5–5ms. La JIT compilation del bytecode es instantánea en runtimes modernos como Wasmtime con Cranelift. Para workloads con patrones de arranque frecuente —edge functions, inferencia por petición, tasks de corta duración— la diferencia no es marginal: es el factor que determina si la arquitectura es viable.

# Contenedor OCI (nginx:alpine, imagen en caché local)
$ time kubectl run test-pod --image=nginx:alpine --restart=Never
real    0m0.847s   # arranque del pod completo

# Módulo Wasm con runwasi + Wasmtime
$ time kwasm-operator run hello-wasm.wasm
real    0m0.003s   # 3ms incluyendo scheduling

# La diferencia se amplifica en cold starts (imagen no cacheada)
# Contenedor OCI: 2–15s (pull de imagen)
# Wasm:           5–20ms (módulo de ~2MB)

Aislamiento y modelo de seguridad

Los contenedores comparten el kernel del host. Un exploit de kernel puede escapar del contenedor y comprometer el nodo. Las syscalls disponibles son una superficie de ataque real: CVE-2019-5736 (runc escape), CVE-2022-0847 (Dirty Pipe) son ejemplos de esto.

Wasm ejecuta en un sandbox de bytecode verificado. El runtime valida estáticamente que el módulo no puede acceder a memoria fuera de su sandbox antes de ejecutarlo. No hay syscalls directas: toda interacción con el exterior pasa por las capacidades WASI que el host concede explícitamente.

Modelo de capacidades WASI:

Host (Wasmtime/Spin)
│
├── wasi:filesystem/preopens   → solo los directorios que le pasas
├── wasi:sockets/network       → solo si lo habilitas explícitamente
├── wasi:clocks/wall-clock     → lectura de tiempo: sí/no
├── wasi:http/outgoing-handler → peticiones salientes: solo dominios permitidos
└── wasi:keyvalue/store        → KV store: namespace aislado por módulo

Tamaño de imagen

| Tipo | Imagen base | App incluida | Total | |------|-------------|--------------|-------| | Contenedor Python (FastAPI) | 120 MB | 15 MB | ~135 MB | | Contenedor Go (binario estático) | 5 MB (distroless) | 8 MB | ~13 MB | | Módulo Wasm (Rust compilado) | 0 MB | 2–6 MB | ~4 MB | | Módulo Wasm (Go compilado) | 0 MB | 5–12 MB | ~8 MB | | Módulo Wasm (componente Python) | 0 MB | 1–3 MB | ~2 MB |

No hay OS base en un módulo Wasm. No hay libc, no hay shell, no hay superficie de ataque derivada de packages del sistema operativo. Los CVEs de libssl, glibc o bash son simplemente irrelevantes.

Spin, Wasmtime y runwasi: el ecosistema actual

El ecosistema Wasm en infraestructura tiene tres capas bien diferenciadas: runtimes (ejecutan bytecode), frameworks (construyen aplicaciones) y shims (integran Wasm en Kubernetes). Las tres son necesarias.

Wasmtime: el runtime de referencia

Mantenido por la Bytecode Alliance (Mozilla, Microsoft, Fastly, Intel), Wasmtime es el runtime Wasm más usado en infraestructura. Implementa WASI 0.2, el Component Model y Ahead-of-Time compilation para rendimiento máximo.

use wasmtime::*;
use wasmtime_wasi::{WasiCtxBuilder, preview2::WasiCtx};

fn main() -> anyhow::Result<()> {
    // Configurar el engine con optimizaciones de producción
    let mut config = Config::new();
    config.wasm_component_model(true);  // WASI 0.2 Component Model
    config.async_support(true);

    let engine = Engine::new(&config)?;

    // Construir el contexto WASI con capacidades explícitas
    // Solo damos acceso a lo que el módulo necesita
    let wasi_ctx = WasiCtxBuilder::new()
        .inherit_stdio()
        .preopened_dir(
            Dir::open_ambient_dir("./data", ambient_authority())?,
            "/data",             // el módulo solo ve /data, nada más
        )?
        .allow_http()            // habilitar peticiones HTTP salientes
        .build();

    let mut store = Store::new(&engine, wasi_ctx);

    // Cargar y compilar el módulo (AoT si ya está compilado)
    let component = Component::from_file(&engine, "mi-servicio.wasm")?;
    let linker = Linker::new(&engine);

    // Instanciar y llamar a la función exportada
    let instance = linker.instantiate_async(&mut store, &component).await?;
    let run = instance.get_typed_func::<(), ()>(&mut store, "run")?;
    run.call_async(&mut store, ()).await?;

    Ok(())
}

Spin: el framework para Wasm en servidor

Spin de Fermyon es al Wasm lo que Express es a Node.js: el framework más usado para construir aplicaciones Wasm orientadas a servidor. Abstrae el runtime, gestiona triggers (HTTP, Redis, cron, Kafka) y define un modelo de componentes listo para producción.

# Instalar Spin CLI
curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash

# Crear un nuevo proyecto Rust para Wasm
spin new -t http-rust mi-api
cd mi-api

# El código generado en src/lib.rs
cat src/lib.rs

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

// La macro marca esta función como el entrypoint del componente Wasm
#[http_component]
fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {
    let path = req.uri().path();

    // Acceso a KV store nativo de Spin (sin SDK externo)
    let store = spin_sdk::key_value::Store::open_default()?;

    let response_body = match path {
        "/health" => serde_json::json!({"status": "ok", "runtime": "wasm"}),
        "/user" => {
            let user_id = req.header("x-user-id")
                .and_then(|v| v.as_str())
                .unwrap_or("anonymous");

            // Lee del KV store — solo el namespace de este componente
            let cached = store.get(user_id)?;
            match cached {
                Some(data) => serde_json::from_slice(&data)?,
                None => serde_json::json!({"user": user_id, "source": "db"}),
            }
        }
        _ => serde_json::json!({"error": "not found"}),
    };

    Ok(Response::builder()
        .status(200)
        .header("content-type", "application/json")
        .body(serde_json::to_string(&response_body)?)
        .build())
}

# Compilar a Wasm (requiere target wasm32-wasi)
spin build

# El resultado: target/wasm32-wasi/release/mi_api.wasm (≈ 3.2 MB)
ls -lh target/wasm32-wasi/release/mi_api.wasm
# -rwxr-xr-x 1 user group 3.2M mi_api.wasm

# Ejecutar localmente (arranca en <5ms)
spin up

# Test
curl http://localhost:3000/health
# {"status":"ok","runtime":"wasm"}

runwasi: el shim que conecta Wasm con Kubernetes

runwasi es el proyecto CNCF que permite a Kubernetes ejecutar módulos Wasm directamente, sin envolver en un contenedor OCI. Actúa como un containerd shim: cuando el scheduler asigna un pod con RuntimeClass: wasmtime, containerd delega la ejecución a runwasi en lugar de a runc.

# Instalar el shim de Wasmtime para containerd
RUNWASI_VERSION="v0.5.0"
curl -LO https://github.com/containerd/runwasi/releases/download/${RUNWASI_VERSION}/\
containerd-shim-wasmtime-v1-linux-amd64.tar.gz

tar -xzf containerd-shim-wasmtime-v1-linux-amd64.tar.gz
sudo install containerd-shim-wasmtime-v1 /usr/local/bin/

# Configurar containerd para reconocer el runtime Wasmtime
sudo tee -a /etc/containerd/config.toml << 'EOF'
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmtime]
  runtime_type = "io.containerd.wasmtime.v1"
EOF

sudo systemctl restart containerd

# runtime-class-wasmtime.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmtime
handler: wasmtime
scheduling:
  nodeClassification:
    tolerations:
      - key: "runtime"
        operator: "Equal"
        value: "wasm"
        effect: "NoSchedule"

Integración con Helm y el ecosistema Kubernetes

Una vez instalado el shim, desplegar módulos Wasm en Kubernetes es estructuralmente idéntico a desplegar contenedores OCI. La diferencia está en el RuntimeClass y en cómo se empaqueta el módulo.

Empaquetar un módulo Wasm como imagen OCI

El estándar emergente para distribuir módulos Wasm es empaquetarlos como artefactos OCI (sin sistema operativo base), usando registries estándar como GHCR, ECR o Docker Hub. Esto mantiene la compatibilidad con el tooling existente de CI/CD.

# Imagen de scratch: 0 bytes de base, solo el binario Wasm
FROM scratch

# Copiar solo el módulo compilado
COPY target/wasm32-wasi/release/mi_api.wasm /mi_api.wasm

# Etiqueta que indica al runtime que es un módulo Wasm
LABEL org.opencontainers.image.description="Wasm HTTP API"
LABEL dev.fermyon.spin.version="2.x"

# Build de la imagen OCI (~3 MB total)
docker build -t ghcr.io/nubyron/mi-api:wasm-v1.0.0 .
docker push ghcr.io/nubyron/mi-api:wasm-v1.0.0

# Verificar el tamaño real
docker manifest inspect ghcr.io/nubyron/mi-api:wasm-v1.0.0 | jq '.layers[].size'
# 3354112  ← 3.2 MB, sin capas de OS

Deployment de un módulo Wasm en Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-api-wasm
  namespace: produccion
  labels:
    app: mi-api
    runtime: wasm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mi-api
  template:
    metadata:
      labels:
        app: mi-api
        runtime: wasm
    spec:
      # Clave: usar el RuntimeClass de Wasmtime en lugar del default (runc)
      runtimeClassName: wasmtime

      containers:
        - name: mi-api
          image: ghcr.io/nubyron/mi-api:wasm-v1.0.0
          resources:
            requests:
              cpu: "10m"      # Wasm consume mucho menos CPU en idle
              memory: "16Mi"  # El módulo ocupa ~3 MB + stack mínimo
            limits:
              cpu: "500m"
              memory: "64Mi"
          ports:
            - containerPort: 3000
          env:
            - name: SPIN_LOG_LEVEL
              value: "info"
          # Health checks funcionan igual que en contenedores OCI
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 0   # Wasm arranca instantáneamente
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 0
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: mi-api-wasm
  namespace: produccion
spec:
  selector:
    app: mi-api
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Helm chart para módulos Wasm

# Valores por defecto para aplicaciones Wasm en nubyron
replicaCount: 3

image:
  registry: ghcr.io
  repository: nubyron/mi-api
  tag: "wasm-v1.0.0"
  pullPolicy: IfNotPresent

runtime:
  class: wasmtime          # RuntimeClass instalado en el cluster
  wasiCapabilities:
    http: true             # Peticiones HTTP salientes
    keyValue: true         # KV store
    filesystem: false      # Acceso a filesystem: deshabilitado por defecto

resources:
  requests:
    cpu: "10m"
    memory: "16Mi"
  limits:
    cpu: "500m"
    memory: "64Mi"

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 50
  # KEDA es ideal para Wasm: escala a cero con arranque instantáneo
  kedaEnabled: true
  scaleToZero: true
  cooldownPeriod: 30      # 30s sin tráfico → 0 réplicas

hpa:
  targetCPUUtilizationPercentage: 70

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "wasm-app.fullname" . }}
  labels:
    {{- include "wasm-app.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  template:
    spec:
      runtimeClassName: {{ .Values.runtime.class }}
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          env:
            - name: WASI_HTTP_ENABLED
              value: {{ .Values.runtime.wasiCapabilities.http | quote }}
            - name: WASI_KV_ENABLED
              value: {{ .Values.runtime.wasiCapabilities.keyValue | quote }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

# Instalar el chart de la app Wasm
helm install mi-api ./helm/wasm-app \
  --namespace produccion \
  --create-namespace \
  --set image.tag="wasm-v1.2.0" \
  --set autoscaling.scaleToZero=true

# Verificar que los pods usan el runtime Wasm
kubectl get pods -n produccion -o wide
# NAME                         STATUS   RUNTIME
# mi-api-wasm-7d9f8b-xk2p9    Running  wasmtime

# Los pods arrancan en <100ms desde scheduled
kubectl describe pod mi-api-wasm-7d9f8b-xk2p9 | grep -A5 "Events:"
# Events:
#   0s   Scheduled   Successfully assigned
#   0s   Pulled      Container image already present
#   0s   Created     Created container mi-api     ← 0 segundos
#   0s   Started     Started container mi-api     ← arranque instantáneo

Casos reales: edge computing y AI inference

Edge computing: Wasm como el runtime universal del edge

Las redes de edge computing (Cloudflare Workers, Fastly Compute, Akamai EdgeWorkers) llevan años ejecutando Wasm en producción porque resuelve su problema estructural: distribuir código a cientos de PoPs sin gestionar imágenes OCI de gigabytes, con arranque instantáneo y aislamiento fuerte entre tenants.

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
async fn edge_router(req: Request) -> anyhow::Result<impl IntoResponse> {
    // Los headers de geolocalización los inyecta el edge runtime
    let country = req.header("cf-ipcountry")   // Cloudflare
        .or_else(|| req.header("x-fastly-country-code"))   // Fastly
        .and_then(|h| h.as_str())
        .unwrap_or("US");

    // Routing hacia el origen más cercano basado en país
    let origin = match country {
        "ES" | "FR" | "DE" | "IT" | "PT" => "https://api-eu.nubyron.com",
        "US" | "CA" | "MX"               => "https://api-us.nubyron.com",
        "JP" | "KR" | "SG" | "AU"        => "https://api-apac.nubyron.com",
        _                                  => "https://api-us.nubyron.com",
    };

    // A/B testing en el edge: sin round trip al origen
    let ab_group = req.header("x-user-id")
        .and_then(|h| h.as_str())
        .map(|id| if id.chars().last().unwrap_or('0') < '5' { "A" } else { "B" })
        .unwrap_or("A");

    // Reescribir la petición y proxiar al origen correcto
    let mut forwarded_req = req.clone();
    forwarded_req.headers_mut().insert(
        "x-ab-group",
        http::HeaderValue::from_str(ab_group)?,
    );

    // Petición saliente al origen (capacidad WASI http habilitada)
    let backend_url = format!("{}{}", origin, req.uri().path_and_query()
        .map(|p| p.as_str()).unwrap_or("/"));

    let response = spin_sdk::http::send(
        http::Request::builder()
            .uri(backend_url)
            .method(req.method())
            .body(req.into_body())?
    ).await?;

    Ok(response)
}

AI inference: Wasm como runtime de modelos pequeños en el edge

El caso de uso más emergente en 2026 es ejecutar modelos de inferencia pequeños directamente en módulos Wasm, aprovechando las extensiones SIMD de WebAssembly para aceleración matemática sin GPU.

// WASI-NN es la extension de WASI para acceso a aceleracion neural
use wasi_nn::{Graph, GraphBuilder, GraphEncoding, ExecutionTarget, TensorType};

fn classify_intent(user_input: &str) -> anyhow::Result<String> {
    // Cargar el modelo ONNX desde el filesystem del modulo
    // El modelo va embebido en el artefacto Wasm (<50 MB para modelos pequeños)
    let graph = GraphBuilder::new(GraphEncoding::Onnx, ExecutionTarget::Cpu)
        .build_from_bytes(&[include_bytes!("../models/intent-classifier-v2.onnx")])?;

    let mut ctx = graph.init_execution_context()?;

    // Tokenizar el input (tokenizer también compilado a Wasm)
    let tokens = tokenize(user_input);
    let input_tensor = tokens_to_tensor(&tokens);

    // Inferencia: ~8ms en un nodo edge con Wasm SIMD
    ctx.set_input(0, TensorType::F32, &[1, 128], &input_tensor)?;
    ctx.compute()?;

    // Obtener el resultado
    let mut output_data = vec![0f32; 10]; // 10 clases de intención
    ctx.get_output(0, &mut output_data)?;

    // Devolver la clase con mayor probabilidad
    let max_idx = output_data.iter()
        .enumerate()
        .max_by(|a, b| a.1.partial_cmp(b.1).unwrap())
        .map(|(idx, _)| idx)
        .unwrap_or(0);

    Ok(INTENT_CLASSES[max_idx].to_string())
}

# Nodos edge etiquetados con location y hardware
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: intent-classifier-wasm
  namespace: ai-inference
spec:
  selector:
    matchLabels:
      app: intent-classifier
  template:
    metadata:
      labels:
        app: intent-classifier
        runtime: wasm
    spec:
      runtimeClassName: wasmtime

      # Desplegar en todos los nodos edge (no en los de control plane)
      nodeSelector:
        node-role: edge

      containers:
        - name: intent-classifier
          image: ghcr.io/nubyron/intent-classifier:wasm-v2.1.0
          resources:
            requests:
              cpu: "50m"
              memory: "128Mi"   # El modelo ONNX cabe en 80MB
            limits:
              cpu: "1000m"
              memory: "256Mi"
          env:
            - name: WASI_NN_BACKEND
              value: "cpu"      # cpu | cuda (si el nodo tiene GPU)
            - name: MODEL_PATH
              value: "/models/intent-classifier-v2.onnx"

Conclusión accionable

El ecosistema Wasm en Kubernetes ha pasado de experimento a producción. No como reemplazo total de los contenedores OCI —la mayoría de los workloads seguirán siendo contenedores durante años— sino como el runtime correcto para una clase específica de problemas: funciones de corta duración, edge computing, plugins aislados e inferencia de modelos pequeños.

La adopción tiene una curva clara y reversible. Cada paso es independiente:

1. Instala runwasi en un clúster de staging y crea el RuntimeClass de Wasmtime. No afecta a los workloads existentes. Un nodo con containerd 1.7+ puede ejecutar pods Wasm y pods OCI simultáneamente sin conflicto.

2. Compila una función existente a Wasm con Spin. Elige algo stateless: un webhook handler, un validador de JSON, una función de transformación de datos. Mide el tiempo de arranque y el tamaño de imagen contra su equivalente en contenedor.

3. Despliega con KEDA y escala a cero en el entorno de staging. Verifica que el cold start real sea inferior a 10ms bajo carga. Ese número es el argumento más convincente para cualquier conversación de arquitectura.

4. Evalúa WASI-NN si tienes modelos de clasificación o embeddings corriendo en contenedores. El ahorro en recursos de nodo puede justificar la migración por sí solo, especialmente en entornos multi-tenant donde el aislamiento actual depende de quotas de cgroups.

5. Contribuye al ecosistema: runwasi, Spin y Wasmtime son proyectos activos con buena documentación de good first issues. La comunidad es pequeña y los contribuidores tienen alto impacto. Si Wasm en producción funciona para vosotros, los issues que encontréis son exactamente lo que el proyecto necesita.

Referencias y recursos

Síntesis ejecutiva

Publicado en nubyron.com | 5 de abril de 2026

Tags: WebAssembly · Kubernetes · DevOps · Cloud Native · WASI · Edge Computing