emptyDir能跨容器重启保留，为何仍属于Pod的临时数据

应用容器重启后还能看到文件，有时会让人以为这份数据已经获得了长期保存能力。对Kubernetes的emptyDir而言，这种推断跨过了一个关键边界：容器的生命周期与Pod的生命周期不是同一个层次。

目录从Pod分配到节点时开始

Kubernetes官方Volumes文档说明，声明emptyDir卷的Pod被分配到节点时，该卷随之建立，初始为空。Pod中的容器可以读写其中相同的文件，各容器内的挂载路径可以相同，也可以不同。因此，emptyDir表达的是Pod内的一份共享卷，并非每次容器启动都另外生成一套互不相关的目录。

这与容器自身文件系统的临时状态需要区分。文档在介绍卷的意义时指出，容器崩溃后会以干净状态重启；而卷的抽象让数据能够跨容器重启保留。观察到文件仍在，首先说明需要辨认它存放在哪类位置，不能只看“容器重启过”就判断所有文件应当消失或全部受到保护。

容器崩溃没有自动变成Pod移除

emptyDir一节特别注明，容器崩溃不会把Pod从节点上移除，emptyDir中的数据可以跨容器崩溃保留。这里的因果关系很明确：发生变化的是容器，Pod与卷的生命周期关系仍在。把这项说明缩写成“重启不丢数据”，就省掉了原文所限定的对象。

原文另一条规则是，Pod因任何原因被移出节点时，emptyDir数据会被永久删除。这与前述规则并不矛盾，因为讨论的是不同事件。一个新的Pod出现，也不能仅凭它承担相同应用任务，就认定旧emptyDir的数据会被继承。临时卷绑定的是特定Pod，而不是抽象的业务名称。

保留机制不是数据备份结论

“跨容器崩溃保留”只回答生命周期中的一项变化，不证明应用写入已经完整，也不等于节点故障、Pod替换或其他变化都受到相同保障。本文没有连接集群，没有实施容器重启、删除、迁移或恢复测试，因此不提供生产变更与数据恢复步骤。

讨论云原生存储资料时，可以把问题明确成：变化的是容器，还是原有Pod已经离开节点？这是一种解释文档的方法，不替具体环境判定原因。所读页面区分临时卷与持久卷，但本篇不据此设计替代存储方案，只说明emptyDir的数据保留范围。保留原文的事件与对象，才能让“文件还在”这一观察回到它实际能证明的事情。