RustFS 1.0 GA 前的生产验收清单：从 rc.1 到 GA 该准备什么

问题背景：评估 RustFS 上生产，rc.1 到底到了哪一步
版本固定：为什么 rc 阶段必须锁版本号
S3 客户端兼容矩阵：迁移前先验证这 6 个行为
安全基线：密钥、RPC 秘密与 TLS
分布式拓扑：纠删码故障域怎么规划
总结与下一步：上线前照着这张清单过一遍

1. 问题背景：评估 RustFS 上生产，rc.1 到底到了哪一步

一支存储团队决定把某类数据从公有云 S3 迁回自建，或者给 AI 训练管线找一块 S3 兼容的本地存储，往往会把 RustFS 放进候选。我最近帮两个团队做选型，他们问的不是"能不能跑"，而是"rc.1 能不能上生产、上线前我该验收什么"。这个问题问得对------候选发布版本和 GA 之间的差距，要靠一份清单去填，而不是靠热度去赌。

RustFS 1.0.0-rc.1 在 2026-08-08 发布，单这一版就合入了 200 多个 PR。最值得 production 关注的不是某个炫酷旗舰特性，而是它把 KMS 从"能用"推到了"生产就绪"：三种后端（local、Vault、AWS KMS）、fail-closed 密钥处理、按密钥授权与可审计。对一个要承载真实数据的存储系统来说，这些"无聊"的组件才是 1.0 的底座。官方路线图指向 9 月中旬 GA，所以现在正是把 staging 集群搭起来、把验收流程跑顺的窗口期。

2. 版本固定：为什么 rc 阶段必须锁版本号

rc 仍然是预发布。RustFS 的容器镜像默认 tag 是 latest，但任何一个要上生产的部署，第一件事就是把它换成固定版本。我习惯在 values 或 compose 里直接钉死：

yaml 复制代码

image:
  repository: rustfs/rustfs
  tag: "1.0.0-rc.1"   # 不要写 latest，rc 阶段固定版本号，升级前先备份

固定版本号带来两个好处：一是回滚路径清晰，出问题能精确回到上一个已知状态；二是复现问题时有锚点，你报 issue 时能说清"我跑的是 rc.1"，而不是"某个最新版"。升级路径上，rc.1 之后到 GA 可能还有几个 rc，每个 rc 主要修稳定性问题，所以建议的策略是：先在次要业务、读多写少、可丢失重算的数据上跑 rc.1 攒经验，等关键环节再随 GA 推进。

中性边界：RustFS 容器以非 root 的 UID/GID 10001 运行，挂载的数据目录必须让这个 UID 能读写（chown -R 10001:10001 /data）。这是一个容易被忽略、却会导致启动即权限拒绝的点，和"稳不稳"无关，是部署成熟度的基本功。

3. S3 客户端兼容矩阵：迁移前先验证这 6 个行为

"100% 兼容 S3"不等于"我的客户端无差别能跑"。我见过最典型的坑：业务只验证了一次上传下载就切流量，结果预签名 HEAD、分页列举、版本控制这些边缘行为在生产里才炸。迁移前，我建议用下面这张矩阵把常用客户端逐个过一遍：

矩阵覆盖的行为：建桶、上传下载、预签名 URL（GET/HEAD）、ListObjectsV2 分页、版本控制、对象锁定。每一条都用你真实在用的 SDK 版本跑，而不是用 mc 替你下结论。RustFS 走 S3 兼容路线，业务代码通常零改动，但版本老到不发出 s3v4 签名的客户端要单独点一下。

一个可照做的验证骨架：

bash 复制代码

mc alias set rustfs http://10.0.0.10:9000 $ACCESS_KEY $SECRET_KEY
mc mb rustfs/verify-bucket
mc cp ./sample.bin rustfs/verify-bucket/sample.bin
mc ls rustfs/verify-bucket
mc share download rustfs/verify-bucket/sample.bin --expire 24h

4. 安全基线：密钥、RPC 秘密与 TLS

上生产前，三件事必须做掉。第一，改掉默认凭证 rustfsadmin/rustfsadmin，用 openssl rand -base64 24 生成强 Access/Secret Key。第二，多节点部署必须显式设 RUSTFS_RPC_SECRET------beta.10 之后，旧的 RUSTFS_SECRET_KEY=rustfsadmin 必须额外配一个 RUSTFS_RPC_SECRET 才能正常起节点间 RPC，否则节点间通信用可被预测的密钥。第三，启用 TLS 1.2+，用反向代理（Nginx）兜住 9000/9001，别把存储节点直曝公网。

bash 复制代码

export RUSTFS_VOLUMES="http://node1:9000/data,http://node2:9000/data,http://node3:9000/data,http://node4:9000/data"
export RUSTFS_ACCESS_KEY=$(openssl rand -base64 12)
export RUSTFS_SECRET_KEY=$(openssl rand -base64 24)
export RUSTFS_RPC_SECRET=$(openssl rand -base64 24)   # 多节点必须，节点间 RPC 鉴权
rustfs server /data --console-address ":9001"

KMS 已经是生产就绪状态，如果你要静态加密，优先用 Vault 后端集中管密钥；也可以先设桶默认加密，但要记住一个边界：KMS 不可用时加密写会失败（fail-closed），写不进去好过明文落盘。上线前务必先验证一次加密读写，别等真实数据来了才发现。

5. 分布式拓扑：纠删码故障域怎么规划

RustFS 分布式的写法是把所有节点端点写进同一个 RUSTFS_VOLUMES，没有"开集群"的开关变量。底层严格用纠删码（EC），默认 4 数据 + 2 校验（4+2），丢两块盘可重建，开销远低于 3 副本。这里要规划的是故障域：EC set 里的盘应尽可能跨节点、跨机架分布，否则同一机架断电就可能一次掉超过容错上限的盘。

我给客户的建议是：先按"能容忍同时坏几块盘"反推拓扑，再决定节点数和每节点盘数。比如 4 节点 × 4 盘做 EC，单 set 4+2，容 2 盘；要更稳就加到 6 节点或更高 parity 配比。换盘重启后，RustFS 的 auto-healing 会自动重建缺失分片，运维面该有的故障域规划一个都不少。

6. 总结与下一步：上线前照着这张清单过一遍

把上面几节压成一张动作清单，上线前逐项打勾：

镜像 tag 钉死 1.0.0-rc.1，不写 latest；升级前先备份数据。
数据目录 chown -R 10001:10001，否则容器非 root 起不来。
用真实 SDK 跑完兼容矩阵 6 项，预签名 HEAD 单独验。
改默认密钥；多节点显式设 RUSTFS_RPC_SECRET；9000/9001 走 Nginx + TLS。
分布式所有端点写进同一个 RUSTFS_VOLUMES，EC set 跨故障域分布。
要加密就先验证一次 KMS 读写，确认 fail-closed 行为符合预期。

GA 在即，现在搭 staging、跑通这份清单，等 9 月中旬 GA 一到就能平滑推进。想先动手，从官方文档的 Helm/Compose 模板起一个单机评估最省事；真要上分布式，按上面的故障域思路先把节点数定下来。RustFS 的仓库在这：https://github.com/rustfs/rustfs ，边跑边提 issue，比看十篇通稿都实在。

深入学习 RustFS ：RustFS

技术文档： RustFS 技术文档- 提供架构、安装指南和 API 参考。

GitHub 仓库： GitHub 仓库 - 获取源代码、提交问题或贡献代码。