k8s跟mysql集群的crd_有了这款商业分布式块存储，K8s 上跑数据库也不用担心了

原标题：有了这款商业分布式块存储，K8s 上跑数据库也不用担心了

毋庸置疑，容器与容器编排已经成为目前 IT 人员最为关注的技术之一并得到快速的普及。根据 Gartner 的调查(1)，截止到 2022 年，仅有 10% 的 CIO 对容器使用没有任何的计划，而 27% 的 CIO 已经计划将容器应用与生产环境。

Gartner IOCS 2018 Conference polling results

最初的容器主要应用于无状态应用，并不需要持久化的存储，但随着容器被原来越多的采用，以及其配合 Kubernetes 带来的强大的自动化管理能力，MongoDB、MySQL 和 PostgreSQL 等有状态应用被越来多的运行于容器之上，对持久化存储提出更多需求和更高的要求。

SmartX 分布式块存储(内部代号：SMTX ZBS)由 SmartX 自主开发，作为 SmartX 超融合的核心引擎，ZBS 已经被大量应用于金融、制造业、通信、地产等行业的私有云建设、虚拟化整合等场景，承载用户生产以及开发业务。其稳定性、易用性和丰富的存储特性已经经过长时间检验，并获得大量行业头部认可。

日前，SMTX ZBS 的 CSI 驱动已正式加入到 K8s 官方的驱动列表，企业客户不仅可以继续使用 SMTX ZBS 构建私有云和超融合系统，亦可使用其为 K8s 提供持久化存储，支持数据库等有状态应用，进一步加速 K8s 在企业内部更多场景落地。

Kubernetes 官网截图

以下部分概述了 CSI 的机制以及 SMTX ZBS 与 CSI 的接口实现。

1.K8s 的持久化存储支持

在支持持久化存储方面，K8s 提供了内嵌原生 Driver 的方式连接外部的常见存储系统例如 NFS、iSCSI、CephFS、RBD 等来满足不同业务的需求。但由于存储生态本身也在不断演进，使用 K8s 内嵌的方式来支持不断变化的存储系统在成本和时效上都会对 K8s 项目自身带来巨大的挑战。

所以和其他服务管理系统一样，K8s 逐渐的将存储系统的具体实现从主项目中分离出来，通过定义接口的方式允许第三方厂商自行接入存储服务。在这个道路上也经历了两个阶段：

(1) Flex Volume, 自 1.2 版本引入。

第三方存储服务提供商直接在 K8s Server 上部署符合 Flex Volume 规范的 Driver，利用 K8s 暴露出的 mount/unmount/attach/detach 等关键 API 实现存储系统的接入。这个模式主要的问题是，在这个形态下第三方厂商的 Driver 有权限接入物理节点的根文件系统，这会带来安全上的隐患。

(2) Container Storage Interface (CSI), 自 1.9 版本引入，目前已经进入 GA 阶段(1.13)。

CSI 定义了容器场景所需要的存储控制原语和完整的控制流程，并且在 K8s 的 CSI 实现中，所有的第三方 Driver 和 K8s 的其他服务扩展一样，以服务容器的形态的运行，不会直接影响到 K8s 的核心系统稳定性。

2.存储对象

CSI 定义的存储对象为持久化卷，称之为 Volume。包括两种类型：

Mounted File Volume，Node 将会把 Volume 以指定的文件格式 Mount 到 Container 上，从 Container 的角度看到的是一个目录；

Raw Block Volume, 直接将 Volume 以 Block Device(磁盘)的形态暴露给 Container，对于某些可以直接操作磁盘的服务，这个形态可以省去文件系统的开销获得更好的性能。

Raw Block Volume 目前还处于 Beta 阶段，所以下文的过程描述和 SMTX 的 CSI Driver 目前的实现方式均针对 Mounted File Volume。

3.Plugi