KubeCon China 2025 速递：成本 vs 性能，如何为 K8s 工作流选型最佳存储方案？-阿里云开发者社区

【阅读原文】戳：KubeCon China 2025 速递：成本 vs 性能，如何为 K8s 工作流选型最佳存储方案？

引言：工作流中的数据

在 Kubernetes 环境下，工作流场景对数据访问性能的敏感度远超传统应用。从实时特征提取到大规模批处理，存储系统的性能直接决定了工作流的执行效率与稳定性。

以大规模 Argo Workflows 场景为例，弹性扩缩容与动态调度特性对存储系统的弹性扩展能力、并发性能提出了更高要求。如何在成本约束下构建兼顾低延迟、高吞吐与强一致性的存储方案，已成为 K8s 工作流优化的重要命题。

在阿里云使用分布式工作流 Argo 集群，请参考使用文档分布式工作流 Argo 集群 [1]。

本文以自动驾驶场景抽象出的流水线为例，介绍该流水线中不同数据的特性与存储选型。

流水线分为数据清洗、算法处理和结果分析三个步骤，每个步骤均由若干并发 Pod 组成。数据清洗阶段从地图与实时路况数据集中提取相关数据，将其作为算法处理步骤的输入，并基于其输出生成最终分析结果。

因集群内 Pod 间无法直接传递数据，整个数据流转过程需依赖共享存储实现持久化。例如清洗数据先上传至对象存储，再由算法处理步骤读取。

Artifacts vs Volumes

Argo Workflow 中存储读写主要通过两种方式实现：

Artifact 机制。本质是对 MinIO 或云厂商对象存储 SDK 的封装。操作相对简便，仅需在 Pipeline 定义 YAML 文件中声明步骤的 Input/Output 路径即可完成数据下载与上传。该方案适用于并发量与数据量可控、无需考虑共享复用的场景，具体实现细节可参考 Argo 官方文档。
Kubernetes 原生 Volume（存储卷）机制。通过将存储介质挂载至 Pod 以实现数据交互。针对工作流场景中 Pod 生命周期短、高并发等特性，通常采用共享存储方案。

底层存储架构的差异性直接影响存储卷的读写性能表现，基于存储卷机制的设计与优化方案为本文接下来的探讨方向。

存算一体 vs 存算分离

在 Argo 工作流场景中，存储架构选型需结合数据特性与读写模式进行针对性设计。

首先考虑整体架构。笼统来说，根据存储介质与计算资源的物理关系，可以划分为：

存算一体：在容器化环境中，"一体"不再局限于单一物理节点，而是指业务 Pod 可以通过容器网络访问集群内共享的本地存储资源（如节点池化系统盘）。
存算分离：以对象存储（如 OSS）为代表的云存储。数据与计算解耦，便于弹性扩展。

选择存储架构时的核心考虑因素：

可扩展性和灵活性：
本地存储：容量受限于节点数量与机型配置，需提前规划存储资源分配。云存储：容量弹性、按需付费，适合数据量波动大或峰值明显的业务（如日志分析、临时文件存储）。
性能与延迟：
本地存储：相对低延迟、高吞吐，但受限于单节点 IO 瓶颈（如 HDD/SSD 性能差异）。
云存储：可通过缓存或预加载优化性能。AI 时代各云厂商也提供了高性能的云存储解决方案，如 CPFS。
成本与运维开销：
本地存储：可复用节点空闲资源，但需承担系统运维（安全加固、容灾副本、生命周期管理）成本。
云存储：隐性成本包括数据传输费、冷热分层策略设计，需结合业务 SLA 综合评估。

对于 Argo 工作流场景，还需要额外关注存储系统最大并发读写能力，避免因 IO 上限导致任务阻塞。一般云存储都会声明读写 IO 上限；而本地存储系统，需要投入生产前压测验证。

此外，对于一些临时的中间数据，需设计按需隔离机制（如命名空间隔离），并结合生命周期策略（TTL）或自动化清理脚本降低存储冗余。

本文将进一步探讨在主流的存算分离架构下，不同存储介质在工作流中的选型实践。（KubeCon 分享中也简单讨论了存算一体架构下的重要组成部分——分布式文件系统，可以点击文末阅读原文查看。

文件存储 vs 对象存储

云存储可分为块存储、文件存储（下称 NAS）和对象存储（下称 OSS）三类。表格已汇总三类云存储的基本特性与对比，各云厂商均提供更细分的子产品与规格型号。

在阿里云 ACK 场景中，您可参考概述文档存储概述 [2] 了解容器存储类型与能力。

需要注意的是，表格中的性能对比并非绝对：某些块存储产品也支持并发访问；低性能云硬盘的延迟可能高于阿里云 CPFS 等高性能 NAS 类产品。总体而言，基于数据容量和共享需求，在Argo Workflows 等强 Job 型工作流场景中，NAS 与 OSS 的使用率更高。

NAS：支持完整 POSIX 语义，无需对象到文件系统的转换开销，在海量小文件处理、元数据密集型场景中具备显著优势，尤其适用于高性能计算（HPC）等强 IO 需求场景。其在容器场景使用门槛较低，通过 NFS 内核挂载即可直接访问数据。

若需在 ACK 中部署 NAS 存储，可参考 NAS 存储卷概述[3] 与 CPFS 存储卷概述 [4]。其中，后者（CPFS）则适用于对吞吐量有极致要求的高性能计算场景。

OSS：虽常被开发运维人员视为“成本优势显著但性能相对受限”的方案，但其无限容量、低费用及 HTTP 协议的开放性，使其在大数据、AI 训练等场景中不可或缺。例如自动驾驶实况数据通常依赖边缘设备通过 HTTP 接口上传至对象存储。此类特性决定了其仍是大数据业务的核心选择。

若需在 ACK 中部署 OSS 存储，可参考 OSS 存储卷概述 [5]。

针对低成本的 OSS 方案，本文后续将聚焦两个关键问题：

适用边界分析：哪些业务场景应谨慎使用 OSS？
性能优化路径：如何通过技术手段提升 OSS 在容器化环境中的读写效率？

OSS：从性能瓶颈到优化方案

性能瓶颈根因

对象存储的性能问题，本质上源于其架构与访问方式的固有特性。

首先，对象存储的平铺结构与 POSIX 文件系统的树形结构存在天然冲突。当我们需要通过 POSIX 协议访问对象存储时，必须依赖 FUSE 客户端作为双向转译器，将系统调用转换为 HTTP 请求，并处理响应数据。

这一过程在 Kubernetes 中具体表现如上图所示，大致可以抽象为：Pod 创建时触发挂载流程，CSI 驱动运行 FUSE 客户端，在 Kubelet 的挂载路径下生成挂载点，并同步到 Pod 的 Mount Namespace。挂载成功后，业务才能通过 FUSE 客户端与对象存储服务端交互。

如果对 K8s 场景 OSS 数据挂载的原理和优化感兴趣，可关注KubeCon 2025 EU DoK 议题《Pains and Gains: Lessons from Orchestrating Volumes for Remote Storage in Cloud-Native AI Scenarios》

议题视频链接：

https://www.youtube.com/watch?v=T_Lx2ZFhfJQ

然而，FUSE 协议本身会引入链路开销。更关键的是，对象存储的特性进一步加剧了性能瓶颈，比如：

对象仅支持覆盖上传，FUSE 客户端支持随机写操作需落盘并加锁，性能受限于磁盘 IO。
对象的元信息有限（如缺少文件权限、所有者等属性）。当业务进行业务的目录遍历、属性查询等操作时，FUSE 客户端需通过大量 HTTP 请求补充或遍历对象的扩展信息。虽然部分客户端支持元信息缓存优化，但实时同步场景（如自动驾驶的实时路况数据）无法依赖缓存，导致性能进一步下降。

因此，对于需要强一致性、高并发、随机写入或依赖文件元信息的的场景，建议优先考虑 NAS 方案。

常见性能优化方案

在 Kubernetes 工作流场景中，对象存储的性能瓶颈常通过以下方式缓解。加速效果受业务特性（如数据规模、读写模式、一致性要求）影响较大，图中列出了不同方案的优劣势对比。

修改服务端存储布局：通过挂载点（存储卷）或 SDK 将数据以特定格式存储于 OSS 云端。可以在保证高 POSIX 兼容的情况下提升性能。缺点是数据仅能通过特定工具读写，通用性差，难以与其他系统兼容。
使用轻量客户端：“轻量”指舍弃元信息处理、随机写等复杂操作，专注于顺序写与只读场景的性能优化，专注于只读顺序写能力的提升。侵入性较低，无需修改数据格式，适合 AI 训推等以顺序读为主的 Pipeline。缺点是需要业务严格满足 POSIX 兼容矩阵。

ACK 集群 CSI 存储插件默认提供基于 ossfs 2.0 轻量客户端的存储卷类型，使用方式、性能压测等具体数据可参考文档 ossfs 2.0 存储卷概述 [6]。

集群侧分布式缓存：将集群节点的内存/磁盘资源池化，缓存热点数据或临时中间结果，以空间换时间。在大并发场景中，缓存可避免直接访问对象存储，规避 API 调用上限（如 OSS 在小地域可能有 5-20 Gbps 限流）。因此，在工作流场景中，判断是否启用缓存的关键指标之一是是否已触达 OSS 的服务端限流。缺点是需要引入缓存组件，性能收益依赖缓存命中率。
服务端加速（托管侧缓存）：由云厂商提供全局加速服务（如 OSS 加速器），用户无需部署额外组件，但成本可能随加速流量上升，需结合业务 SLA 与预算评估。

扩展：突破 FUSE 性能瓶颈的新尝试

针对容器环境访问 OSS 的性能问题，我们正在探索一种基于虚拟块存储的优化方案。该方案的核心思路是：

初次挂载时构建元信息索引：通过预解析对象存储的元数据，在本地生成结构化的索引表，减少后续访问时的 HTTP 请求次数。
内核层优化：利用 UBLK（用户态块设备驱动架构）和内核态文件系统（如 erofs）直接响应系统调用，绕过传统 FUSE 的用户态-内核态切换开销。

这一方案的优势在于：

显著降低FUSE开销：通过内核层直接处理系统调用，减少上下文切换和协议转换的延迟。
适用于海量小文件场景：对海量只读小文件（如AI训练数据集）和频繁读取少量数据的场景（如日志分析）优化效果尤为明显。
稳定性提升：相比FUSE客户端，内核态实现更稳定，不易因高并发或异常请求导致挂载失败。

在 ACK 集群可以通过 strmvol 存储卷体验该方案，方案简介与使用方式、性能压测等具体数据可参考文档 strmvol 存储卷概述 [7]。

如果对该方案的具体原理与实现感兴趣，可关注KubeCon 2025 EU 议题《Streamlined Efficiency: Unshackling Kubernetes Image Volumes for Rapid AI Model and Dataset Loading》，该议题分享了使用该原理实现镜像下载加速。

议题视频链接：

https://www.youtube.com/watch?v=nHGzMmstR0E&t=13s

总结

Artifacts vs Volumes?

并发量、数据量可控，数据不需要实时共享的场景使用 Artifacts 更简单。否则应考虑 Volumes 及其选型与调优。

存算一体 vs 存算分离？

存算一体适合非数据型企业通过 MinIO/Ceph 等开源方案实现低成本基础读写，或大型 AI 公司通过 3FS 等开源方案利用 RDMA 等硬件及 GPU 闲置存储资源（需具备二次开发能力）。其余企业仍以存算分离为主。

在 ACK 集群使用 eRDMA 与弹性临时盘 EED 部署 3FS 存储集群，可参考文档基于 ACK 集群部署 3FS [8]。

NAS vs OSS?

NAS/CPFS 有性能优势，适合 HPC 场景，对于需要强一致性、高并发、随机写入或依赖文件元信息的的场景，建议优先考虑 NAS 方案。若考虑成本、容量与 http 访问简易性，选择 OSS 时可针对数据特性与访问模型进行调优。

OSS 优化方案

通用的 OSS 访问性能优化方案包括修改服务端存储布局、使用轻量客户端、集群侧分布式缓存及服务端加速等。

在自动驾驶流水线中，静态地图数据适合用带缓存的客户端存储卷（如 JindoFuse），实时路况数据则可用轻量客户端（如 ossfs 2.0）。中间及最终数据上传下载可结合 Argo 原生 Artifacts 或轻量客户端存储卷，按并发量选择。

对于 OSS 的性能优化，实践经验是：单一存储卷难以满足全流程性能需求。建议按数据的特性和业务的访问模型拆分多个存储卷（如隔离随机写与只读场景）。因此在优化 OSS 存储访问时，还需要权衡运维难度与性能限制。以本流水线为例，若维护成本高，可优先全用轻量客户端；若使用 Fluid 等缓存平台，可选择同时支持无缓存模式的客户端。

相关链接：

[1] 分布式工作流 Argo 集群

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/kubernetes-clusters-for-distributed-argo-workflows/

[2] 存储概述

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/csi-overview-1/

[3] NAS 存储卷概述

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/nas-volume-overview-1/

[4] CPFS 存储卷概述

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/cpfs-volume-overview/

[5] OSS 存储卷概述

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/oss-volume-overview-1/

[6] ossfs 2.0 存储卷概述