部署于Kubernetes集群的Spring Boot应用找不到/tmp目录下的临时文件

常见触发原因 #

• 多副本路径错位：绝大多数这类找不到文件的情况，根源是你手动登录的Pod和日志里写入文件的Pod根本不是同一个。多副本部署下，Service的负载均衡会把外部API的请求随机转发到任意健康副本，没有任何机制保证请求一定会落到你手动exec进去的那个Pod上。很多开发者刚接触K8s时容易忽略这一点，随便挑一个Pod登进去找文件，自然毫无结果。
  快速验证方法：通过Downward API把Pod名称注入应用的环境变量，在日志框架的MDC中配置输出Pod名称，定位到具体执行写文件操作的Pod名称后，再用kubectl exec -it <目标Pod名> -- ls -l /tmp登录到指定Pod内查找，基本都能定位到目标文件。
• 文件写入后被即时清理：Java中File.createTempFile创建的文件本身不会被JVM自动删除，但如果业务逻辑在读取完临时文件的内容后，显式调用了stateFile.delete()，或是在创建文件后注册了stateFile.deleteOnExit()的退出钩子，整个文件处理流程跑完的瞬间文件就会被删掉。你手动登录Pod查看时，距离文件创建的时间已经过去了几秒甚至几分钟，文件早就被清理干净了。
  验证方式：在删除文件的代码分支前后加日志，打印删除操作的执行时间戳，和文件创建的日志时间做对照，就能确认是否在你查看之前文件就已经被删除了。
• Pod重启导致文件丢失：K8s容器的可写层是和容器生命周期绑定的临时存储，只要Pod因为OOM驱逐、健康探针失败、节点资源压力、镜像更新等原因重启，哪怕最终调度到同一个节点上，容器也会重建全新的可写层，/tmp目录下的所有文件都会被完全清空。你登录查看时，当前运行的容器是重启后的新实例，自然找不到旧容器中写入的文件。
• 隔离规则导致的可见性问题：如果Pod配置了严格的安全上下文，限制了不同用户间的文件目录访问权限，哪怕文件真实存在，非文件属主的用户登录后执行ls /tmp也看不到对应文件。另外要注意：容器内部的/tmp和宿主机节点的/tmp是完全隔离的两套文件系统，直接SSH登录到节点的/tmp目录找文件，是永远找不到目标文件的。

业务设计注意点 #

如果业务需要依赖临时文件做跨流程、跨实例的状态存储，不要依赖容器本地的/tmp目录——这种存储的临时属性和K8s容器的弹性调度特性天然不匹配，应该根据实际场景挂载共享存储卷（比如emptyDir、PersistentVolume），或是直接对接持久化存储服务做文件存放。

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