8.1 Kubernetes 上的 MinIO：Operator 与租户

8.1 Kubernetes 上的 MinIO：Operator 与租户

本节摘要：在 Kubernetes 上跑 MinIO,正确的姿势不是手写 StatefulSet,而是用官方 Operator 声明一套"租户"（Tenant）:节点数、盘数、纠删配置、TLS 全部写进 YAML,Operator 负责拉起、扩容与修复。本节讲清租户模型的隔离边界与存储卷的规划要领。

为什么不直接写 StatefulSet

K8s 老手的第一个念头往往是"MinIO 不就是个 StatefulSet 加 PVC 吗"。能跑，但你会亲手重新发明 Operator 已经解决的问题：纠删集拓扑的编排（哪几个卷属于哪个池）、节点级反亲和（同一纠删集的盘要散在不同宿主机）、域名编址（MinIO 集群要求每节点稳定的主机名语义）、在线扩池、证书轮换。这些细节每一个都有坑，Operator 把它们固化成了经过大量生产验证的控制器逻辑。把复杂性交给 Operator,把规划责任留给自己——这是本节的立场。

租户模型：隔离的单位

Operator 的核心抽象是租户：一套 MinIO 集群（含全部池）在 K8s 里的化身。隔离的边界划在租户上——每个租户独立的凭证体系、独立的桶空间、独立的 TLS 证书、独立的资源配额。平台团队的常见布局是按业务域分租户：数据平台一个、备份归档一个、开发测试一个，租户之间互不可见，管理面统一。

一份最小可用的租户声明长这样：

apiVersion: minio.min.io/v2
kind: Tenant
metadata:
  name: data-platform
  namespace: minio-tenant
spec:
  pools:
    - servers: 4
      volumesPerServer: 4
      volumeClaimTemplate:
        metadata:
          name: data
        spec:
          storageClassName: local-nvme
          resources:
            requests:
              storage: 4Ti
      tolerations: [...]
      nodeSelector:
        storage-node: "true"
  requestAutoCert: true
  users:
    - name: backup-svc
​

三处与裸机部署（第 2 章）的对应关系值得点破：servers 加 volumesPerServer 就是"四节点每节点四盘"；storageClassName: local-nvme 对应"直通专用盘"——租户的池必须绑定本地持久卷（Local PV）,网络存储类（Ceph RBD、云盘）会把延迟与可用性问题请回数据路径，重蹈 4.2 讨论过的覆辙；nodeSelector 把租户钉在存储节点池上，与计算负载隔离，这是"存储节点不混部"纪律在 K8s 里的表达。

图 8-1 租户在 Kubernetes 中的层次栈

K8s 环境的三个特有注意点

注意点一：故障域从"机房"变成"节点与可用区"。 纠删集的分片打散在 Operator 里通过反亲和规则落到不同节点；跨可用区的集群要配拓扑分布约束，让分片不与某个可用区同生共死——2.2 的"打散"逻辑在这里多了一层 K8s 语义。

注意点二：扩池走声明变更。 4.3 的在线扩容在 K8s 里的表达是往租户的 pools 数组追加一个池，Operator 完成拉起与加入，滚动与验收逻辑不变——模型没变，只是"改配置文件滚动重启"变成了"改 CR 等控制器收敛"。

注意点三：别让 K8s 的自动行为伤害存储语义。 节点自动扩缩容可能回收"看起来闲置"的存储节点，Pod 驱逐策略可能把 MinIO 进程当成普通负载调度搬家。存储节点池打污点、Pod 加对应的容忍与 PDB（中断预算），把存储的稳定性权重显式告诉调度器。

案例：一次迁移的取舍

背景：第 4 章扩容后的双池裸机集群，平台组要求统一迁入 K8s。

操作：评估后团队没有迁移存量集群，而是并行新建 K8s 租户，用 mc mirror 全量同步历史数据，业务双写两周后切读，裸机集群按 4.3 的退役流程下线。迁移期间借机把纠删配比从对半分调到 10+6（数据重写带来的免费优化窗口）。

结果：迁移窗口六周，业务无感，新租户与监控链路（下一节）一体化交付。

解读：不迁存量而重建同步，是存储上云的常见最优解——K8s 里"搬裸机数据目录"没有干净的路，而对象存储天生适合 mirror 同步。配比调整搭迁移顺风车，则把一次纯运维项目变成了顺手优化。

变式：开发测试租户可以激进得多——单池四节点缩成单节点多盘，存储类用廉价盘，因为它的使命是验证流程而非承载数据。生产租户的纪律一条不能少。

本节要点回顾

• Operator 优先：StatefulSet 手搓会重新发明拓扑编排、反亲和与证书管理，且更脆。
• 租户是隔离单位：按业务域分租户，凭证、桶空间、证书各自独立。
• 本地持久卷是底线：网络存储类会摧毁对象存储的延迟与一致性前提。
• 扩池即改声明：4.3 的扩容模型原样适用，滚动与验收逻辑不变。

集群住进了 K8s,接下来让它学会喊疼。下一节搭监控告警链路。

集群上云后的三个疑问

Operator 与租户的版本升级怎么做？

顺序是先升 Operator、再滚动租户实例：Operator 兼容旧版本的租户声明，反向则不保证。租户升级按池滚动进行，升级窗口的选择与裸机时代相同——避开业务高峰，升级前后各跑一轮读写探活。把"Operator 先行"记成铁律，可以避开绝大多数升级期异常。

存储类建错了能换吗？

不能就地更换。卷的存储类在创建时绑定，错配的解法与 8.1 案例同构：新建正确的池或租户，mirror 同步，旧池退役。K8s 的声明式把"换存储类"变成了"换基础设施"，理解这一点就会在建租户前认真核对存储类清单——声明式系统的错误修复成本，全部前移到了声明的那一刻。

单个租户能长到多大？

Operator 支持的租户规模在数百节点级，远超绝大多数企业的需求。真正的上限通常先出现在 K8s 集群本身（节点规模、PV 数量、调度压力）与网络层。规划口径与裸机一致：按业务增量外推，按池为单位扩展，不要因为"在 K8s 里"就期待容量问题自动消失。

三问的共同答案是：K8s 改变了部署的表达方式，没有改变存储的物理规律。池模型、扩容纪律、备份策略在云原生世界里原样适用——理解了这一层，8.1 的所有 YAML 都只是第 2 章命令的另一种拼写。