-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compile to WASM #675
Comments
Kruslet doesn't appear to support pulling from indexes at all, only OCI artifacts with the WASM media types. So this is probably not going to be something worth shoehorning into ko. This might still make sense as a separate Go-specific pipeline for building WASM images, a la wasm-to-oci with fewer steps, but it won't coexist alongside regular OCI images. |
A braindump after thinking about this a bit more: So in order for this to work, I think we need to agree on a few things with whatever run-this-OCI-image-as-wasm runtime we're working with: If the runtime:
Then What this would enable is, a Advantages:
Some limitations:
|
Reopening as I still think this is an idea worth pulling on. |
cf: Istio's WASM plugins are also packaged as OCI images (building tutorial, spec) TL;DR: In this case, the format seems to be:
This seems fine for Istio, there's not a lot of use cases for multi-platform WASM and non-WASM plugins there I think, but it's something to consider as folks have gone down this path before and made certain decisions. |
ref: Similar discussion in buildpacks, to allow buildpacks to run and produce a wasm image instead of the standard OCI image: buildpacks/lifecycle#820 In this case, it would be either-or, and buildpacks wouldn't create a single multi-platform index containing the wasm image and the standard linux/amd64 (e.g.) image. But maybe if that was supported somewhere, they could. |
This is indeed very interesting! crun has implementations for handling WASI Images already, but is toggled via a feature flag which needs to bet set during crun compile time: https://github.com/second-state/wasmedge-containers-examples/blob/fb049e4d9884699622ffea0963a77f9d7f0b1f39/containerd/install.sh#L38 Kubernetes pods, if containerd, cri-o etc. don't use the rebuilt crun binary by default, include a runtimeClass in their spec. But all of that has some issues: std go doesn't yet provide a way to generate binaries for target WASI. We would need to use tinygo to target wasi, so the options would be: If this is something to look forward to, I'd be happy to try and provide an experimental PR. |
This issue is stale because it has been open for 90 days with no |
Go can compile to WASM (
GOOS=js GOARCH=wasm
), and WASM can be packaged into images and executed on K8s clusters using krustlet: https://developer.okta.com/blog/2022/01/28/webassembly-on-kubernetes-with-rustSo, maybe
ko
can build a WASM executable, and put it in a multiarch image, alongside the other ko-built archs.This wouldn't work for Go executables that need to call into their base images (I don't think WASM images have multiple layers, and the environment isn't very linux-ey...yet?), but it should mostly maybe kinda work if they're just static binaries, which is exactly ko's sweet spot.
An example WASM image that kruslet can apparently run: https://explore.ggcr.dev/?image=webassembly.azurecr.io%2Fhello-wasm%3Av1 -- note media types and the annotation.
Questions:
What OCI platform does kruslet expect when it's given a multiplatform image?
js/wasm
?How should users express this?
ko build ./ --wasm
to additionally produce a WASM image in the index?The text was updated successfully, but these errors were encountered: