日志显示堆转储已创建但Pod内无对应文件问题排查求助

核心原因：路径不匹配导致文件写入容器本地存储 #

你的Deployment中，PVC被挂载到了容器的/dumps/heap-dump路径，但JAVA启动参数里的堆转储路径设置为/dumps/demo-heap-dump——这个路径属于容器本地文件系统，而非挂载的PVC卷。当Pod因OOM崩溃后，容器的本地存储会被Kubernetes清理销毁，所以重新部署后的新Pod自然找不到这个文件。

修复方案 #

修改JAVA_TOOL_OPTIONS的HeapDumpPath为PVC挂载的子路径，确保文件写入持久化存储：

env:
- name: JAVA_TOOL_OPTIONS
  value: " -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=\"/dumps/heap-dump/demo-heap-dump\""

其他排查方向 #

1. 验证PVC名称的大小写一致性 #

Deployment中volumes部分的claimName写的是staging-filestore-PVC，但你创建的PVC实际名称是staging-filestore-pvc（全小写）。Kubernetes资源名称要求仅使用小写字母、数字、连字符和点，虽然部分场景可能兼容，但建议统一为小写避免挂载异常。可以通过以下命令检查Pod的挂载状态：

kubectl describe pod <你的Pod名称>

查看Volumes和VolumeMounts部分，确认PVC是否成功挂载。

2. 直接检查NFS服务器端文件 #

登录到NFS服务器（IP：10.64.16.130），查看/staging目录下是否存在堆转储文件：

ssh <服务器用户名>@10.64.16.130
ls -l /staging/

有时候Pod内的挂载可能存在缓存延迟，直接查看服务器端能更准确确认文件是否真的写入。

3. 检查挂载目录的权限 #

进入Pod后，查看PVC挂载目录的权限：

kubectl exec -it <你的Pod名称> -- sh
ls -ld /dumps/heap-dump

确认应用运行的用户（比如容器内的Java进程用户）拥有该目录的读写权限。如果权限不足，可以在Deployment的container部分添加securityContext配置，或者在NFS服务器上调整/staging目录的权限。

4. 查看崩溃Pod的完整日志 #

使用--previous参数查看崩溃Pod的完整日志，确认是否有隐藏的写入错误：

kubectl logs <崩溃的Pod名称> --previous

虽然日志显示堆转储文件已创建，但可能存在后续的IO异常导致文件未成功写入PVC。

内容的提问来源于stack exchange，提问作者Rando Shtishi