Java应用部署到K8s需先容器化并适配容器生命周期：启用-XX:+UseContainerSupport、合理配置liveness/readiness探针（如/actuator/health/readiness）、避免检查数据库连通性，Spring Boot 2.3+推荐用bootBuildImage构建镜像。
Java应用怎么部署到K8s上，不是搭K8s集群
Java项目本身不“搭”K8s环境——K8s是基础设施层，Java应用只是它的负载。你真正要做的，是把打包好的Java服务（通常是jar或war）容器化，再用YAML描述它怎么跑在K8s里。
常见误区：花几天装minikube或k3s，结果发现Java服务根本没适配容器生命周期，一启动就OOM或健康检查失败。
- 先确认你的Java服务能跑在容器里：
java -jar app.jar启动后必须长期驻留（不能启动完就退出），且监听的端口要明确（比如8080） - 别直接用
openjdk:17-jre-slim镜像就完事——JVM参数得调：-XX:+UseContainerSupport必须开，否则JVM会无视cgroup内存限制，导致Pod被OOMKilled - Spring Boot 2.3+默认支持
Buildpacks，用./gradlew bootBuildImage可直接生成OCI镜像，比手写Dockerfile更稳
Java应用的liveness/readiness探针怎么写才不翻车
K8s靠探针判断Java服务是否“活”着，但直接套用HTTP GET /actuator/health，很容易误杀。
典型错误现象：Readiness probe failed: HTTP probe failed with statuscode: 503，其实服务已经起来了，只是Actuator还没就绪，或者数据库连接慢拖住了健康检查链路。
立即学习“Java免费学习笔记（深入）”；
-
readinessProbe别检查数据库连通性——它只该反映“能否接收流量”，建议用/actuator/health/readiness（Spring Boot 2.3+），并设initialDelaySeconds: 30 -
livenessProbe别太激进：Java应用GC停顿可能长达几秒，timeoutSeconds至少设为5，failureThreshold建议3，避免因一次GC卡顿就被重启 - 如果用的是传统War包+Tomcat，探针路径得改成
/your-app/actuator/health，注意上下文路径（context path）是否带前缀
Java应用内存超限被K8s杀掉，和JVM参数有什么关系
Pod状态显示OOMKilled，但jstat看堆才用了1G——这不是Java代码问题，是JVM没正确读取容器内存限制。
原因很简单：旧版JVM（-Xmx，导致申请超限被K8s干掉。
- 必须用JDK 8u191+、JDK 11.0.2+ 或 JDK 17+，并显式加参数：
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 - 别再写死
-Xmx2g——容器里分配了2Gi内存，但JVM可能按宿主机16G算出2g，实际可用远低于此；用MaxRAMPercentage让JVM按容器cgroup动态算 - 注意：
MaxRAMPercentage只控制堆，直接内存（-XX:MaxDirectMemorySize）、元空间（-XX:MaxMetaspaceSize）、线程栈（-Xss）也得预留，总和别超容器limit
Java服务滚动更新时请求499/502，怎么平滑过渡
执行kubectl rollout restart deploy/my-java-app后，前端立刻报错，不是连接拒绝就是上游关了——这是没处理好优雅下线。
Java进程收到K8s发的SIGTERM后，默认立刻退出，但Spring Boot的Shutdown Hook、Netty连接池、RabbitMQ消费者都来不及清理。
- Spring Boot 2.3+ 开启
server.shutdown=graceful，并设spring.lifecycle.timeout-per-shutdown-phase=30s，确保HTTP连接逐步关闭 - 在Deployment里配
terminationGracePeriodSeconds: 60，比JVM优雅停机时间多留缓冲（网络延迟、连接池回收等） - readinessProbe成功后，K8s才把Pod加入Endpoint；但livenessProbe失败前，它仍可能收请求——所以务必让readiness探针真实反映“已准备好接流”，而不是“JVM没挂”
最常被忽略的一点：Java应用日志里看不到SIGTERM被接收，不代表没收到——得在代码里加Runtime.getRuntime().addShutdownHook()打日志验证，否则你以为它优雅了，其实早被强制kill了。
