在云原生技术蓬勃发展的当下，容器编排系统 Kubernetes 无疑是其中的中流砥柱。自 2014 年 6 月 6 日，Kubernetes 的第一次提交被推送到 GitHub，历经十年的飞速演进，它早已超越了单纯编排系统的范畴。如今，Kubernetes 提供了一种规范，让用户能够精准描述集群架构，定义服务的最终状态，并能自动将系统达成并维持在该状态。

而 CSI（Container Storage Interface）作为 Kubernetes 上建立的行业标准接口规范，使存储系统能为容器应用提供数据持久化能力，极大地推动了云原生存储的发展。

云原生存储的痛点与挑战

XSKY 作为软件定义存储的代表性厂商，紧密跟随云原生生态的步伐。早在 CSI 标准发布前，就已深度适配 Kubernetes in-tree 架构，提供分布式块、文件存储服务。2018 年底 CSI 标准正式版本发布后，又迅速支持 CSI 标准，推出 CSI-ISCSI、CSI-NFS 协议接口，多年来助力上百家客户成功实现云原生应用转型。

在大量的交付案例中，我们也察觉到当前 CSI 在使用过程中存在一些亟待解决的痛点：

• CSI Driver 部署与运维难题：目前 CSI Driver 主要采用命令行单独安装的方式，这使得 PV 卷缺乏总容量监控以及性能监控管理，给运维工作带来诸多不便。

• 多存储环境管理复杂：在实际项目中，一套 K8s 平台可能对接多套不同性能的存储，或者一套存储要对接多套 K8s 集群。这种情况下，需要为每套 K8s 进行集群管理，实现对 PV 卷容量、配额等的统一限制，否则资源分配比较随机，无法有效管理每套 K8s 使用容量，管理难度较大。

• 块存储 Pod 异常切换困境：云原生应用数据持久化主要依赖块和文件存储。文件存储天然支持多节点共享，当云原生节点出现异常时，应用能迅速自动切换到可用节点。但当使用块存储承载数据库、中间件等应用时，一般采用 RWO 模式挂载。此时若节点异常，Kubernetes 需要 6 分钟才能自动强制切换，而且切换后应用仍无法运行，因为后端存储未能正确释放块存储对应异常节点的映射，导致业务长时间受影响，难以满足业务要求的 SLA 标准。

XCNSP 重磅登场，开启云原生存储新篇章

为了攻克这些难题，满足云原生新需求，XSKY 发布了 XCNSP（XSKY 云原生存储平台），这是一款基于原有 CSI Driver 进行重大升级的存储管理平台，为云原生存储带来了全新的解决方案。

01  主要功能亮点

Pod 高可用

这一功能彻底解决了块存储挂载到 Pod 后，Pod 所在节点关机等异常情况下的自动切换问题。在 1 分钟内，Pod 即可自动切换到其他可用节点，确保业务正常访问。

• 高可用检查条件：在 K8s 节点部署 XKSY 高可用插件，同时为需要保护的 Pod 添加特定标签 “csi.xsky.com/Podha: "enable"”，并且高可用插件会对节点和 Pod 进行全面且详细的健康检查；

• 高可用操作：高可用插件一旦通过健康检查发现异常，触发条件后会立即删除异常节点受保护的 Pod，促使 Pod 快速漂移；随后删除该节点高可用 Pod 卷的 VolumeAttachment 记录，取消卷与异常节点的挂载信息，让业务能在 1 分钟内顺利切换到可用节点并恢复运行；

• 事后处理：当异常节点恢复后，系统会自动清理残余卷，保证系统的整洁与稳定。

统一平台，可视化运维管理

XCNSP 提供了直观的可视化统一管理界面，全面支持星飞全闪（CSI-iSCSI、CSI-NVMEof）和 SDS 混闪（CSI-iSCSI 、CSI-NFSv3/v4）。同时，能够对所有 PV 卷进行精准的容量、性能监控，让运维管理更加高效便捷。

多租户配额管理

针对每种类型的存储，XCNSP 允许创建一个或多个项目，用于对全局容量、卷个数、快照个数进行灵活限制，满足不同租户的多样化需求。

支持单 PV 310 万 IOPS

XCNSP 专注于存储管理的深度集成，在 IO 路径上未做任何改动，能够充分发挥存储本身的性能优势。它支持最新的星飞全闪块存储，可以使用 NVMe-oF 提供单卷高达 310 万 IOPS 的超高性能，足以满足云原生上所有应用的严苛性能需求。

Pod 高可用测试对比与实际效果

我们创建有 3 台节点的 k8s 集群，节点名是 k8s-test、k8s-test-2、k8s-test-3。

01  模拟节点故障

以下是模拟挂载块存储卷的 Pod 所在节点关机，看 XSKY Pod HA 插件如何自动恢复业务 Pod。

• 我们首先创建一个 StatefulSet 类型 nginx 应用，不设置高可用 label；

• 然后让 k8s-test-2 节点停机，在将近 10 分钟后，此应用一直处于 Terminating 状态，无法自动恢复；

• 接下来我们重新创建一个 StatefulSet 类型 nginx 应用，并添加上高可用 label；

• 创建完应用后，我们停止 k8s-test-2 节点，可以看到在 2 分 54 秒前检测到 k8s-test-2 节点离线，2 分 19 秒前新 Pod 在 k8s-test 节点创建，也就是 1 分钟内新 Pod 被启动起来。

02  模拟存储网络故障

• 首先，创建一个 StatefulSet 类型的应用（Postgresql 数据库），并为该 StatefulSet 的 Pod 开启 Pod 高可用；

• 然后，我们新建一个容器应用，让应用每隔一秒往 Postgresql 数据库的 items 表中插入一条记录；

• 最后，我们断开 k8s-test-3 节点与后端存储的网络，观察到 Postgresql 数据库 Pod 在 k8s-test-2 节点重建，查看 items 表记录，可以看到记录插入动作停止了 36 秒后恢复。

可以看到，使用 XSKY 高可用方案后，Pod 可以及时自动恢复，极大解决故障场景下的 Pod 高可用问题。产品支持节点故障、网络故障、卷 IO error、Pod 状态异常（CPU、内存、系统盘不足等引起）等异常场景切换。

典型案例

在某新能源汽车企业云资源池建设项目中，采用前沿的数据库容器云 + XSKY 星飞分布式全闪块存储 + CNSP 创新方案，替代传统烟囱式的数据库物理机 + 集中式全闪存储模式。用 24 个容器云计算节点，成功承载集团及子公司各类业务中广泛应用的 MySQL 等新型数据库。这一方案不仅保障了数据库的性能和可靠性，还极大降低了硬件投入成本，大幅简化管理复杂度。

总结

XCNSP 为云原生应用提供全闪块、混闪块、混闪文件全产品支持，适用云原生应用不同需求。全闪块更是达到单卷 310 万 IOPS，帮助高性能应用的云原生改造。同时使用 XCNSP 平台，也创新性解决了云原生节点异常，挂载块卷的 Pod 业务无法快速自动恢复问题，让云原生应用更好的运行。

当前 XCNSP 产品已经在多个客户项目上落地，包括金融、能源、先进制造行业，我们也将持续投入，更加完善 XCNSP 从云原生到存储的管理能力。