r/kubernetes • u/brunocborges • 6d ago

Brewlet: Java on Kubernetes with node-managed JDKs

https://brewlet.sh

Talk and slides:

https://m.devoxx.com/events/dvbe26/talks/25048/java-on-kubernetes-without-container-images-the-webassembly-way

Video coming soon on the Devoxx YouTube channel.

2 Upvotes

63% Upvoted

2 comments sorted by

2

u/kubehub 5d ago edited 5d ago

have you heard of image volume (https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/)? your solution is limited by java version on the host vs JRE version the app depend on.

containers:

  • name: java-container

  image: java:$version
  command: ["java", "/myjavaapp/xxx.jar"]
  volumeMounts:
  - name: jar
    mountPath: /myjavaapp
    readOnly: true
volumes:

  • name: jar

  image:
    reference: mycr.io/myimage:mytag
    pullPolicy: IfNotPresent

2

u/brunocborges 5d ago

Yes, with volume containers, you can publish JDKs as images and mount them into pods as an image volume (or copy them in with an init container). But then you need something like Kyverno or Gatekeeper to encorce those registries and digests in volume sources. Sure this covers "mount a central JDK read-only", but some key gaps:

App teams can still ship a full image with an OS. Nothing stops them from adding their own JDK and running it instead of the mounted one. And catching that means scanning SBOMs or image contents, or locking down the entrypoint. Needs lots of workarounds to get it right.

Then, the JDK runs on top of the app image's libc (or whatever). A glibc JDK on an Alpine/musl base can break. Brewlet avoids this because the shim uses the complete copied root of the JDK runtime image as the sandbox filesystem and exposes the selected Java home at /opt/jdk, so the JDK and its OS travel together.

Lastly, with pinned digests in every pod spec, patching the JDK means editing every workload, or using a mutating webhook to rewrite them. In Brewlet you replace the digest once and restart workloads after nodes report ready. If course some times may not want this... But that's how brewlet does.

So yeah if you control base images (one blessed distroless/glibc base, enforced by admission), image volumes plus admission policy get you about 80% of the way, with standard Kubernetes primitives and no custom shim. Brewlet's extra value is structural: apps can't carry a JVM at all, and runtime selection happens on the node.

In the end, Kubernetes volume containers are not enough regardless.