您如何处理在K8s上运行的Java应用程序的JDK/JRE补丁更新？
我很好奇在Kubernetes上运行Java工作负载的人是如何处理JDK/JRE更新和安全补丁的，而不需要重建每个应用镜像。
背景：在使用[Mesos](https://en.wikipedia.org/wiki/Apache_Mesos)的时代，我们通常将JDK保留在运行节点上。当出现CVE或补丁时，我们会更新主机上的JDK，所有应用都会自动使用更新。这对于快速的安全发布非常方便。而在Kubernetes上，我看到几乎所有人都将JDK打包进容器镜像中，这意味着：新JDK → 重建基础镜像 → 重建应用镜像（或至少重建基础镜像）→ 推送 → 部署。这种方式可靠且可重现，但例如，对于2000个应用来说，快速更新JDK版本几乎是不可能的。
我对在Kubernetes上大规模运行Java的人有几个问题：
* 你们会为每个JDK补丁重建镜像吗？
如果会，你们是如何保持流水线快速和自动化的？
我们讨论过的一些方法（仍在寻找更好的方案）：
- 每次JDK补丁都重建镜像（CI流水线自动更新基础镜像并重建）：可重现但繁重且缓慢。
- 通过hostPath或共享卷提供主机JDK（类似Mesos）：补丁快速，但脆弱（节点漂移、Kubernetes节点间版本混乱、可重现性差、潜在的安全/权限问题）。
- 为所有Java应用提供基础标准镜像（alpine+java），由我们的平台进行更新，并在启动时通过init容器下载用户应用，这样我们可以在后台进行更新。
- 侧车或init容器将JDK放入共享卷中，应用容器使用该卷：可变运行时而无需重建镜像——在实践中效果如何？
查看原文
I’m curious how people running Java workloads on Kubernetes handle JDK/JRE updates and security patches without rebuilding every app image.<p>Background: in [Mesos](https://en.wikipedia.org/wiki/Apache_Mesos) times, we used to keep the JDK on the runner nodes. When a CVE or patch came out, we updated the host JDK, and all apps picked it up. That was convenient for fast security rollouts. On k8s, almost everyone I see bakes the JDK into the container image, which means: new JDK → rebuild base image → rebuild app images (or at least rebuild base) → push → roll out. That is reliable and reproducible, but it is impossible to update the JDK version for, for example, 2000 apps quickly.<p>Questions I have for people who run Java on k8s at scale:<p><i>Do you rebuild images for every JDK patch?</i><p>If so, how do you keep the pipeline fast/automated?<p>What approaches we talked about (still looking for something better):<p>- Rebuild images on every JDK patch (CI pipeline that automatically bumps base image + rebuilds): reproducible but heavy and slow.<p>- Host-provided JDK (like Mesos) via hostPath or a shared volume (every path version must be available): fast patches, but brittle (node drift, version chaos between k8s nodes, less reproducible, potential security/permission problems).<p>- Base, standard image for all java apps (alpine+java) that our platform updates and init container downloading user app on startup, so that we can update it in the background.<p>- Sidecar or init-container that places a JDK into a shared volume, and the app container uses that volume: mutable runtime without rebuilding images — how well does this work in practice?