8 Scalability for Wasm with Kubernetes

WebAssembly brings small binaries, fast startup, and a strong security model, but it benefits from the mature orchestration and tooling of Kubernetes. The chapter shows how Kubernetes’s extensibility—through Custom Resource Definitions (CRDs) and operators—lets us treat Wasm as a first-class workload. By defining custom resources that feel like “applications,” controllers can reconcile desired state into running services, so Wasm components can plug into standard Kubernetes capabilities such as scheduling, networking, observability, and autoscaling.

With SpinKube, Spin applications are packaged as OCI images and run directly as pods via a Wasm-aware runtime class. The setup prepares a cluster, installs support for secure admission webhooks, adds a RuntimeClass that selects the Spin containerd shim, and registers SpinKube’s CRDs (SpinApp and SpinAppExecutor) plus its operator. From there, a Spin app is pushed to a registry, scaffolded into a SpinApp manifest, and applied like any other Kubernetes object. The chapter then demonstrates scaling with a Horizontal Pod Autoscaler by adding CPU- and memory-based targets, setting resource requests and limits, generating load, and observing the operator and HPA scale replicas up and down automatically (with KEDA presented as an alternative event-driven autoscaler).

wasmCloud integrates differently: instead of a node runtime shim, it deploys its application platform into the cluster (hosts, a message broker, and a deployment manager). You install the platform, create hosts with WasmCloudHostConfig, and deploy applications via an Application CRD—reusing the same wadm specs used outside Kubernetes—and operate them with kubectl or wash. The chapter contrasts the operational experience: SpinKube makes Wasm look like conventional pods managed with native tools, while wasmCloud centralizes lifecycle and linking inside its platform. A complete end-to-end example culminates by running the multi-component SmartCMS application on Kubernetes with wasmCloud, including an Ollama-backed provider, illustrating how both approaches scale Wasm workloads using familiar cluster primitives.

Kubernetes architecture showing the control plane (API server, scheduler, controller manager) and data plane (nodes with pods). The control plane manages cluster state and makes scheduling decisions, while the data plane runs the actual workloads. Users interact with the cluster through the API server, typically using kubectl commands or YAML manifests.

How a Wasm operator fits into Kubernetes: the user deploys a Wasm app by submitting a CR to the Kubernetes API server. This resource is defined by a Wasm-specific CRD, which is handled behind the scenes by a Wasm operator.

Architectural comparison of SpinKube and wasmCloud in Kubernetes. SpinKube (left) extends the container runtime with a Wasm shim to run Spin applications directly as pods. wasmCloud (right) deploys its platform components (NATS, wadm, and hosts) as regular Kubernetes pods, then orchestrates Wasm workloads within those hosts. Both approaches use CRDs and operators but integrate at different layers of the stack.

• Wasm can reuse mature, battle-tested components of the container ecosystem, like Kubernetes. This helps solve problems where there’s no good Wasm-native solution yet.
• Custom Resource Definitions (CRDs) and operators enable Kubernetes to manage non-container workloads, including Wasm apps, using native patterns for orchestration and scaling.
• SpinKube integrates Spin with Kubernetes, providing CRDs and an operator that understands how to deploy, scale, and manage Spin applications using Kubernetes-native primitives.
• The Spin kube plugin streamlines deployment by scaffolding Kubernetes manifests for Spin applications, making it easy to move from local dev to production.
• Kubernetes’s Horizontal Pod Autoscaler (HPA) can be integrated with Spin apps, allowing replicas to scale dynamically based on CPU and memory load.
• Unlike SpinKube, wasmCloud does not rely on a specialized container runtime; instead, it deploys its full host environment inside the cluster and manages apps through NATS and wadm.

FAQ