Java微服务上Kubernetes的核心是JVM与容器资源对齐及显式生命周期控制：需设-XX:ActiveProcessorCount、-Xms/-Xmx（≤75% memory limits）、非root启动；Deployment必须配liveness/readinessProbe、minReadySeconds；集群内调用API须用InClusterConfig；Service需正确配置targetPort、selector和type。
Java微服务上Kubernetes，不是“能不能”，而是“怎么配才不翻车”——核心卡点在JVM与容器资源边界的对齐，以及Deployment/Service生命周期的显式控制。
Java应用容器化时JVM参数必须显式限制CPU和内存
容器里跑JVM，cgroup限制了资源，但默认JVM会按宿主机CPU核数和内存总量初始化线程池、堆大小，结果就是：Pod被OOMKilled、GC频繁、CPU限频却仍报高负载。
-
-XX:ActiveProcessorCount=N必须设，N等于resources.limits.cpu向下取整（比如cpu: "1500m"→ N=1） -
-Xms和-Xmx必须设为相同值，且不超过resources.limits.memory的75%（留空间给Metaspace、Direct Buffer等） - 避免用
-XX:+UseContainerSupport（JDK 10+已默认开启），但要确认JDK版本 ≥ 8u191 或 ≥ 10 - 镜像中用非root用户启动，否则
securityContext.runAsNonRoot: true会直接拒绝调度
Deployment配置里replicas和探针缺一不可
只写replicas: 3不够，Kubernetes不会自动判断你的Java服务是否真就绪。没有livenessProbe和readinessProbe，滚动更新时流量会打到还没启动完的Pod，或卡死的Pod上持续转发。
-
readinessProbe建议用Spring Boot Actuator的/actuator/health/readiness端点，initialDelaySeconds: 30（Spring Boot冷启动常需20–40秒） -
livenessProbe用/actuator/health/liveness，失败后Kubernetes会重启容器，而非等待JVM自己恢复 -
minReadySeconds: 10加在Deployment spec里，确保新Pod就绪后至少稳定10秒才开始下一批更新 - 不要依赖
startupProbe替代readinessProbe，它只解决启动慢问题，不解决运行中假死
Kubectl Java客户端调用Kubernetes API容易忽略context切换
本地开发用ClientBuilder.defaultClient()能连~/.kube/config，但部署到集群内时，若没显式指定InClusterConfig，会因权限不足报io.kubernetes.client.openapi.ApiException: Forbidden。
立即学习“Java免费学习笔记（深入）”；
- 集群内运行必须用
ClientBuilder.clusterRoleClient()或手动加载in-cluster config -
Kubectl.get(V1Pod.class).namespace("default")这种写法在多命名空间场景下极脆弱，应始终显式传入namespace参数 - 批量操作（如查所有Pod）慎用
.execute()，考虑加.limit(500)防API Server限流 - 异步执行推荐用
Kubectl.watch()而非轮询，但注意watch连接超时后需重连逻辑
Service暴露方式选错会导致Java服务根本不可达
用type: ClusterIP只能集群内访问，但很多Java服务需要被Ingress或外部LB转发——这时候如果没配targetPort或port映射错，请求根本进不到容器。
-
targetPort必须和容器EXPOSE及Java应用实际监听端口一致（如Spring Boot默认8080） - 若用Ingress，Service的
port字段必须是数字，不能是名称；且Ingress规则中的service.port.number要与之匹配 - 避免在Service里漏写
selector，否则Endpoints为空，kubectl get endpoints会显示<none> - 调试时优先用
kubectl port-forward service/<name> 8080:8080直连验证，绕过DNS和网络策略干扰
最常被跳过的一步：上线前用kubectl describe pod <pod-name>看Events里有没有FailedScheduling或OOMKilled，这些信息比日志更早暴露资源配置矛盾。
