Using WASM Functions

How to run, develop, and deploy WebAssembly (WASM) functions with kpt.

WASM functions are an alternative to container-based KRM functions. They’re faster to start, smaller to distribute, and run in a sandboxed environment.

Why use WASM functions? #

Note WASM support in kpt is currently in alpha and not ready for production use. The API and behavior may change in future releases.

WASM functions have some advantages over container-based functions:

Faster startup - no container runtime needed
Smaller size - WASM modules are typically much smaller than container images
Better security - sandboxed execution with no host access by default
More portable - run anywhere WASM is supported
Lower resource usage

Running WASM functions #

WASM support is an alpha feature. You need to use the --allow-alpha-wasm flag to enable it.

With `fn render` #

Add the WASM function to your Kptfile pipeline:

# Kptfile
apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: my-package
pipeline:
  mutators:
    - image: example.registry.io/my-org/my-wasm-fn:v1.0.0
      configMap:
        key: value

kpt fn render my-package --allow-alpha-wasm

kpt will detect the function as WASM if the OCI image has a js/wasm platform manifest.

With `fn eval` #

Run WASM functions imperatively:

kpt fn eval my-package --allow-alpha-wasm -i example.registry.io/my-org/my-wasm-fn:v1.0.0 -- key=value

Using local WASM files #

You can run local .wasm files with the --exec flag:

kpt fn eval my-package --allow-alpha-wasm --exec ./my-function.wasm

You can also declare local WASM files in your Kptfile:

# Kptfile
apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: my-package
pipeline:
  mutators:
    - exec: ./functions/my-function.wasm

kpt fn render my-package --allow-alpha-wasm --allow-exec

Note: Using local WASM files makes your package less portable since the file needs to exist on every system.

Publishing WASM functions #

Push a WASM module #

Compress and push a WASM module to an OCI registry:

kpt alpha wasm push ./my-function.wasm example.registry.io/my-org/my-wasm-fn:v1.0.0

What this does:

Compresses the WASM file into a tar archive
Creates an OCI image with js/wasm platform
Pushes to the registry

Pull a WASM module #

Download and decompress a WASM module:

kpt alpha wasm pull example.registry.io/my-org/my-wasm-fn:v1.0.0 ./my-function.wasm

Useful for:

Testing WASM functions locally
Inspecting modules
Offline caching

Developing WASM functions #

WASM functions follow the KRM Functions Specification. They receive a ResourceList as input and return a ResourceList as output.

What you need #

A language that compiles to WASM (Go, Rust, etc.)
WASM build toolchain
KRM functions SDK

Example: Go WASM function #

For a complete working example of a Go WASM function, see the starlark function in the krm-functions-catalog, which shows the two-file pattern (run.go for regular builds and run_js.go for WASM builds).

Build for WASM #

GOOS=js GOARCH=wasm go build -o my-function.wasm .

Test locally #

kpt fn eval ./test-package --allow-alpha-wasm --allow-exec --exec ./my-function.wasm

Publish #

Push to a registry:

kpt alpha wasm push ./my-function.wasm example.registry.io/my-org/my-wasm-fn:v1.0.0

# Test the published version
kpt fn eval ./test-package --allow-alpha-wasm -i example.registry.io/my-org/my-wasm-fn:v1.0.0

Complete example #

From development to deployment:

# 1. Write your function code (main.go and main_js.go)

# 2. Build
GOOS=js GOARCH=wasm go build -o my-function.wasm .

# 3. Test locally
kpt fn eval ./test-package --allow-alpha-wasm --exec ./my-function.wasm

# 4. Publish
kpt alpha wasm push ./my-function.wasm example.registry.io/my-org/my-wasm-fn:v1.0.0

# 5. Use in a package
cat <<EOF > Kptfile
apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: my-package
pipeline:
  mutators:
    - image: example.registry.io/my-org/my-wasm-fn:v1.0.0
EOF

# 6. Render
kpt fn render my-package --allow-alpha-wasm

Limitations #

Alpha status #

WASM support is alpha, which means:

API may change
Requires --allow-alpha-wasm flag
Some features may be limited

Security #

WASM functions are designed to run in a sandboxed environment, but the exact security properties depend on the WASM runtime and how it is configured:

Some runtimes (for example, wasmtime with default settings) do not grant network or filesystem access unless you explicitly enable those capabilities.
Other runtimes (for example, a Node.js-based WASM runtime) execute the module within a local node process, where filesystem and network access may be possible depending on the glue code and module implementation.
In all cases, you should treat the WASM runtime as part of your trusted computing base and review its configuration and allowed host APIs.

Compared to running arbitrary container images, a well-configured WASM runtime can offer stronger isolation, but the actual security guarantees depend on the chosen runtime and its configuration.

Performance #

Faster startup than containers
CPU-intensive operations may be slower
Different memory patterns
Benchmark if performance is critical

Compatibility #

Not all container functions can convert to WASM:

Functions needing network access
Functions with complex dependencies
Platform-specific code