在上期，我们提到，容器受到namespace, rootfs和cgroups这些无形的墙的约束，在运行时对文件系统写入的任何数据都不能持久化存储。
但是，在云原生应用中，有一些组件是有数据持久化存储的要求的。
让我们回到开篇的问题：
X博期望用kubeflow构建深度学习平台，训练一个神经网络模型，自动识别所有的江疏影和方方：
那么，kubeflow的容器实例就需要将训练的模型持久化存储，否则，X博的工作即使找到了抓手，拉通了周边资源，对焦了项目目标，抽离了底层逻辑，提炼了打法，应用了组合拳，但由于缺乏沉淀，没有闭环，因此没有任何价值。X博将面临绩效3.25甚至3.0的严重危机。
怎么样能让X博及其领导下的kubeflow的工作能够有效沉淀，最终形成闭环，救X博于361考核的水火之中呢？
X博找到了方老师。虽然是来自友商的求助，本着知识共享的精神，方老师还是为X博进行了详解——
我们在docker中创建容器的时候，实际上是可以手工为这个容器添加持久化挂载的存储的，如在docker run命令中，加入参数 -v。
让我们做一个实验：
我们将用户切换到root，并在/root目录下建立一个目录 tmp
我们在root用户下运行容器ubuntu，用这个命令：
docker run -it -u root -v ~/tmp:/mnt/tmp ubuntu
这条命令的作用是：
docker run #容器运行
-it #交互模式
-u root #指定使用root用户
-v ~/tmp:/mnt/tmp # 将hostos的~/tmp/目录挂载到容器上的/mnt/tmp/目录
ubuntu # ubuntu容器
我们再去hostos的/root/tmp/目录下看看：
宿主机上有了目录test0。
我们再到容器ubuntu中执行下面的操作：
我们利用cp /dev/stdin abc 命令，(将stdin标准输入拷贝到文件abc)，建立一个文件abc，其内容是键盘输入内容(stdin标准输入)。
我们在容器ubuntu中看一下abc文件的内容，和我们输入的一致：
我们再去hostos看一看：
果然，文件内容和容器侧写入的是一致的。
我们退出容器ubuntu再验证，文件依然存在。这说明，我们通过给容器挂载本地持久化目录，已经突破了容器的次元壁，让容器能够读写外部的持久化存储！
如图，HostOS上的/root/tmp/目录，被映射到容器ubuntu中的/mnt/tmp目录，成为了容器通过hostpash方式挂载的持久化存储。
如果我们有一台nfs服务器，也可以利用容器启动时的命令，加上-v参数，将外部nfs目录挂载为容器的持久化卷。
这样一来，X博只需要在启动kubeflow容器的时候加上这个参数就行了。
但是，在云原生的世界里，有这样一条铁律：
任何需要手工做的事情，都不满足云原生的自动化原则。
我们需要的是，让容器可以自动化地挂载外部持久化共享卷。也就是说，让kubernetes在批量拉起容器时，能够自动化地让容器挂载持久化卷，无论是块存储还是文件存储。
我们怎么样实现这一目标呢？
请看下回分解。
