wasmCloud on Kubernetes

wasmCloud can run standalone or on Kubernetes. The optional wasmcloud-operator utilizes the operator pattern and custom resource definitions (CRDs) to run wasmCloud hosts on Kubernetes—and thereby take full advantage of WebAssembly components in Kubernetes environments.

With a Kubernetes cluster running the wasmCloud operator, launching components as Kubernetes services can be as simple as running kubectl apply on a wadm manifest:

shell

kubectl apply -f wadm.yaml
application/echo created

For instructions on how to deploy wasmCloud with Kubernetes, see the Kubernetes page in our Operator Guide. You can also watch a video of the quickstart on YouTube:

How we run WebAssembly on Kubernetes

wasmCloud hosts can run on a Kubernetes cluster or external to it. Regardless of where hosts are running, they can be connected on a lattice. Kubernetes handles infrastructure management (the job for which it is designed) by orchestrating wasmCloud hosts, while wasmCloud handles application-level operations with full support for component capabilities.

This separation of concerns—Kubernetes for infrastructure, wasmCloud for applications—means that WebAssembly runtime operations are unconstrained by container-centric frameworks and abstractions; wasmCloud can extend Kubernetes to provide new hybrid compute options and expand the frontiers of computing.

• Avoid lock-in to proprietary systems
• Run on existing cloud native infrastructure
• Leverage and build on the most powerful and singular features of the WebAssembly component model, such as composability and interoperability

Running Wasm Components in Kubernetes with containerd shims significantly reduces the distributed architecture possibilities for the application.

When deployed with a "Decoupled" pattern, wasmCloud applications can be deployed on Kubernetes clusters while still retaining all the benefits of more distributed architectures.

Components and cloud native standards

wasmCloud is designed to conform to cloud native standards, making it simple to use existing tooling for everything from observability to policy to registries.

• Open Policy Agent: wasmCloud's policy service API makes it easy to communicate with external policy servers using engines like Open Policy Agent.
• OpenTelemetry: wasmCloud emits OpenTelemetry signals for traces, logs, and metrics, compatible with your favorite observability tooling.
• Backstage: Develop Backstage plugins with any language using Cosmonic Labs' bigband project.
• Argo CD: Smoothly integrate Argo CD for GitOps flow using our concordance-gitops example.
• Pull from OCI registries: wasmCloud pulls Wasm components packaged as Open Container Initiative (OCI) images—so it's simple to store application components and providers in your existing private registries.
• Open Application Model (OAM): wasmCloud manifests use the same Open Application Model specification as most Kubernetes extensions. If you've worked with K8s, you should be right at home.

Further reading

Find more details on deployment and configuration of wasmCloud on Kubernetes in the Kubernetes page of our Operator Guide.