There's no way getting around needing to install the patched versions of the compiler or runtime. Someone has to do it and in my opinion it should be done internally so its controlled and has verified/known sources.
I think option/bullet 2 keeps things as streamlined as possible - base standard image for java apps that apps then use as their base when they build their container images to run in k8s containers. Maybe there's a way to tag base images with major.minor so that apps just pull that image and if its cached its faster and if there was a major.minor.patch just applied and you're the first app to deploy then that app pays the penalty of waiting for the underlying base image to be rebuilt.
A volume is an interesting idea but are there possible issues for OS library dependencies like openssl, database drivers, etc. that might not be the right version for a JDK mounted on a shared volume?
Java is the worse language to deal with in Kubernetes. You might want to look into Quarkus. I’m of the opinion that ditching Java for Go is better if possible.
Just my experience, but slow start times, high memory usage, tracking down GC pauses, getting the memory flags in line with the k8s resources config, and fat image sizes. All things I enjoy living without.
Also regarding Quarkus, that's java stuff. I don't use it, but I know people do use it for shortcomings of Java in k8s. Perhaps GraalVM is the thing that makes it worth-while, idk.
There's also a distroless Java container from Google that could be of value.
There's no way getting around needing to install the patched versions of the compiler or runtime. Someone has to do it and in my opinion it should be done internally so its controlled and has verified/known sources.
I think option/bullet 2 keeps things as streamlined as possible - base standard image for java apps that apps then use as their base when they build their container images to run in k8s containers. Maybe there's a way to tag base images with major.minor so that apps just pull that image and if its cached its faster and if there was a major.minor.patch just applied and you're the first app to deploy then that app pays the penalty of waiting for the underlying base image to be rebuilt.
A volume is an interesting idea but are there possible issues for OS library dependencies like openssl, database drivers, etc. that might not be the right version for a JDK mounted on a shared volume?
A patch is a change and for changes to be deployed they must go through the pipelines.
The new images are then rolled out in exactly the same controlled manner as any other new release.
Java is the worse language to deal with in Kubernetes. You might want to look into Quarkus. I’m of the opinion that ditching Java for Go is better if possible.
Why did you say so? Do you mind to elaborate more?
Just my experience, but slow start times, high memory usage, tracking down GC pauses, getting the memory flags in line with the k8s resources config, and fat image sizes. All things I enjoy living without.
Also regarding Quarkus, that's java stuff. I don't use it, but I know people do use it for shortcomings of Java in k8s. Perhaps GraalVM is the thing that makes it worth-while, idk.
There's also a distroless Java container from Google that could be of value.