随着云原生时代的到来,越来越多的企业开始采用 Kubernetes(K8s)加速现代应用的开发和部署过程。为了适应容器环境敏捷、可移植等特点,存储作为 IT 基础设施的核心组件,也需要进行云化转型,以满足现代化应用在数据持久化和高效运行方面的需求。目前,用户在挑选容器存储时,经常会听到“K8s 持久化存储”、“云原生存储”、“容器原生存储”、“K8s 原生存储”等不同的方案类型。这些存储方案有什么区别?本文中,我们将深入探讨这四个概念,帮助读者更好地理解、选择合适的容器存储方案。
什么是 K8s 持久化存储
首先需要明确的是,相较于作为一种存储方案类型,“K8s 持久化存储”更常被用作为一种概念,与 K8s 上随 Pod 销毁或移动而无法持久化保存数据的存储卷(Volume)相区分。
K8s 支持很多类型的卷,包括持久卷(PersistentVolume)和临时卷(EphemeralVolume)。临时卷的生命周期与 Pod 一致,如 emptyDir,其存储的数据会随着 Pod 的销毁而消失,仅可用作临时存储空间。而持久卷的生命周期比 Pod 长,即使 Pod 销毁也可保留下来。值得注意的是,HostPath 虽然也是一种持久卷,但若 Pod 漂移到其他 Node 或当前 Node 故障,也无法保证数据持久化,因此有时被称为“半持久化存储”。
综上所述,“K8s 持久化存储”是指 K8s 在管理 Pod 数据时使用的一组抽象概念和资源。这些概念包括 PersistentVolume(PV)、PersistentVolumeClaim(PVC)和 StorageClass。它们为 K8s 中的应用程序提供了一种持久存储数据的方法。而云原生存储、K8s 原生存储等则是实现 “K8s 持久化存储”的具体技术、产品、方案。也就是说,所有支持 K8s 环境中的应用数据持久化存储的方案,都是“K8s 持久化存储”,包括文中提到的云原生存储、容器原生存储和 K8s 原生存储。
什么是云原生存储
云原生存储(Cloud Native Storage)是一种基于云原生架构理念设计的存储方案,云原生计算基金会(CNCF)对此这样形容:
云原生存储是针对新的云原生环境而量身定制的:传统存储硬件与基础设施紧密绑定,不同数据中心也可能使用不同的存储接口,存储置备也难以自动操作;而云原生架构极具流动性、灵活性和弹性,容器化应用程序会不断地创建和删除,容器运行的物理位置也会发生变化,这些变化都对存储方案提出了新的要求:
- 为容器提供云原生存储选项;
- 将容器和存储提供商之间的接口标准化;
- 通过备份和恢复操作提供数据保护。
这意味着云原生存储需要使用云原生兼容的容器存储接口,并且可以自动进行置备,消除人为操作瓶颈,实现自动缩放和自我修复。在 K8s 环境下,云原生存储使用提供标准 API 的容器存储接口(CSI)提供存储服务。
CNCF 认证的云原生存储包括开源的和商用的存储产品(见下图)。
由此可见,“云原生存储”是一个广泛的范畴,重点强调存储方案对云原生环境和接口标准化的支持特性,而并不区分存储类型、存储架构、部署环境、支持的应用负载等。例如,用户可以选择基于分布式块存储的商用闭源存储方案,支持 I/O 密集的应用场景,也可以采用公有云或开源的分布式文件存储产品,支持大数据量的文件存储场景。
因此,当面对一个“云原生存储”产品时,用户需要首先了解该存储方案支持的存储类型、存储接入方式、存储协议、兼容的容器运行时、对 CSI 的支持程度、支持的 K8s 资源类型(如 PersistentVolume、StorageClass 等)以及适用的应用场景。
另外,虽然云原生存储为 K8s 提供数据持久化保存,但不是所有的 K8s 持久化存储都是云原生存储,因为传统的存储解决方案也可以被用于 K8s。例如,用户依旧可以将本地磁盘作为“K8s 持久卷”,但这种方式并不能算作云原生存储产品或方案。
什么是容器原生存储和 K8s 原生存储
一些云原生厂商也将它们的存储方案精确细分为“容器原生存储(Container Native Storage)”类别。根据 Gartner 的报告《2022 Strategic Roadmap for Storage》,“容器原生存储是专门为支持容器工作负载而设计的,重点解决云原生环境下独特的规模、粒度和性能需求,同时与 K8s 容器管理系统深度集成。”这些方案与云原生存储方案的主要区别在于,容器原生存储与 K8s 的集成程度更深,能够更好地支持在 K8s 运行的工作负载。而且,由于 K8s 已经成为云原生时代既定的容器编排工具,整个容器应用生态均以 K8s 为标准,因此“容器原生存储”与“K8s 原生存储”并没有本质上的区别。
K8s 具备跨环境的一致性特性,它能够支持应用在不同云环境中实现自动弹性扩缩容、滚动更新和自我修复。同时,K8s API 为应用部署和管理的标准化与自动化提供了坚实基础。因此,与核心业务紧密关联的有状态应用,如 MySQL、PostgreSQL、Cassandra 和 RabbitMQ 等,越来越多地运行在 K8s 环境中,期望其获得与 K8s 同样的弹性、标准化和自动化能力。这些数据库和消息中间件类应用在数据可靠性和性能方面,对 K8s 持久化存储方案提出了更高的要求,推动了由云原生存储向容器/K8s 原生存储的需求转变。
容器/K8s 原生存储方案通常具备以下特性:
- 基于分布式、软件定义的统一存储池。
- 具有容器级别的数据服务粒度。
- 具备自动化存储资源运维能力。
- API 驱动。
- 与 K8s 紧密集成(如支持与 K8s 工具链集成)。
- 可支持多种部署形式(如本地、边缘)。
- 多种集成的高级数据服务(如容灾备份、加密、数据缩减)。
由此可见,容器/K8s 原生存储包含在云原生存储的范畴,但不是所有的云原生存储都可以被称为容器/K8s 原生存储。
基于此,我们可以将 K8s 持久化存储、云原生存储、容器原生存储和 K8s 原生存储之间的关系,以下图呈现:
在选择容器存储时,用户应结合容器承载的应用需求和自身的建设条件,选择合适的存储方案。尤其是对于 K8s 集群上的数据库类、消息中间件类应用,应优先考虑采用性能更高、稳定性更强的容器/K8s 原生存储方案(基于分布式块存储)。
为了充分满足现代化应用的存储需求,SmartX 将在近期发布 K8s 原生存储新品,敬请期待!
参考文章:
1. Cloud Native Storage,CNCFhttps://landscape.cncf.io/guide#runtime–cloud-native-storage
2. CNCF Cloud Native Landscape
https://landscape.cncf.io/
3. 2022 Strategic Roadmap for Storage,Gartnerhttps://www.gartner.com/document/4012543
4. Cloud Native Storage – Webinar,CNCFhttps://www.cncf.io/wp-content/uploads/2020/08/CNCF-Storage-Final-1.pdf
推荐阅读
- SmartX 发布 K8s 云原生存储 IOMesh,加速有状态应用容器化进程
- SmartX 发布 SKS 1.0,一站式构建生产级 K8s 集群
- 如何部署运维 K8s?我们整理了 3 份 Gartner 报告,得到这些建议
- 选型 K8s 管理平台需关注哪些核心能力?【附 Gartner 选型建议】
- 接管 K8s 部署运维,基础架构团队是否做好准备?丨SmartX 趋势分享
- 如何利用 knest 构建数据中心的 Kubernetes as a Service?
- K8s 多租户现有实现机制分析与优化
- Virtink:更轻量的 Kubernetes 原生虚拟化管理引擎
- 云原生时代需要什么样的存储系统