云存储硬核技术内幕——(25) 送你一朵小红花

同学们好，方老师又与大家见面了。

从今天起，我们开始探索一个新的领域——云原生存储。

云原生(Cloud Native)指的是从应用设计、开发、构建、部署、运行到迭代的一整套体系框架。云原生基金会CNCF(Cloud Native Computing Foundation)认为，云原生需要三大要素：微服务、DevOps和容器。因此，在云原生时代，云存储需要解决的问题，就是存储与容器适配。

使用过容器的同学会发现，容器与其所在的服务器Host OS，实际上是不同的平行世界。

让我们做一个实验：

首先，我们启动一个CentOS 8.1的HostOS (实际上是虚拟机)，并且从docker hub拉取一个docker镜像，如busybox：

然后，执行命令：

#docker run -it busybox

果然，计算机进入了容器的平行世界。

我们发现，在docker的平行世界中，可以像HostOS的现实世界一样，用ls命令查看目录结构，还可以对文件系统进行读写操作：

我们把/bin目录下的find(实际上是一个可执行文件)拷贝到/var目录，

然后在/var目录下执行ls命令，果然，拷贝成功了。

我们在《容器网络硬核技术内幕 (17) 生命的火花》中提到过，容器的生命周期是短暂的，与虚拟机不同，容器实际上并不会迁移，而是被销毁后重新建立。那么，在容器被销毁后，容器对文件系统做的改动能够保留吗？

让我们再做一个实验。

让我们退出刚才建立的busybox容器，再重新拉起一个busybox容器：

我们发现，在/var目录下，没有了刚才我们复制过来的find文件。也就是说，在容器的平行世界中发生的事情，不是持久化的。

正如电影《送你一朵小红花》中，男主角在平行世界里，终于和女主角一起到了茶卡盐湖，但在现实世界中，男主角却不可能和平行世界中的女主角在一起。

我们希望，电影里相爱的男女主角都能最后在一起，也希望容器能够实现持久化的存储。实际上，由于在云原生的理念中，基于容器的应用应当是无状态的，容器的拉起和销毁，是容器编排平台(如Kubernetes)基于监控到的系统性能，对CPU/RAM资源进行调配的常规手段，因此，只有实现了容器的持久化存储，才能真正让大家放心地部署云原生应用，而不需要担心容器销毁以后，应用的工作状态毁于一旦。

那么，为什么基于docker的容器，对文件系统做的修改是不能持久化的呢？

请看下回分解。