为云原生插上翅膀，天翼云弹性存储CStor-CSI助力容器腾飞

云原生是一种新型技术体系，已成为云计算未来的发展方向，越来越多的数字化项目与云原生紧密相连。作为云原生的基座，容器是必不可少的核心技术。然而，以Docker为代表的容器引擎，并不能满足大批量的容器业务需求，相应的管理和联动也是难题。Kubernetes（K8S）的出现，解决了容器编排层面的问题。

为了给K8S容器提供数据存储，保证数据的可用性和可靠性，K8S设定了各种方式、机制、规范，以帮助用户更好地存储数据。

传统的方式包含Hostpath、LocalPV、动态provisioner等，这些方式虽支持在K8S容器上使用容器存储，但或多或少存在一些问题，相关问题对比如下：为云原生插上翅膀，天翼云弹性存储CStor-CSI助力容器腾飞而市场对于K8S的使用需求主要包含以下几点： ① 是否能够保证容器在漂移后，还能复用原有的存储数据？ ② 能否随着社区的发展增加新的特性？ ③ 是否支持远端存储？ ④ 是否可以在使用的时候才申请，不用的时候销毁？ ⑤ 是否支持拓扑调度？ ⑥ 是否可以自行定义挂载个性化的方式方法？ ⑦ 是否为社区主推方式？由此可见，上述三种容器存储手段，无法完全满足市场需求。那么，还有更好的存储手段吗？CSI给出了答案。

CSI是什么，为什么选择CStor-CSI?

CSI即容器存储接口（Container Storage Interface）, 其构建旨在为容器编排引擎CO（Container Orchestrator System）和存储供应商SP（Storage Provider）之间搭建一套标准的存储调用接口，从而定义行业标准，使存储供应商SP能够开发一个符合CSI标准的插件并使其可以在多个容器编排CO系统中工作。也就是说，CSI是一套接口，它约定的标准，让所有符合CSI接口的插件在多个容器编排中都可以工作。

形象地说，CSI就是容器和存储之间的翻译官，并以存储代理人的身份，满足容器关于存储的一切要求。而各类容器编排系统（如K8S），则是这一切标准的制定者，满足CSI规范的组件都可以接入进来，成为容器和存储之间的桥梁，这些组件被称为CSI插件。

CSI一般包含三种服务：Controller Service - 提供控制面的相关功能，Node Service - 提供节点层面的服务，以及Identity Service - 提供身份认证服务。

在Controller Service和Node Service上均会提供Identity Service，所以CSI直接对外呈现的服务实体，只有Controller Service和Node Service。

为方便用户更好地使用天翼云存储，丰富天翼云容器特性，天翼云推出了弹性存储CStor-CSI插件，让用户在使用天翼云容器的同时，无感知使用天翼云高性能后端存储。天翼云弹性存储CStor-CSI主要具备以下特性： ① 提供基于天翼云的云硬盘和弹性文件CSI业务，以及基于现有高性能本地磁盘的CSI块存储业务。 ② 支持容器漂移。 ③ 动态创建PV，用户无感知使用。 ④ 支持多可用区，完美匹配天翼云4.0架构。

比如在多AZ架构场景中，随着天翼云4.0在各大局点投入商用，新的多AZ架构也从多方面满足了用户对于可靠性的需求。其中，CStor-CSI也成功完成了与多AZ的适配。

在容器存储不支持多AZ的情况下，CStor-CSI针对AZ级别资源的使用情况如下所示：Pod的调度并不受控制，根据K8S的调度算法，将随时可以在其他AZ上运行，这样新建的Pod，是无法享受原AZ内资源的。为云原生插上翅膀，天翼云弹性存储CStor-CSI助力容器腾飞而拥有CStor-CSI的天翼云，在新一代云平台的容器存储产品中，可以在用户毫无感知的情况下，继续支持Pod在原有AZ中使用，且复用原有的存储资源。不过，如果是跨AZ使用的资源，情况如何呢？在该情况下，容器存储CStor-CSI也能够很好地支持跨AZ使用的存储资源。如图所示，不论Pod调度到哪个AZ上，天翼云都可以如影随形，为Pod提供始终如一的弹性文件服务，保证企业业务正常运行。为云原生插上翅膀，天翼云弹性存储CStor-CSI助力容器腾飞 ⑤ 后续特性扩展，持续更新支持。 ⑥ 匹配业界规范，紧跟社区更新脚步，是社区推荐的接入方式。