Kubernetes 持久化存储方案选择——从入门到评估

Kubernetes持久化存储方案选择 从入门到评估 概念入门 随着云原生时代的到来，越来越多的企业开始采用Kubernetes（简称K8s）加速现代应用的开发和部署过程。为了适应容器环境敏捷、可移植等特点，存储作为IT基础设施的核心组件，也需要进行云化转型，以满足现代化应用在数据持久化和高效运行方面的需求。 目前，用户在挑选容器存储时，经常会听到“Kubernetes持久化存储”、“云原生存储”、“容器原生存储”、“Kubernetes原生存储”等不同的方案类型。这些概念都有什么区别？ 同时，在挑选Kubernetes持久化存储方案时，用户也经常面临本地磁盘、CSI外接商用存储、Kubernetes原生存储3种不同形式的选择，以及多个不同存储产品的对比。不同的存储方案应该怎么选？不同存储产品各自的优劣势又有哪些？ 本文档将通过一系列概念解读、趋势洞察以及产品对比，帮助用户更好理解不同概念与不同产品的区别，选择适合自己的Kubernetes存储方案。 2023年12月更新 目录 区分Kubernetes持久化存储、云原生存储、容器原生存储、Kubernetes原生存储对比3类Kubernetes持久化存储主流架构 对比Longhorn、Rook、OpenEBS、Portworx、IOMesh5种主流产品分析机构评估Kubernetes存储的关键指标 IOMeshPodHA：优化Kubernetes机制，提供高级别高可用持久化存储利用IOMesh为KubeVirt提供高效稳定的存储支持（附用户实践） 资源推荐 2023年12月更新 区分Kubernetes持久化存储、云原生存储、容器原生存储、Kubernetes原生存储 什么是Kubernetes持久化存储？ 首先需要明确的是，相较于作为一种存储方案类型，“Kubernetes持久化存储”更常被用作为一种概念，与Kubernetes上随Pod销毁或移动而无法持久化保存数据的存储卷（Volume）相区分。 Kubernetes支持很多类型的卷，包括持久卷（PersistentVolume）和临时卷（EphemeralVolume）。临时卷的生命周期与Pod一致，如emptyDir，其存储的数据会随着Pod的销毁而消失，仅可用作临时存储空间。而持久卷的生命周期比Pod长，即使Pod销毁也可保留下来。值得注意的是，HostPath虽然也是一种持久卷，但若Pod漂移到其他Node或当前Node故障，也无法保证数据持久化，因此有时被称为“半持久化存储”。 综上所述，“Kubernetes持久化存储”是指Kubernetes在管理Pod数据时使用的一组抽象概念和资源。这些概念包括PersistentVolume（PV）、PersistentVolumeClaim（PVC）和StorageClass。它们为Kubernetes中的应用程序提供了一种持久存储数据的方法。而云原生存储、Kubernetes原生存储等则是实现“Kubernetes持久化存储”的具体技术、产品、方 案。也就是说，所有支持Kubernetes环境中的应用数据持久化存储的方案，都是“Kubernetes持久化存储”，包括文中提到 的云原生存储、容器原生存储和Kubernetes原生存储。 什么是云原生存储？ 云原生存储（CloudNativeStorage）是一种基于云原生架构理念设计的存储方案，云原生计算基金会（CNCF）对此这样形容： 云原生存储是针对新的云原生现实而量身定制的：传统存储硬件与基础设施紧密绑定，不同数据中心也可能使用不同的存储接口，存储置备也难以自动操作；而云原生架构极具流动性、灵活性和弹性，容器化应用程序会不断地创建和删除，容器的物理位置也会发生变化，这些变化都对存储方案提出了新的要求： 1.为容器提供云原生存储选项； 2.将容器和存储提供商之间的接口标准化； 3.通过备份和恢复操作提供数据保护。 这意味着云原生存储需要使用云原生兼容的容器存储接口，并且可以自动进行置备，消除人为操作瓶颈，实现自动缩放和自我修复。在Kubernetes环境下，云原生存储使用提供标准API的容器存储接口（CSI）提供存储服务。 CNCF认证的云原生存储包括开源的和商用的存储产品。 图源：CNCFCloudNativeLandscape-CloudNativeStorage 由此可见，“云原生存储”是一个广泛的范畴，重点强调存储方案对云原生环境和接口标准化的支持特性，而并不区分存储类型、存储架构、部署环境、支持的应用负载等。例如，用户可以选择基于分布式块存储的商用闭源存储方案，支持I/O密集的应用场景，也可以采用公有云或开源的分布式文件存储产品，支持大数据量的文件存储场景。 因此，当面对一个“云原生存储”产品时，用户需要首先了解该存储方案支持的存储类型、存储接入方式、存储协议、兼容的容器运行时、对CSI的支持程度、支持的Kubernetes资源类型（如PersistentVolume、StorageClass等）以及适用的应用场景。 图源：CNCFWebinarSeries-CloudNativeStorage 另外，虽然云原生存储为Kubernetes提供数据持久化保存，但不是所有的Kubernetes持久化存储都是云原生存储，因为传统的存储解决方案也可以被用于Kubernetes。例如，用户依旧可以将本地磁盘，作为“Kubernetes持久卷”，但这种方式并不能算作云原生存储产品或方案。 什么是容器原生存储和Kubernetes原生存储？ 一些云原生厂商也将它们的存储方案细化为“容器原生存储（ContainerNativeStorage）”。 根据Gartner的报告《2022StrategicRoadmapforStorage》，“容器原生存储是专门为支持容器工作负载而设计的，重点解决云原生环境下独特的规模、粒度和性能需求，同时与Kubernetes容器管理系统深度集成。” 这些方案与云原生存储方案的主要区别在于，容器原生存储与Kubernetes的集成程度更深，能够更好地支持在Kubernetes运行的工作负载。不过，由于Kubernetes已经成为云原生时代既定的容器编排工具，整个容器应用生态均以Kubernetes为标准，“容器原生存储”与“Kubernetes原生存储”并没有本质上的区别。 Kubernetes具备跨环境的一致性特性，它能够支持应用在不同云环境中实现自动弹性扩缩容、滚动更新和自我修复。同时，KubernetesAPI为应用部署和管理的标准化与自动化提供了坚实基础。 因此，与核心业务紧密关联的有状态应用，如MySQL、PostgreSQL、Cassandra和RabbitMQ等，越来越多地运行在Kubernetes环境中，期望其获得与Kubernetes同样的弹性、标准化和自动化能力。这些数据库和消息中间件类应用在数据可靠性和性能方面，对Kubernetes持久化存储方案提出了更高的要求，推动了持久化存储技术的进一步发展和优化。 这些方案通常具备以下特性： •基于分布式、软件定义的统一存储池。 •具有容器级别的数据服务粒度。 •具备自助化存储资源运维能力。 •API驱动。 •与Kubernetes紧密集成（如支持与Kubernetes工具链集成）。 •可支持多种部署形式（如本地、边缘）。 •多种集成的高级数据服务（如容灾备份、加密、数据缩减）。 总结 由此可见，容器/Kubernetes原生存储包含在云原生存储的范畴，但不是所有的云原生存储都可以被称为容器/Kubernetes原生存储。基于此，我们可以将Kubernetes持久化存储、云原生存储、容器原生存储和Kubernetes原生存储之间的关系梳理成下图。 点击链接，阅读原文： 一文看懂Kubernetes持久化存储、云原生存储、容器原生存储、Kubernetes原生存储有何区别 在选择容器存储时，用户应结合容器承载的应用需求和自身的建设条件，选择合适的存储方案。尤其是对于Kubernetes集群上的数据库类、消息中间件类应用，应优先考虑采用性能更高、稳定性更强的容器/Kubernetes原生存储方案（基于分布式块存储），而不是外置的NFS存储。 对比3类Kubernetes持久化存储主流架构 为了满足不同的场景需求，Kubernetes可以支持基于不同架构的多种存储方案。这些方案间有什么区别？用户应如何选择？ 我们从架构角度出发，详细解读一下本地磁盘、CSI外接商用存储、Kubernetes原生存储3类Kubernetes持久化存储方案，并对比分析各个方案的能力与优劣势。 本地磁盘 首先，Kubernetes支持用户直接将本地盘插到服务器上作为存储设备。 由于磁盘和应用系统中间的I/O路径最短，本地磁盘可以提供最佳的性能。同时RAID提供了一定程度的可靠性的保证，可以避免因单个磁盘故障而导致的数据丢失。因此，目前有大量用户采用这种方式为有状态的应用提供存储服务。 但同时，本地磁盘方案也在可用性和扩容方面存在着巨大的缺陷： •本地磁盘无法提供节点级别的高可用，当物理节点发生故障时，应用无法被恢复到其他节点。如果业务系统有节点级高可用的要求，则必须由业务系统自己实现数据层面的高可用，这极大地增加了业务系统的复杂度。 •本地磁盘也无法满足Kubernetes环境下的业务敏捷性需求：业务使用的存储空间受限于本地磁盘的大小，达到磁盘空间的上限后，增加磁盘的操作步骤复杂，要想使用新增的硬盘空间，必须手工修改Pod中的配置，难以实现敏捷的平滑扩容。此外，要想对物理节点内的硬盘实现高可用，就需要部署RAID，这也是相当费时、费力、费钱的方案，难以实现在短时间内为大量的应用系统配置足够的存储容量。 此外，该方案无论是部署还是故障后的修复，都需要大量人力的参与，这使得本地存储方案的运维成本大大提高。同时由于节点间的存储空间无法共享，也很容易造成存储空间的浪费。 总的来说，本地磁盘的方案只适合在业务容器化的初期阶段进行小规模试用，或者作为较低重要性的数据存储使用，难以在大规模生产场景下被广泛使用。 CSI外接商用存储 为Kubernetes提供持久化存储的另一种方式是通过容器存储接口（CSI）将Kubernetes平台与底层存储基础设施连接起来，从而允许Kubernetes动态调配和配置存储、实现存储操作自动化。国际分析机构GigaOm将这些外接存储方案进一步划分为商用存储（EnterpriseStorage）和Kubernetes原生存储（Kuernetes-NativeStorage）两个类型。 商用存储既包括软件定义式存储（如分布式存储），也包括传统的集中式存储。与专为Kubernetes环境而设计的Kubernetes原生存储不同，商用存储通常情况下主要为裸金属和虚拟化环境服务，由于在企业中被广泛使用，通过CSI插件让商用存储获得容器存储支持能力，是非常方便且经济的选择。 然而，正因为商用存储在本质上更侧重虚拟化时代的功能特性，一些厂商推出的存储方案对云原生环境的支持能力仍有欠缺。另外值得注意的是，CNCF认可的“云原生存储”不仅包含Kubernetes原生存储，也包含基于不同架构的商用存储方案，产品间特性与性能差异较大，因此需要用户多加甄别。 1.外接集中式存储 Kubernetes集群外接集中式存储提供了可远程访问共享存储的能力。和本地磁盘的方案相比，集中式存储解决了应用系统高可用的问题，当业务Pod所在的服务器发生故障时，可以通过共享存储在其他节点上把应用拉起来，很多基于集中式存储的商用存储方案也提供快照、克隆、容灾等高级功能。此外，由于数据集中存储，也一定程度解决了本地存储对磁盘空间浪费的问题。 然而，传统集中式存储的架构（存储控制器加盘柜的形式）决定了它不能很好满足云