Solomon Hykes, Mitgründer von Docker, sagte einmal: „Wenn WASM+WASI 2008 existiert hätten, hätten wir Docker nicht erschaffen müssen.” 2025 werden WebAssembly-Workloads in Kubernetes-Clustern Realität — und verändern, wie ein moderner Container aussieht.

Warum Container nicht ausreichen¶

Linux-Container sind eine fantastische Technologie. Isolation über Namespaces und cgroups, standardisierte Image-Formate, ein riesiges Ökosystem. Aber sie haben inhärente Einschränkungen, die immer deutlicher werden.

Cold Start: Das Starten eines Containers dauert Hunderte Millisekunden bis Sekunden. Für Serverless- und Event-Driven-Workloads ist das zu viel. AWS Lambda adressiert Cold Starts mit einer Custom Runtime, aber das ist ein herstellerspezifischer Hack, keine Lösung.

Größe: Ein minimales Container-Image umfasst Dutzende MB. Googles Distroless-Images reduzieren die Angriffsfläche, aber Sie packen immer noch den gesamten Userspace ein. Ein Wasm-Modul für die gleiche Funktionalität hat Hunderte KB.

Sicherheit: Container teilen sich den Kernel mit dem Host. Capability-basierte Sicherheit und seccomp-Profile helfen, aber die Angriffsfläche bleibt groß. Jeder Container-Escape-Exploit erinnert daran, dass die Isolation nicht vollständig ist.

Was WebAssembly bringt¶

WebAssembly (Wasm) wurde ursprünglich für Browser als Kompilierungsziel für C/C++/Rust entwickelt. Aber seine Eigenschaften — sandboxed Execution, near-native Performance, Plattformunabhängigkeit — machen es ideal für serverseitige Workloads.

WASI (WebAssembly System Interface) fügt standardisierten Zugriff auf Systemressourcen hinzu — Dateisystem, Netzwerk, Uhren, Zufallszahlen — ohne direkten Kernel-Zugriff. Ein Wasm-Modul läuft in seiner eigenen Sandbox mit explizit deklarierten Capabilities. Es hat keinen Zugriff auf etwas, das der Host nicht explizit erlaubt.

Die Zahlen sprechen für sich¶

• Cold Start: unter 1 ms (vs. 100–500 ms für Container)
• Modulgröße: 100 KB – 5 MB (vs. 20–500 MB für ein Container-Image)
• Speicher-Overhead: minimal — kein OS, kein Runtime-Overhead
• Sicherheit: Capability-basierte Sandbox, kein geteilter Kernel

SpinKube — Wasm in Kubernetes¶

Das SpinKube-Projekt (vormals containerd-shim-spin) integriert die WebAssembly-Runtime direkt in Kubernetes. Es fungiert als containerd-Shim — Kubernetes scheduled Wasm-Workloads genau wie Container, aber statt einer OCI-Runtime wird eine Wasm-Runtime (Wasmtime oder Spin) gestartet.

Kubernetes und WebAssembly — Eine neue Ära der Workloads¶

apiVersion: apps/v1

kind: Deployment

metadata:

name: my-wasm-app

spec:

replicas: 3

template:

spec:

  runtimeClassName: wasmtime-spin

  containers:

  - name: app

    image: ghcr.io/my-org/my-app:latest

    command: ["/"]

Aus Sicht des Operators ändert sich nichts — kubectl, Helm, ArgoCD, Monitoring — alles funktioniert. Wasm-Workloads sind First-Class Citizens im Kubernetes-Ökosystem. Der Unterschied liegt unter der Haube: schnellerer Start, kleinerer Footprint, stärkere Isolation.

Fermyon, Cosmonic und das Ökosystem¶

Fermyon mit dem Spin-Framework bietet eine Developer Experience ähnlich wie Serverless — Sie schreiben einen Handler in Rust, Go, TypeScript oder Python, kompilieren zu Wasm und deployen. Spin Cloud läuft vollständig auf Wasm ohne traditionelle Container.

Cosmonic (jetzt Teil des CNCF-Projekts wasmCloud) konzentriert sich auf verteilte Wasm-Anwendungen mit einem Actor-Modell. Komponenten kommunizieren über Capability Provider — eine Abstraktion, die den Wechsel der Implementierung (z.B. der Datenbank) ohne Neukompilierung der Anwendung ermöglicht.

Die CNCF hat mehrere Wasm-Projekte aufgenommen: wasmCloud, Krustlet (archiviert, ersetzt durch SpinKube), WasmEdge. Das Ökosystem konvergiert um WASI Preview 2 und das Component Model — Standards, die definieren, wie Wasm-Module interagieren.

Wo es heute Sinn macht¶

• Edge Computing: IoT-Gateways mit begrenzten Ressourcen, wo ein Container zu schwer ist. Ein Wasm-Modul läuft auf einem ARM-Gerät mit 256 MB RAM.
• Plugin-Systeme: Sichere Erweiterung von Anwendungen durch Dritte. Envoy Proxy Filter, Istio Extensions, Datenbank-UDFs — alles in sandboxed Wasm.
• Serverless Functions: Cold Starts unter einer Millisekunde beseitigen den Hauptschmerzpunkt von Serverless. Fermyon Spin und Fastly Compute@Edge beweisen dies in Produktion.
• Multi-Tenant SaaS: Jeder Tenant läuft in einer isolierten Wasm-Sandbox. Tausende Tenants auf einem einzigen Node ohne Bedenken wegen Datenlecks.

Wo es (noch) keinen Sinn macht¶

Zustandsbehaftete Workloads: Wasm ist für zustandslose Ausführung konzipiert. Datenbanken, Message Broker, verteilte Caches — die bleiben in Containern.

Bestehende Anwendungen: Eine Enterprise-Java-Anwendung nach Wasm zu portieren ist unrealistisch. Wasm ist für neue Workloads oder Komponenten, nicht für Lift-and-Shift.

Debugging und Observability: Das Tooling reift heran, liegt aber noch hinter dem Container-Ökosystem zurück. DWARF-Debug-Info in Wasm funktioniert, aber die IDE-Integration ist begrenzt.

Container + Wasm = die Zukunft¶

Es geht nicht um „Container oder Wasm.” Es geht um Container und Wasm nebeneinander im gleichen Cluster. Kubernetes ist die Orchestrierungsschicht für beide Workload-Typen. Schwere zustandsbehaftete Dienste laufen in Containern, leichtgewichtige Event-Driven-Funktionen in Wasm. Ein Cluster, einheitliches Management, unterschiedliche Runtime-Charakteristiken.

Wasm in K8s — Beobachten, experimentieren¶

WebAssembly-Workloads in Kubernetes sind nicht die Zukunft — sie sind die Gegenwart. SpinKube und wasmCloud laufen bei Early Adopters in Produktion. Das Ökosystem reift schnell.

Empfehlung: Installieren Sie SpinKube in Ihrem Dev-Cluster, deployen Sie Ihre erste Spin-Anwendung, messen Sie Cold Start und Ressourcenverbrauch. Daten überzeugen besser als jeder Blogpost.