一文了解评估 K8s 原生存储产品需要关注的关键能力
近些年，越来越多的企业使用 Kubernetes（K8s）支持生产环境关键业务。这些业务往往对存储性能和稳定性具有更高的要求，传统存储方案难以充分满足，因此不少用户开始关注更契合 K8s 环境的 K8s 原生存储方案。
不过，面对不同厂商的 K8s 原生存储产品，用户应如何进行选型？有哪些需要重点关注的产品特性与能力？GigaOm 在《Key Criteria for Evaluating Kubernetes Data Storage Solutions v4.0》报告中，分析了容器环境对存储方案的特性需求，并列举了决定/影响这些特性的产品能力，包括 4 项标准能力、5 项关键差异能力和 3 项新兴技术支持能力。本文将结合这篇报告，对 K8s 原生存储关键能力进行深入解读，以便用户更好地进行选型评估。
评估维度：K8s 环境看重存储产品哪些特性？
GigaOm 认为，为了满足 K8s 环境的存储需求，存储方案的以下特性表现至关重要：存储架构、可扩展性、灵活性、效率、可管理性和性能。
存储架构
存储架构将直接影响产品性能和扩展性。GigaOm 根据存储架构将 K8s 外接存储方案划分为商用存储（Enterprise Storage）和 K8s 原生存储（Kuernetes-Native Storage）两个类型。
商用存储是指通常基于软件定义的控制器架构，或基于物理的控制器架构构建的存储解决方案，可以软硬件捆绑的形式提供，也可以纯软件交付。这些商用存储通常情况下主要为虚拟化环境而设计，并且已经通过 CSI 插件扩展了对容器的支持能力。由于这种方案允许企业沿用既有存储，因此可以快速、经济地实现部署。然而，商用存储毕竟与容器化应用属于不同的“世代”和“架构”，容器快速创建/销毁时，后端和元数据操作的数量非常大，一些传统存储难以适应基于容器的工作负载的短暂存在和动态变化的特点，容器数量的增长也会导致性能瓶颈和扩展困难。
K8s 原生存储是专门为支持容器而构建的存储方案。K8s 原生存储系统本身作为 K8s 集群上的一组容器运行，通过 CSI 将存储暴露给集群，供工作负载使用，并与 K8s 集群中的应用工作负载一起运行。K8s 原生存储通常基于分布式架构，与 K8s 紧密集成，在容器创建/销毁时会处理存储配置和撤销配置操作，专为 K8s 环境优化的存储技术也使得 K8s 原生存储具备更好的性能。而且，这种存储方案遵循集群的自动扩展规则，在添加或移除集群节点时，存储系统也会自动扩缩容，非常动态和灵活。
欲深入了解两种存储架构的特点和优劣势，请阅读：本地盘 vs CSI 外接存储 vs K8s 原生存储：详细解析 3 种 K8s 持久化存储方案。
可扩展性
在企业不断扩大 K8s 的使用范围时，应注意避免造成 K8s 集群间的孤立。一个可扩展的存储方案允许用户从小规模开始部署，根据业务需求按需扩展存储资源，而无需更换基础架构的基本组件。存储方案还应允许企业整合 K8s 基础设施，并支持试运行阶段的多环境混合部署。对于使用既有（传统）存储方案的 K8s 集群而言，可扩展性可能是一个独特的挑战，因为这些存储可能无法随着 K8s 的使用进行扩展，从而不得不进行翻新或替换。
灵活性
云原生时代，数据不再局限于数据中心，而是被分散存放在不同的环境中——企业内部、多云、SaaS 应用程序和边缘站点——这也因此带来了延迟、移动应用与用户侧数据。这种分散化现象要求数据必须能够在必要时跟随应用程序进行移动：只有当存储层可以部署在不同的环境中，并且能够正确、透明地管理和移动数据，无缝移动才有可能实现。此外，数据存储层应与基础架构的其他部分一样具有弹性，能够动态分配资源，并在任务完成后迅速释放资源，让存储能够在任何特定环境中同应用一起扩缩容。
效率
传统的商用存储在资源利用和 I/O 处理方面非常高效。然而，由于商用存储软硬件专为相对静态和偏向长期保存数据的物理和虚拟化环境而设计，这种方案在支持短暂、动态的容器环境时，运行效率略显不足。
K8s 原生存储更适合容器环境，但与传统存储相比，K8s 原生存储相对不够成熟，尚难以达到物理/虚拟化环境中商用存储的运行效率。影响存储效率的因素有很多，包括架构和底层硬件性能，以及擦除编码、压缩、重复数据删除等数据占用优化（Data Footprint Optimization）功能。
可管理性
K8s 存储有许多开发人员和工程师用户，他们需要通过 API 自行配置和使用存储。这要求 K8s 存储具备易用性和自助服务功能。除了这种编程式访问，存储方案也需要照顾到传统架构的存储管理员，为他们提供熟悉的图形用户界面用于管理。此外，可管理性还要求存储系统与 K8s 生态系统易于集成，包括备份、监控、仪表板和其他第三方操作或管理系统。
性能
无论容器在哪里运行，如果存储性能不佳，用户体验都会大打折扣。性能是以 IOPS、延迟和吞吐量来衡量的，这些很大程度上是由底层硬件决定的。在多数情况下，如本地部署和边缘环境，管理员可以控制底层硬件；而在云环境中，尤其是当客户间共享硬件时，性能往往是不透明且难以保证的。因此，用户选择在哪个存储平台运行应用程序时，性能是一个重要的考虑因素。
关键指标：影响特性的重要产品能力
基于这些存储特性，GigaOm 将其影响因素分为三类：标准能力（Table Stakes）、关键差异能力（Key Criteria）和新兴技术支持能力（Emerging Technologies）。
标准能力：在 K8s 存储领域被广泛采用并良好应用的特性和功能。这些能力已经较为成熟，因此不会对产品特性/方案价值产生较大影响，对总拥有成本（TCO）和投资回报率（ROI）的影响也微乎其微。
关键差异能力：是 K8s 存储领域的核心差异化特征，是决定产品之于企业是否有价值的重要能力。这些能力的实现细节会直接影响产品/服务，从而给企业基础设施、流程和业务带来深远影响。随着时间的推移，一些关键差异能力可能会随着产品迭代，变成该领域产品的标准能力。
新兴技术支持能力：指在未来 12 至 18 个月内，在 K8s 存储领域出现的最具吸引力和潜在影响力的技术。一些高端产品可能已经为解决具体场景问题准备了这些新兴功能，但当前技术还不够成熟，不能被视为关键标准。
标准能力：CSI 兼容性、快照功能、运行和数据安全、云和平台支持
CSI 兼容性
CSI 规范并不要求插件支持规范中的所有功能，但至少需要支持的基本功能包括：
卷的静态与动态置备。
创建和删除快照。
卷扩展和卷克隆（基于卷或快照）。
支持四种 CSI 访问模式（RWO、ROX、RWX 和 RWOP），用于管理集群中跨节点和 Pod 的读/写操作。
快照功能
基本能力应包括数据移动功能，即可以基于卷和快照及其持久化存储，创建应用程序的克隆和副本。除了存储阵列上的持久化存储卷，快照操作还应能捕获 K8s 对象和资源（包括部署、服务、持久卷、ConfigMaps、机密、标签和命名空间）。
此外，为了实现备份、灾难恢复和迁移，将快照移动到异地（云或企业外）的能力也被评估为一项基本能力，但不包含实施和平台支持能力（将快照传输到远程存储集群或对象存储）。
运行和数据安全
K8s 存储应具备合适且可同时支持本地和云环境安全的功能特性。基本能力应包括：
数据加密：当数据在静态和传输过程中处于加密状态，用户可以在云中使用 Kubernetes 或托管平台，而不会面临物理存储或服务提供商相关的安全风险。目前，一些 K8s 原生存储方案实现了加密密钥的一致管理，让卷能够在各个环境（本地和云）使用客户管理的加密密钥。
自带密钥：存储方案应支持第三方密钥管理系统，具备自带密钥的能力，以防止存储供应商访问客户的数据。
基于角色的访问控制（RBAC）：根据角色为用户和管理员提供不同级别的访问权限和可见性，帮助企业更严格地控制访问管理原则以及身份验证和授权，同时向更多用户（包括软件开发人员和数据工程师）开放访问权限。与目录服务的集成以及使用 Kubernetes 本机结构实施 RBAC 的能力是一个关键的差异化因素。
勒索软件保护：存储解决方案必须支持基本的勒索软件保护功能，包括保留策略锁、快照不变性和异常检测。
云和平台支持
成功部署 K8s 的关键在于存储层能够跟随数据移动。GigaOm 希望存储方案能够以多种方式部署，并拥有广泛的平台/部署环境支持，包括企业内部、云、边缘环境以及较小的独立服务提供商。部署应实现标准化和自动化，从而降低在新位置部署存储的难度，这种能力具体包括支持集成到 Kubernetes 服务、Helm 图表或虚拟设备中，以及能够简化部署和生命周期管理的能力。
关键差异能力：原生存储集成、数据复制服务、数据占用优化、自动监控 & 可视化洞察、开发人员使用支持
原生存储集成
CSI 规范非常详尽，包括许多用于存储管理的高级功能，但很多都不强制供应商提供，一些存储方案中包含的高级功能也不是 CSI 规范的一部分。为此，存储厂商只能在其 CSI Driver 上创建额外的插件，帮助他们将自研的高级功能集成到 K8s 集群中。（GigaOm 注明，这一能力的评估重点是为 K8s 集群和用户提供原生功能的能力，而不是功能本身。）
CSI 插件应具备的差异性功能包括：
支持块卷（在容器中显示为块设备）和文件卷（在容器中显示为目录）。
更多快照功能，包括还原快照以代替原始卷，以及在一致性组中维护崩溃一致性卷组，以确保数据卷、Pod 和应用程序之间的数据一致性，从而实现快照、副本、容灾和备份与恢复。
支持同步和异步复制，允许工程师和开发人员使用供应商的原生复制技术复制（组）卷，包括启动应用程序和在目标集群中创建 PV 对象（代表复制的卷）。
自动从存储系统向 Kubernetes API 传递有关存储层或存储类的信息—— NVMe、SSD、HDD 等。
对对象和资源（包括部署、服务、持久卷、配置映射、机密、标签和命名空间）的原生支持。这反映了厂商对 K8s 元数据模型的深刻理解，以及捕获这些信息作为快照和副本的一部分的能力。
协议级验证和授权，包括 RBAC 和配额。
支持对卷进行多路径管理，支持故障切换。
数据复制服务
数据复制服务包括同步和异步复制、容灾、故障恢复后回切和再保护工作流，以及备份和恢复功能。这里主要关注数据迁移、数据复制管理等支持能力的广度和深度。
要想充分发挥 K8s 的优势，关键要解决数据固有惰性的问题。为了在不同环境的不同存储系统之间移动数据，需要特定的数据移动功能。远程复制功能是数据保护和灾难恢复的基础，还能缩短将工作负载迁移至云的时间。远程复制有两种方式：同步复制和基于快照的异步复制。在这两种情况下，目标站点都需要一个类似的存储集群。
这些技术有多种用例，包括备份和容灾，以防止内部站点或云可用区域出现故障和故障恢复情况。此外，这些技术还可实现数据迁移和移动功能，在企业内部、云、边缘和其他位置之间逐步无缝迁移数据。除了底层复制技术，这些用例还需要工作流和特定的用户界面，这也是该关键能力的一部分。
具体就数据保护而言，理想的 K8s 原生存储方案应使用基于存储的快照（通过 CSI 或其他方式支持 Kubernetes）并捕获完整 Kubernetes 元数据状态和应用对象。
数据占用优化
数据占用优化即使用各种技术来避免存储后端出现数据重复和数据碎片，如自动存储分层、删除重复数据、擦除编码、压缩数据和其他数据放置优化技术。这些技术可提高数据占用效率，进而防止成本增加、性能降低和可扩展性变差。
不过，大多数 K8s 原生存储方案还未实现与传统存储相同的全面数据占用优化方案。未来，容器部署将持续增长，欠缺数据占用优化功能或功能较差的 K8s 存储将难以满足未来的存储需求。
自动监控 & 可视化洞察
比起标准的监控和警报功能，具备强大分析功能的存储方案更具优势——既可让企业快速分析整个基础架构的状态，在问题出现之前发现问题，还可为基础架构提供强大的安全性和容量优化能力。
这一关键能力主要关注产品的自动监控与可视化功能是否可以做到“开箱即用”，包括是否将自动监控与可视化功能与 Prometheus 和 Grafana 集成，以及这两个工具对存储环境的探测/可视化程度有多深（阵列级、集群级、卷级和应用级）。此外，理想的存储方案还能让管理员从存储角度了解 K8s 应用的对象拓扑，包括持久卷和声明，以及供应商存储系统中的原生对象，如 LUN 或文件共享。
最后，由于 K8s 正在使基础架构对开发人员和工程师越来越友好，成本控制是任何一个 K8s 存储方案都应具备的关键能力，这其中也包括在各环境部署卷、存储和应用的成本可见性。
开发人员使用支持
K8s 存储应为开发人员的使用提供一流的支持，让他们使用熟悉的工具与存储系统进行交互，这意味着存储系统需要与 API 集成，并支持通过 K8s API、命令行工具和基础架构即代码（IaC）工具，以按需自助的方式实现访问和管理。
存储管理员应能通过存储类为 K8s 定义并公开高级存储功能（如性能、复制、快照计划等），让开发人员能够使用这些特性。为保证系统性能、管理成本，管理员应能通过配额和 QoS 功能限制专用于特定存储类、应用或集群的资源数量。
新兴技术支持能力：边缘应用与管理、对象存储和多协议支持、高性能存储
边缘应用与管理
很多已经在边缘部署 K8s 集群的企业，面临着如何管理数量多规模小的集群、使用集中式蓝图或模板简化集群创建并保持一致性等挑战。K8s 存储应在边缘场景得到使用，提供原生存储管理的能力（包括数据在边缘集群和中心集群间复制的基本和高级功能），同时支持没有稳定互联网链路的站点或处于安全保护下的环境。
对象存储和多协议支持
由于对象存储通常都用于云服务，它既不是 K8s 集群基础设施的一部分，也不容易在应用程序的 YAML 定义中看到。K8s 社区正在开发容器对象存储接口（COSI），未来的存储应能够支持这一接口。此外，针对托管数据库服务也有类似的项目，让 K8s 可以对接云托管、云管理服务等。
高性能存储
随着 NVMe 以及更快速、先进的存储技术逐渐成熟，K8s 存储方案也应利用这些技术优化 I/O 路径，从而减少延迟、提高吞吐量。
除了以上产品能力，厂商对 K8s 的原生支持能力也会直接影响存储方案的实际表现。目前，对于 K8s 原生存储，用户可以选择开源产品（以基于 Ceph 开发的 Rook 和 Longhorn 为代表），也可以采用闭源商用产品（以 Portworx 和 IOMesh 为代表）。这两种方案都能提供 K8s 原生的数据存储功能，也各有利弊：开源产品没有采购成本，定制更灵活，具有技术实力的客户可以自行开发，但若出现严重故障或漏洞，很难像商业厂商那样通过专业团队提供快速响应、深度解决问题的服务支持。另外，通过性能测试可以看出，目前基于自研闭源技术的 K8s 存储方案，在性能和稳定性方面要优于开源产品。欲了解测试详情，请扫描二维码，阅读《主流 K8s 持久化存储方案特性与性能对比（Longhorn / Rook / OpenEBS / Portworx / IOMesh）》。
交叉分析：能力对特性的影响程度
基于以上特性与能力解读，GigaOm 对不同的关键差异能力在多大程度上影响 K8s 存储产品的哪些特性，进行了交叉分析（如下图）。建议用户结合企业 K8s 存储使用情况，评估最为看重的产品特性，并在选型时重点关注对这些特性带来较大影响的产品能力（例如，企业需要使用 K8s 原生存储承载 K8s 平台上数据库等性能要求较高的应用，则需重点关注产品的性能特性。如表中所示，对 K8s 存储性能影响最大的关键能力是“数据占用优化”、“原生存储集成”和“数据复制服务”，那么选型时应重点考虑具备这些能力的产品方案）。
注：表格左侧列为 5 项 K8s 存储关键差异能力，表格第一行为 K8s 存储关键特性，能力与特性交叉点的数字，表示该能力对这一特性的影响程度，数字越大，影响能力越大。用户解读时，既可关注某项能力会影响哪些产品特性，也可分析为了满足某一产品特性需要具备哪些关键能力。
另外，从表中不难发现，“原生存储集成”（即与 K8s 生态无缝对接的能力）是对 K8s 原生存储方案水平总体影响最大的能力，尤其是在架构优势、灵活性、可管理性和性能这些重要维度，“原生存储集成”起着至关重要的作用。正如上文所述，与 K8s 的集成程度，真正体现了一个厂商对 K8s 环境与技术的理解程度和自主研发的能力。因此，K8s 存储产品是否具备自主研发、提供多种高级功能、与 K8s 高度集成且在生产环境中顺畅应用的 CSI 支持，很大程度上反映了产品的整体价值。
作为国内首款 K8s 原生的企业级分布式存储，IOMesh 以自主研发的核心技术，可无缝融入 Kubernetes 原生的开发和运维体系，对 Kubernetes 集群内的存储资源进行整合与管理，为运行在 Kubernetes 集群上的各类有状态应用提供稳定、高性能的持久化存储资源。
除了标准能力，IOMesh 还具备多种 K8s 原生存储关键差异能力与新兴技术支持能力：
原生存储集成：完全基于 Kubernetes 自身能力构建，充分利用 Kubernetes Worker 节点的硬件资源融合部署，支持动态置备，提供本地卷和多副本分布式存储卷，并提供 Kubernetes 原生的操作方式和工具。
自动监控 & 可视化洞察：支持与 Kubernetes 工具链集成，支持将监控与报警功能集成进 Prometheus 和 Grafana ，提供可视化监控数据与报警提醒。
开发人员使用支持：使用 Kubernetes Operator 统一运维，基于 Helm Chart 部署，提供声明式 API 管理能力，加快部署与扩容。
高性能存储：通过 I/O 本地化、冷热数据分层、全闪存支持、扩展的 Local PV 等技术优化，提供高性能与低延时。
边缘应用与管理：可完美融入用户基于 K8s 构建的边缘应用，支持 IT 客户构建边缘计算解决方案。
欲深入了解 IOMesh 技术特性，请扫描下方二维码，获取《IOMesh 用户指南》。
参考文章：
1. Key Criteria for Evaluating Kubernetes Data Storage Solutions v4.0，GigaOm，2023
https://research.gigaom.com/report/key-criteria-for-evaluating-kubernetes-data-storage-solutions/
推荐阅读：