Java 项目在 Ubuntu 下的 K8s 环境报错，通常不是代码逻辑问题，而是容器化适配或资源配置问题，最推荐的做法是先通过 kubectl 查看 Pod 状态和日志，定位是启动失败、内存溢出还是网络不通。

命令速用版

以下命令可快速定位 Pod 异常原因，请在拥有集群访问权限的终端执行：

# 查看 Pod 运行状态
kubectl get pods -n <命名空间>

# 查看 Pod 详细事件（重点看 Reason 和 Message）
kubectl describe pod <Pod 名称> -n <命名空间>

# 查看容器日志（排查应用启动报错）
kubectl logs <Pod 名称> -n <命名空间>

# 进入容器内部验证网络或环境
kubectl exec -it <Pod 名称> -n <命名空间> -- /bin/sh

为什么会这样

本地 Ubuntu 环境与 K8s 容器环境存在本质差异。首先，JVM 默认会根据宿主机的物理内存计算堆大小，而在容器中，如果不显式配置，JVM 可能尝试申请超过容器限制（limit）的内存，导致被 K8s 直接杀死（OOMKilled）。其次，K8s 的存活探针（Liveness Probe）和就绪探针（Readiness Probe）有超时限制，Java 应用启动较慢，若探针配置过严，容器会在应用完全启动前被重启。此外，服务发现机制也不同，本地常用的 localhost 在 K8s 中通常需要替换为 Service 名称。

分步处理

1. 检查 Pod 状态与退出码

执行 kubectl get pods 观察状态。若显示 OOMKilled，说明内存不足；若显示 CrashLoopBackOff，说明应用启动后异常退出。使用 kubectl describe pod 查看最后状态字段中的 Exit Code，退出码 137 通常代表内存溢出，退出码 1 代表应用内部错误。

2. 调整 JVM 内存配置

在 Deployment 的 YAML 文件中，确保容器的 resources.limits.memory 大于 JVM 的最大堆内存。建议在启动命令中显式设置堆大小，例如：

java -Xms512m -Xmx512m -jar app.jar

同时，在容器配置中预留部分内存给非堆内存（如元空间、线程栈），容器限制值建议比 Xmx 大一些，确保留有缓冲空间。

3. 修正探针配置

若日志显示应用正在启动但容器反复重启，检查 YAML 中的 livenessProbe 和 readinessProbe。适当增加 initialDelaySeconds（初始延迟）和 failureThreshold（失败阈值），给 Java 应用足够的预热时间。

4. 核对环境变量与配置

本地开发常使用配置文件或硬编码，K8s 中建议通过 ConfigMap 或 Secret 注入。检查 kubectl describe pod 输出中的 Environment 部分，确认数据库地址、中间件账号等关键变量已正确挂载且无拼写错误。

怎么验证是否生效

完成调整后，重新部署应用并观察状态。执行 kubectl get pods，状态应变为 Running 且重启次数（RESTARTS）不再持续增加。使用 kubectl logs 确认日志末尾出现“启动成功”或类似业务就绪信息。若服务暴露了端口，可在集群内其他 Pod 中使用 curl 命令测试接口连通性，确保网络策略未阻断流量。

常见坑

1. 文件路径依赖

代码中若写入绝对路径（如 /var/logs），需确保容器镜像中该目录存在且有写入权限，否则会导致启动报错。建议改为相对路径或挂载持久化卷。

2. 时区不一致

容器默认时区可能是 UTC，而本地 Ubuntu 可能是 CST。若业务依赖时间计算，需在 Dockerfile 中设置时区或通过环境变量 TZ 修正，避免日志时间和业务逻辑偏差。

3. 随机端口问题

部分 Java 应用（如被动 FTP 或特定 RPC）会启用随机端口，K8s 默认网络策略可能不允许。建议固定服务端口，或在 SecurityGroup 和网络策略中放宽限制，但需注意安全风险。