容器存储是容器化部署中绕不开的难题。很多开发者第一次遇到容器数据丢失，往往是在升级镜像或重建容器之后——明明在容器里写入了文件，重启后却消失得无影无踪。这背后是容器可写层的生命周期问题。理解容器可写层与数据持久化的关系，是掌握容器存储的第一步。
为什么容器写入的数据会丢失
容器镜像由多个只读层组成，容器运行时会在这些只读层之上创建一个可写层，所有对文件系统的写入操作都发生在这一层。可写层与容器的生命周期绑定：当容器被删除，可写层也随之销毁。因此，容器内写入的数据默认不具备持久性。这是容器设计的核心特性，但也意味着必须使用卷（Volume）来保存需要长期保留的数据。
可写层的工作原理
在Linux上，容器可写层通常使用联合文件系统（如OverlayFS）实现。镜像层是只读的，可写层记录文件的变更。读取文件时，如果可写层没有该文件，则向下查找只读层；写入时则复制到可写层（写时复制）。这种机制让容器镜像可以被多个容器共享，节省存储空间，但可写层本身是临时的。
数据持久化：卷的引入
为了让数据在容器重建后依然存在，需要将数据存储在容器之外。卷（Volume）就是为此设计的抽象。卷可以是宿主机上的目录、网络存储或云盘。容器可以挂载卷，将数据写入卷中，卷的生命周期独立于容器。Kubernetes等容器编排系统提供了丰富的卷类型，并抽象出持久卷（PersistentVolume，PV）和持久卷声明（PersistentVolumeClaim，PVC）来管理存储资源。
临时卷与持久卷的取舍
并非所有数据都需要持久化。临时卷（如emptyDir）的生命周期与Pod相同，适合存放缓存、临时文件等。持久卷则适合数据库、日志等需要长期保存的数据。选择哪种卷，取决于数据的重要性和容错要求。例如，无状态应用可以容忍数据丢失，使用临时卷即可；有状态应用则必须使用持久卷。
Kubernetes中的存储抽象
Kubernetes通过PV和PVC将存储资源与使用解耦。管理员预先创建PV，用户通过PVC声明存储需求，Kubernetes负责将PV绑定到PVC。Pod通过PVC引用存储，无需关心底层实现。这种设计让存储管理更加灵活，也便于扩展。此外，CSI（Container Storage Interface）驱动允许第三方存储系统接入Kubernetes，提供更丰富的存储能力。
常见误区与失败条件
一个常见误区是认为容器内的数据总是安全的。实际上，除非使用卷，否则任何写入可写层的数据都会在容器删除时丢失。另一个误区是混淆临时卷与持久卷的用途，导致数据意外丢失。此外，在分布式环境中，仅依赖本地存储可能无法满足高可用要求，需要考虑网络存储或分布式存储方案。
参考资料
延伸阅读