本文来自微信公众号“twt企业IT社区（talkwithtrend.com）”，【作者】刘东，系统架构师。
导读
以容器为代表的开源技术体系，对存储设备提出了新的要求，需要新的数据存储方案，确保可以为容器提供满足多种不同需求的存储解决方案，本文详细分析了容器云环境给存储需求带来的新变化。
【作者】刘东 系统架构师
一、容器云开源生态存储发展所面临问题和挑战
在采用容器技术体系部署应用时，一个宿主机通常会承载上千个容器，存储需求呈现出数据量大、读写速度快、数据安全性高等特点。为了满足容器环境下数据快速读写和数据共享的需求，需要实现存储与容器的深度集成。
容器的特点就是灵活和轻量化，应用部署和扩缩容是动态的，存储系统需要支持动态资源调度，以满足不同容器的存储需求。容器存储需要同时支持持久化数据存储和非持久化数据存储应用。
对于Kubernetes而言，非持久化数据存储的数据在容器进行迁移并重新创建实例时，数据会消失。而持久化数据存储，就必须有一种方法保证在容器迁移或重启之后继续保存变化的数据，需要一个一致性的存储卷机制，多个容器可能需要共享同一份数据，或者可以实现容器迁移后的数据连续存储，保持存储系统数据的一致性。
二、容器云环境下对存储需求带来的新变化
容器云环境下，一个Kubernetes由Master节点和Node节点组成，一个Node节点可以有多个Pod，其中Pod为最小容器单元。一个Pod是由镜像创建而来的运行实例，每个Pod都有自己的存储空间，储存空间的使用和分配取决于配置和运行环境，可以是一个文件夹，也可以是一个文件。这样的运行环境在处理无状态应用时没有问题，但是在处理有状态应用（例如MySQL）的时候就需要存储具备持久化的能力，采用数据卷的机制来进行更高级的数据管理。数据卷是一个可供一个或多个容器进行读写访问的特殊目录，它绕过了容器的存储路径，使得数据可以在容器之间共享和保持持久化。
在创建一个存储卷时，需要进行申请对应的存储空间，即PVC（Persistent Volume Claim）。通过PVC请求存储卷的PV资源（Persistent Volume）。PVC和PV是抽象的存储资源，可以使应用程序及其开发人员能够避免处理底层存储申请、访问和使用的细节。
PVC是容器用户对存储的请求，当创建一个Pod的PVC时，可以通过手动方式静态创建应用所需要的PV存储资源，也可以创建动态的PV资源，不过需要存储设备接口程序的支持，否则只能手动创建PV资源。
通常情况下，容器在运行时应用产生的数据可以都存储在容器内部的PVC上，当容器创建了一个非持久化应用，例如Tomcat，当这个容器的实例被关闭时，数据也会一起消失。但是如果创建的是一个持久化应用，例如MySQL，那么就需要将数据读写状态保存下来，即使发生了容器重启、迁移等操作，仍然可以访问并读写原来的数据，需要采用数据卷的方式进行数据的存储和访问。由于数据卷绕过了容器的存储路径，这就涉及到了一个外部数据存储问题。根据以上的容器存储需求，目前可采用的数据存储方案主要包括服务器本地盘、集中存储设备和分布式存储设备三种。
图1容器云存储架构图
1.服务器本地盘
直接使用容器宿主机的本地磁盘作为容器存储资源，可以提供灵活的容器存储使用方案。而且在使用基于PCI-E接口的NVMe SSD磁盘时，由于读写性能高，还可以提供不错的性能。在安全性方面，由于大部分服务器都可以组建RAID，也可以提供一定的安全保障，在采用RAID1/5/6等带有冗余的RAID级别时，可以避免数据丢失，特别适合单一宿主机容器运行的场景和测试场景。
缺点是无法提供高可用场景，由于存储的数据不能在多个宿主机服务器之间保持一致，当单台宿主机故障时，数据将有可能全部丢失，没有冗余保护。而且对于持久化的数据存储，单个容器节点只能运行在本机的宿主机节点上，无法迁移到其他宿主机，因为其他宿主机没有可同步的且具有数据一致性的数据，无法处理持久化的有状态应用跨主机部署。
2.集中式存储
传统的集中式存储在接入Kubernetes时，主要有两种接入方案，分别为无CSI存储插件和有CSI存储插件。CSI（Container Storage Interface）是一种开放的存储插件标准，用于将存储系统与容器编排平台（如Kubernetes）解耦，为容器提供灵活的存储选项。CSI的设计目标是为不同的存储提供商提供统一的接口，使它们可以轻松地集成到容器编排平台中。
如果无CSI插件，接入后和本地磁盘情况类似，以块设备或NAS设备接入到容器环境中，提供共享访问能力，对比本地存储方案，可以解决高可用场景的问题，可以提供持久化存储所需的共享存储空间，可以满足基础的容器数据共享存储需求。但是对于容器化存储的根本需求问题还是无法解决，不支持动态卷的创建、删除和扩容，无法对存储卷进行生命周期管理，无法适应容器的灵活和敏捷性要求。
如果有CSI插件，那么就可以通过CSI插件将集中式存储的能力集成到容器云平台，提供存储服务能力，获得容器存储的特性。存储的CSI插件将以一个类似Driver的形式部署在容器云平台上，然后通过CSI调用集中存储资源。例如需要创建一个持久化数据卷（PV），那么容器将通过CSI在集中式存储上创建一个LUN，并且不需要手动去管理和操作。
详见图2：
图2集中式存储对接容器架构图
举例说明：在有了CSI存储插件，并向容器云平台申请PVC存储空间时，可以提前划分一个10TB的空间给Kubernetes使用。在一个容器需要PV时，会通过CSI发送请求并自动创建一个满足要求的PV，然后将PV提供给申请的PVC作为挂载使用即可，不需要手动创建或指定一个PV给PVC使用。
3.分布式存储
分布式存储在接入Kubernetes时，接入方案和集中式存储类似，同样可以分为无CSI存储插件和有CSI存储插件。
目前大部分的分布式存储产品都是基于开源技术而来，即使无CSI插件，也可以原生支持Kubernetes。例如采用基于开源Ceph技术的分布式存储产品，因为Ceph本身就是云原生技术体系，与Kubernetes具备先天集成能力，同时也具备自动化存储资源管理和运维能力，可以直接通过Ceph技术对分布式存储资源进行管理。同样还有基于对象存储的分布式产品，包括支持Amazon S3、Google Cloud Storage和OpenStack Swift协议的对象存储产品。对象存储的产生就是简单、低成本的存取和管理大量的非结构化数据，部署和管理使用都比较简单，易于横向扩展，天然支持云原生。容器通过对象存储协议即可访问对象存储，无需挂载。
当然，也有部分采用自研技术路线的分布式存储产品，本身并不具备开源产品那样的原生接入能力，通过编写标准的CSI存储插件驱动，以CSI标准的方式与Kubernetes进行对接，和传统的集中式存储的接入方案一样。
主要的技术对比能力如表1所示。
表1分布式存储技术路线对比
三、对传统存储拥抱生态方面的期望
传统存储在拥抱以容器为代表的开源技术体系时，期望可以结合自身的产品定位，提供更加优化的存储产品接入解决方案。例如在集中式SAN存储或者NAS存储方面，提供效率更高，适配性更好，并通过CNCF认证的“云原生存储”插件或产品，可以更好的为容器云平台提供存储服务。在分布式存储产品方面，除了可以提供采用不同开源技术路线的分布式存储产品，满足不同的市场需求之外，在企业级产品线上，更期望能推出具有自主知识产权并具有一定创新技术的自研分布式存储产品。在保证与开源Kubernetes的适配和兼容性基础上，提供更好的产品性能、稳定性和技术服务，可以规避采用开源技术产品带来的安全漏洞和技术风险，也可以帮助用户获得专业的技术服务支持。
四、结语
以开源为中心的云原生技术体系给存储领域带来了新的挑战和机遇。以容器为代表的开源技术体系已经逐渐成为IT的主要发展趋势之一。在这样的大环境下，传统存储厂商需结合自身产品特点与市场需求需要不断调整发展策略，积极拥抱开源生态，实现技术的转型升级，应对未来的挑战。
可以预见，在未来的开源技术体系发展过程中，容器生态将更加成熟，存储也必将更加灵活和高效，为IT行业和云原生领域带来更多的创新和机遇。存储厂商需要和开源项目共同努力共同推动容器存储技术的发展，解决如技术标准、数据安全、自动化管理和高性能可扩展等新需求。通过开源技术体系和生态的不断发展完善，开源技术体系和存储技术的融合将更加紧密，为各大行业的数字化转型提供有力支持。
