块存储是将裸磁盘空间通过划逻辑盘，做Raid，或者LVM（逻辑卷）等方式逻辑划分出N个逻辑的硬盘，然后采用映射的方式将这些逻辑盘挂载到主机。主机的操作系统认为这些磁盘均为物理硬盘，跟直接拿一块物理硬盘挂载到操作系统没有区别。
块存储的优点不言而喻：
需求
在IaaS中，块存储被广泛应用于为虚拟机提供持久卷。虚拟机故障后依然能够通过在其他虚拟机上挂载旧数据卷的方式来访问磁盘数据，因此被普遍认可。受此影响，一些客户在设计PaaS时，自然而然的联想到共享存储的这一优势，提出在PaaS中为容器挂载块存储的需求。
但是，凭借在IaaS中的卓越表现，块存储也能够跻身PaaS业务中吗？
分析
假设已有一套可提供RBD块存储的Ceph集群的前提下，我们先来分析几个场景：
场景一
“我使用容器技术，但还不是深度用户，只使用docker run之类的命令来手工启动单个容器，这些容器中运行的服务都比较消耗磁盘空间。”这类用户局限于将容器作为一个临时工具，并没有将其与业务紧密结合。
块存储驱动框架图如下所示：
场景二
“我使用容器编排工具来管理应用，比如docker-compose、Rancher或Kubernetes.但我在每一个service下只需要启用一个container，且对service没有扩容的需求；这些service都比较消耗磁盘，我希望在容器被重启或重新调度后，仍可使用旧的数据盘。”
该场景比较特殊，每一个service只对应一个container.因此，不会有多个container同时读写一块数据盘的需求，只需保障container之前所挂载的存储卷在container故障恢复或正常迁移后依然能够被container访问即可；即存储卷对容器的自动跟随。
迁移场景如下图所示：
但是，值得注意的是：
场景三
我使用Rancher或者Kubernetes之类的容器编排软件来管理应用，每一个应用有多个微服务；每一个微服务又对应多个容器来并行对外提供服务。
Rancher
在Rancher里面，应用被称之为Stack，每一个stack包含一到多个service； service即微服务，微服务之间按照单一职责划分，只做一件事情。service属于逻辑的概念，真正做事的是各service对应的containers.如果希望通过为service扩容，就增加service对应的container数量；这些container无状态，可被调度到多台宿主机上，它们必须使用共享存储来保障业务的持续性。
Kubernetes
在Kubernetes中，业务也是由一到多个service来共同完成的，这里的service与Rancher中service的概览类似。Kubernetes的service是一个外部访问点（endpoint），通过selector指定labels的方式可以选定一组pods，service为这组pods提供访问代理和负载均衡。外部的客户端只需知道service所暴露的端口和IP就能够访问到业务。由于pod是无状态的，因此同Rancher一样，也需要将业务数据存储到共享存储上，还必须保障同一个service对应的多个pods均能共享该业务数据。
限于块存储只能同时被一个客户端（主机）所挂载，当service的多个containers或pods调度到多台主机上时，块存储就难以应付了。此时，原始共享文件系统的方法又体现出了它的优势，NAS会是一个最好的选择！
以上就是关于“探讨容器中如何使用块存储”的相关介绍，筋斗云是国内较早的云主机应用的服务商，拥有10余年行业经验，提供丰富的云服务器、租用服务器等相关产品服务。云服务器资源弹性伸缩，主机vCPU、内存性能强悍、超高I/O速度、故障秒级恢复；电子化备案，提交快速，专业团队7×24小时服务支持！
简单好用、高性价比云服务器租用链接：https://www.jindouyun.cn/product/cvm