Java on Kubernetes Without Container Images: The WebAssembly Way

Every time you ship a Java service to Kubernetes, you ship a base image, a bundled JDK, and an OS layer. None of which you wrote besides your application code and the selection of dependencies, but all of which you must monitor and regularly patch. The real artifact you care about, your application JAR and its dependencies, are buried inside 250 MB of packaging you never wanted to own. WebAssembly already solved this. With KWasm, the Wasm runtime lives on the node, the developer ships only a .wasm module as an OCI artifact, and a RuntimeClass tells Kubernetes to execute it. There is no Dockerfile, no container image involved at all.

Most Kubernetes users know that "runtimeClassName: kata" or "runtimeClassName: wasm" routes a pod to a different executor. Few know how this works with the containerd Runtime v2 TTRPC protocol, OCI bundle assembly, overlay filesystems, and runc delegation that make all this possible.

In this talk we walk through how the KWasm analogy actually maps cleanly to Java, and what custom containerd shims, node provisioners, and CRDs can actually do: allow you to build your own Kubernetes-based platform (and quite easily with agentic AI). We will explore a new open source project called Brewlet.sh with live coding: its CLI brewlet push target/app.jar, the Kubernetes deployment approach kubectl apply, and see in practice how a Spring Boot service runs on Kubernetes without a single container image in sight.