容器原生存储 (CNS) 提供了一种在Kubernetes集群上集成持久存储的方式。那么随着供应商打响收购战，结构化数据库越来越多地使用Kubernetes，容器原生存储下一步会怎么走？
背景
随着Docker的普及，对Kubernetes的采用，容器化技术发展速度飞快。如今想要持久化应用能在Kubernetes集群中无缝运行就意味着要提供弹性存储。
但持久存储映射到容器化应用的方式可能会出现问题。单个容器应用可以在多个节点中的其中一个上启动（或重新启动），物理存储从本地NVMe盘、共享存储或网络存储上提供。如果一个容器想移动位置（到另一个节点），那么到现有NVMe存储的映射就会丢失。
共享存储可能会hold住这种变化（虽然设备映射过程是挑战），网络存储虽然能提供更好的灵活性但会降低性能。
映射问题的一个解决方案是前几年就已经停产的开源软件容器管理器Flocker，已被容器存储接口 (CSI) 取代。
容器原生存储（CNS）
容器原生存储和超融合存储部署有很多相似之处，容器原生存储跨Kubernetes集群的节点部署横向扩展存储解决方案。CNS层提供数据弹性（通过复制）、应用性能（通过启用节点本地存储）以及如快照和克隆等数据管理功能。
大多数CNS的实现都采用类似架构，在每个节点上运行容器进程，通常通过CSI向应用开放存储资源和可使用的API。
容器原生存储可以解决许多数据持久化问题。物理存储从应用中抽象到了存储类，这些类定义了性能和弹性等特性。如果物理基础设备发生变化，存储类对应用保持不变。应用如果需要一组不同的特性，只需采用另一个存储类即可。（PS：存储类的概念居然是1989年为IBM大型机系统管理存储发明的）
随着新节点添加到集群，CNS可以快速扩展。 与添加使用共享存储（例如 SAN）的新节点相比，过程可能要数秒或数分钟，后者可能需要数分钟或数小时才能完成配置。
未来预测
数据移动性。这个领域正在改进，未来会看到更多功能，不用重复创建整个复制集群，让再利用已存在快照中的数据成为可能。提出这个要求的部分原因是为了在公有云上部署CNS。
云采用率增加。随着虚拟实例持续提供本地存储（NVMe设备）选项（通过提供本地存储，虚拟实例可以提供比网络存储更快的数据访问速度和更低延迟），我们会看到CNS解决方案会在公有云上得到进一步采用。 这些实现需要“云感知”并能够有效地使用云存储。
可观察性。希望看到CNS中引入更多的可观察性功能。随着Kubernetes在持久数据应用中的使用增长，部署变得越来越复杂，因此需要详细检查的能力。集群优化解决方案（如 StormForge）需要与CNS等集群中的基础设施应用协同工作。
集成。CNS和传统存储之间的集成。 SAN在数据中心里历史悠久，不太可能很快被取代。而CNS 解决方案和共享存储可以更有效地协同工作，或许可以卸载设备层已有功能，如加密和数据重删。CNS 解决方案应该能按需扩展物理存储，包括公有云。已知Portworx已经为 Pure Storage的FlashArray提供了这个特性。
最后
容器原生存储会继续存储并在未来几年里转变为物理存储（包括设备）的抽象层。 Pure Storage收购Portworx，DataCore收购MayaData都明确了这个意图。
另一种观点是，基于块的 CNS 市场还会存在几年，但最终会被文件或对象存储的连通性所取代，目前有待观察。
原文整理自：https://www.architecting.it/blog/predictions-2023-cns/
