By Jermine

技术选型

☰

在 Kubernetes 上跑 CI/CD，编译产物需要一个共享位置中转，供打包、测试、发布等环节读取——这是编译流水线里非常典型的存储需求。这个中转存储的核心诉求有四点：

  1. 多 Pod 共享访问：编译 Pod、打包 Pod、测试 Pod 可能同时访问同一批制品，PVC 最好支持 ReadWriteMany。
  2. 成本敏感：编译制品大多是临时数据，生命周期短、容量波动大，不值得长期放在高性能块存储或高性能文件系统上。
  3. 与现有 BOS 生态一致：Fluid 本身已经需要挂载自有 BOS Bucket，如果制品中转也落在 BOS 上，数据链路和权限体系可以统一。
  4. 性能要求不是数据库级：编译制品中转更关注吞吐、共享和成本，而不是微秒级随机 IO。

围绕这个需求，本文对比了百度智能云的 CDS、CFS、PFS、BOS，并评估了 BOS 原生 CSI、Fluid + JuiceFS + BOS、RapidFS 等方案。最终结论是：选择 BOS 作为后端存储，通过 Fluid + JuiceFS 提供 RWX 模式的 PVC，满足编译制品中转需求。

一、四类存储的定位对比

1.1 CDS：高性能块存储，但不适合共享

CDS 是云磁盘，提供块设备接口，类似虚拟硬盘。它的优势是低时延、高 IOPS，适合数据库、系统盘、I/O 密集型应用。但它通常是单节点挂载，不支持多 Pod 同时读写，因此不适合作为编译制品共享中转层。

成本上，CDS 跨度很大：通用型 HDD 约 0.25 元/GB/月，高性能云磁盘约 0.35 元/GB/月，增强型 SSD 可到 2 元/GB/月左右。即便选低端型号，它也不是为多节点共享文件访问设计的。

结论：CDS 性能好，但访问模型不匹配，排除。

1.2 CFS：通用共享文件存储，但成本高于对象存储

CFS 提供 POSIX 文件接口，支持多节点同时挂载读写，天然支持 RWX。性能型 CFS 约 1.8 元/GB/月，容量型约 0.35 元/GB/月。容量型在成本和共享之间比较平衡，适合内容管理、Web 服务、企业文件共享等场景。

但对于编译制品中转，CFS 的单位容量成本仍然明显高于 BOS 标准存储的约 0.119 元/GB/月。如果制品总量较大且生命周期短，长期看成本不够理想。

结论：CFS 可用，但成本不如 BOS，排除作为主方案。

1.3 PFS：高性能并行文件系统，性能确定但成本高

PFS 面向 AI 训练、HPC、自动驾驶、视频渲染等场景，提供亚毫秒级延迟、百万级 IOPS、超高吞吐，并且完全托管，无需自己维护元数据引擎。它支持多节点共享，是高性能 RWX 的“天花板”选项。

但 PFS 价格约 1.45 元/GB/月，且通常有起步容量要求。对于编译制品中转这种成本敏感、性能要求并非极致的场景，PFS 属于性能过剩。

结论：PFS 很好，但对当前场景过重，排除。

1.4 BOS：低成本、高弹性，适合制品中转

BOS 是对象存储，标准存储约 0.119 元/GB/月，低频和归档更低。它扩展性强、成本低，适合读多写少、备份、归档、数据分发等场景。BOS 原生 CSI 驱动支持的访问模式主要是 RWO 和 ROX，不能直接提供标准 RWX，这是它作为共享文件层的一个限制。

但 BOS 作为后端存储非常合适：编译制品写入后，主要被下游读取；制品生命周期短，可以通过生命周期规则清理；容量弹性好，不需要预先规划大容量文件系统。

结论：BOS 成本最合适，但需要额外一层文件系统来提供 RWX。

1.5 对比总览

存储类型标准型价格（约，元/GB/月）多 Pod 读写共享对本场景的适配度
CDS块存储0.25 ～ 2❌ 单节点挂载访问模型不匹配，排除
CFS共享文件存储0.35 ～ 1.8✅ 原生支持可用，但成本偏高
PFS并行文件系统1.45✅ 原生支持性能过剩，成本过高
BOS对象存储0.119⚠️ 原生 CSI 仅 RWO/ROX后端首选，需补齐 RWX

二、为什么 BOS 原生 CSI 不够？

BOS 是对象存储，数据模型是“一写多读”。原生 BOS CSI 插件创建 PV/PVC 时，通常只支持：

  • ReadWriteOnce：单节点读写；
  • ReadOnlyMany：多节点只读。

它无法像传统文件系统那样让多个节点同时以读写方式挂载同一个卷。因此，如果直接使用 BOS CSI，编译制品中转无法获得标准 RWX PVC。

这正是需要 JuiceFS 的原因。

三、Fluid + JuiceFS + BOS：让 BOS 具备 RWX 能力

在这个组合中，三者分工明确：

  • BOS：作为数据后端，承载实际制品数据，提供低成本、高弹性的持久化层。
  • JuiceFS：提供 POSIX 兼容的分布式文件系统层，通过元数据引擎管理目录、文件锁和并发访问语义，使 Kubernetes 可以将其以 ReadWriteMany 模式暴露给多个 Pod。
  • Fluid：作为 Kubernetes 原生的数据集编排与加速层，管理 JuiceFS Runtime，并在计算节点提供缓存能力，加速对 BOS 中数据的访问。

关键点是：RWX 不是 BOS 直接提供的，而是 JuiceFS 文件系统层提供的。 BOS 只是 JuiceFS 的对象存储后端。

在 Fluid Dataset 中，可以指定 JuiceFS 使用 BOS：

 1apiVersion: data.fluid.io/v1alpha1
 2kind: Dataset
 3metadata:
 4  name: jfs-bos-compile
 5spec:
 6  mounts:
 7    - name: bos-mount
 8      mountPoint: "juicefs:///compile-artifacts"
 9      options:
10        bucket: "https://your-bucket.bj.bcebos.com"
11        storage: "bos"

认证信息通过 Secret 引用 BOS 的 Access Key 和 Secret Key。创建 Dataset 和 JuiceFSRuntime 后，Fluid 会生成对应 PV，用户创建 PVC 时指定：

1accessModes:
2  - ReadWriteMany

即可让多个编译、打包、测试 Pod 同时挂载读写。

四、为什么不是 RapidFS？

RapidFS 的角色和 JuiceFS 有相似之处：都在 BOS 之上提供缓存加速和文件访问入口。但 RapidFS 的定位更偏向托管读缓存加速，官方描述适用于“以读为主、小写较少”的场景，随机写能力较弱。

编译制品中转虽然整体是“写入后读取”，但编译阶段会有持续的制品写入。RapidFS 不是完整的自建文件系统替代品，写路径不是它的强项。对于需要完整 POSIX 读写语义和 RWX 写场景的编译中转，JuiceFS 更合适。

RapidFS 的价格按缓存容量计费，约 0.703 ～ 0.8 元/GB/月，适合读多写少的推理和数据分析，不是这个场景的最优选择。

三种方案横向对比：

方案RWX 写支持写路径成本运维要点
BOS 原生 CSI❌ 仅 RWO/ROX—最低无法满足共享读写
RapidFS部分（弱随机写）托管读缓存为主0.703 ～ 0.8 元/GB/月（缓存容量）不适合持续写入
Fluid + JuiceFS + BOS✅ 完整 POSIX元数据引擎 + 对象后端0.119 元/GB/月（BOS）+ 自维护元数据引擎元数据引擎需高可用

五、为什么最终选择 BOS + Fluid + JuiceFS？

最终选择逻辑可以归纳为四点：

  1. 成本优先：BOS 标准存储约 0.119 元/GB/月，远低于 CFS 容量型约 0.35 元/GB/月、PFS 约 1.45 元/GB/月。编译制品生命周期短，放在 BOS 上成本最可控。
  2. RWX 由 JuiceFS 补齐：BOS 原生 CSI 不支持 RWX，但 JuiceFS 提供完整 POSIX 文件系统语义，可以创建 ReadWriteMany PVC。
  3. Fluid 已有 BOS 挂载：Fluid 本身需要挂载自有 Bucket，制品中转继续使用 BOS，可以统一数据后端、权限和运维体系，减少数据搬运。
  4. 性能足够：编译制品中转不是数据库事务场景，不需要 PFS 级亚毫秒延迟。Fluid 的缓存层可以缓解 BOS 访问延迟，JuiceFS 的顺序读写能力也优于直接使用 s3fs 等简单挂载方案。

六、架构示意

 1┌─────────────────────────────────────────────┐
 2│ Kubernetes 集群                              │
 3│                                             │
 4│  编译 Pod     打包 Pod     测试 Pod           │
 5│     │            │           │              │
 6│     └────────────┴───────────┘              │
 7│              RWX PVC                        │
 8│                 │                           │
 9│          JuiceFS CSI / Fluid                │
10│                 │                           │
11│           JuiceFS 文件系统层                 │
12│          （元数据引擎 + 缓存）                │
13│                 │                           │
14└─────────────────┼───────────────────────────┘
15                  │
16            百度云 BOS Bucket
17          （编译制品持久化后端）

在这个架构中，BOS 是最终持久化层，JuiceFS 提供文件系统语义和 RWX，Fluid 负责 Runtime 管理和缓存加速。

七、需要注意的边界

这个方案不是没有代价，落地时需要关注：

  1. 元数据引擎必须高可用：JuiceFS 依赖 Redis、MySQL 或 TiKV 等元数据引擎。元数据引擎的可用性直接决定文件系统可用性，生产环境需要做高可用部署和监控。
  2. 写入延迟高于本地盘：写入路径需要经过 JuiceFS 元数据引擎再到 BOS，延迟高于本地文件系统。编译制品中转可以接受，但不适合对写延迟极敏感的场景。
  3. 小文件元数据操作需要观察：BOS 是对象存储，海量小文件的列表、属性获取等元数据操作可能成为瓶颈。如果编译制品以小文件为主，需要关注 JuiceFS 元数据引擎的性能和容量。
  4. 制品清理策略：编译制品生命周期短，建议结合 BOS 生命周期规则或定时任务清理过期制品，避免无用数据长期占用容量。
  5. 缓存容量规划：Fluid 缓存可以提升读性能，但缓存不是无限大。需要根据活跃制品规模规划缓存资源，避免缓存频繁淘汰。
  6. 权限与安全：BOS 的 Access Key/Secret Key 通过 Kubernetes Secret 管理，避免明文写入配置。

八、结论

经过 CDS、CFS、PFS、BOS 的对比，以及 BOS 原生 CSI、Fluid + JuiceFS + BOS、RapidFS 等方案的评估，结论是：

BOS 作为后端存储已经足够满足编译制品中转需求。 它成本低、弹性好，并且与 Fluid 已有的 BOS Bucket 挂载体系一致。BOS 原生 CSI 不支持 RWX 的问题，通过 Fluid + JuiceFS + BOS 组合解决：JuiceFS 提供 RWX 文件系统语义，Fluid 提供 Kubernetes 原生管理和缓存加速，BOS 承担低成本持久化。

对于编译制品中转这种“共享访问、成本敏感、性能要求适中、生命周期短”的场景，这是一条技术上成立、成本上合理、与现有 BOS 生态契合的落地路径。

参考链接