背景

在当今云原生架构快速发展的背景下，对象存储作为一种弹性、高可用、成本可控的存储方式，广泛应用于日志存储、备份恢复、机器学习、媒体资源管理等场景。而在众多对象存储方案中，MinIO 由于其兼容 Amazon S3 协议、高性能、开源轻量的特性，成为企业在私有云乃至混合云环境中部署对象存储的首选。

容器化挑战

随着云原生基础设施的发展，企业越来越多地将对象存储系统纳入 Kubernetes 环境中统一管理。相比传统部署方式，将 MinIO 进行容器化部署具有显著优势：

• ✅ 更容易实现弹性伸缩、资源隔离和多租户；

• ✅ 便于与平台的监控、网络、安全策略集成；

• ✅ 更适合 DevOps、CI/CD 流水线式部署与升级；

• ✅ 利于统一的生命周期管理、自动化运维。

MinIO 本身天然支持容器化部署，并提供了官方容器镜像与 Helm Charts。社区也发布了 MinIO Operator，意在通过 CRD 和 Operator 实现更标准化的部署与管理方式。然而，在实际的企业级使用中，MinIO****的官方容器化方案仍面临一些关键问题，主要包括：

1. 配置复杂，手动维护成本高 MinIO 分布式部署要求在启动参数中显式列出所有节点地址，且节点顺序敏感。每次节点变更（如扩容、重部署）都需要手动修改地址列表。这一方式在 Kubernetes 中极不友好，不利于自动化部署和动态运维。

2. 水平扩容受限 MinIO 原生的集群节点数在初始化时即固定，后续无法通过简单地增加 Pod 或节点来实现扩容。如需扩容，必须重新部署整个集群或手动拼接新的 Server Pool，增加了系统复杂度和运维风险。

3. 生命周期管理能力薄弱尽管官方 Operator 提供了一些基础的 CRD 能力，但缺乏统一的生命周期管理规范，诸如版本升级、参数变更、备份恢复、状态探测等依然需要依赖手动操作或外部脚本，难以纳入平台运维体系中统一管理。

在社区用户的强烈要求下，KubeBlocks 支持了 MinIO Addon，以下是使用和实现细节的介绍。

MinIO Addon 实现

本节介绍如何实现 MinIO 集群管理、高可用、水平扩容等功能。

集群管理

实现如下接口，即可在 KubeBlocks 中实现对 MinIO 集群的基本生命周期管理和运维：

• ComponentDefinition：定义某个服务组件的基本特征，包括容器模板、探针、挂载点、服务端口等。它相当于组件的“模具”或“零件图纸”，决定了集群每个组件的运行行为。

• ComponentVersion：为上述组件定义具体的版本支持，包括镜像地址、版本别名、参数模板等。它描述了“某个零件”的不同版本及其属性。

接下来主要介绍 MinIO ComponentDefinition 的实现。

• roles：定义 MinIO 集群的副本角色，有两种，readwrite和notready
  

 roles: - name: readwrite updatePriority: 1 participatesInQuorum: false - name: notready# a special role to hack the update strategy of its updatePriority: 1 participatesInQuorum: false

• services：定义两个对外提供的 Service，一个指向 MinIO 的 api，提供对象存储服务，一个指向 MinIO 的 console，提供 MinIO 管理功能。

 services: - name: default spec: ports: - name: api port: 9000 targetPort: api - name: console port: 9001 targetPort: console

• systemAccounts：定义内置账号 root ，及其密码生成策略， KubeBlocks 会将对应账号和密码信息生成到对应 secret 中。

 systemAccounts: - name: root initAccount: true passwordGenerationPolicy: length: 16 numDigits: 8 letterCase: MixedCases

• vars：定义一些变量，如 MinIO ``_ROOT_USER表示 MinIO 的管理员账号名称， MinIO ``_ROOT_PASSWORD表示 MinIO 的管理员账号密码等，这些变量最终会以环境变量的形式渲染到 Pod 中。

 vars: - name: MinIO _ROOT_USER valueFrom: credentialVarRef: name: root optional: false username: Required - name: MinIO _ROOT_PASSWORD valueFrom: credentialVarRef: name: root optional: false password: Required

• lifecycleActions：定义一些生命周期相关的动作， MinIO 实现了一个 Action：

• roleProbe：用于探测副本角色

lifecycleActions:roleProbe:exec:command:- /bin/sh- -c- |if mc config host add MinIO http://127.0.0.1:9000 $ MinIO _ROOT_USER $ MinIO _ROOT_PASSWORD &>/dev/null; thenecho -n "readwrite"elseecho -n "notready"fi

• runtime：定义容器运行时相关的配置，包括两个容器：

• init：初始化 MinIO _REPLICAS_HISTORY，并保存到 Configmap 中，用于 MinIO 水平扩容使用（稍后在讲）。

• MinIO ： MinIO 服务运行容器

runtime:initContainers:- name: initcommand:- /bin/sh- -ce- /scripts/replicas-history-config.shcontainers:- name: MinIO command:- /bin/bash- -c- /scripts/startup.sh

到此一个基本的 MinIO Addon 就基本完成了，完整实现可见link。

高可用

MinIO 原生通过分布式部署实现高可用，其核心机制是将多个节点组成统一的集群，配合 Erasure Coding（纠删码）技术对数据进行切片与冗余编码，确保在部分节点或磁盘故障的情况下依然能够读写数据。任意节点都可接收客户端请求，系统具备自动恢复能力，同时保持严格一致性，整体架构无单点故障，具备强健的服务高可用能力。因此，为确保高可用性 MinIO 要求至少 4 个节点，并推荐使用偶数节点（如 4、6、8、16）以实现数据冗余均衡。

水平扩容

为突破 MinIO 原生节点数固定的限制， KubeBlocks 在 ComponentDefinition 中设计并实现了一套自动化的水平扩容机制。该方案通过组合使用 initContainer 和 ConfigMap，记录并维护每次副本数变化的历史信息，在容器启动时动态构造对应的 Server Pool 地址，从而实现多阶段副本的持续管理与拼接。

扩容过程核心逻辑如下：

1. 记录副本历史（replica history）：在 initContainer 中读取并维护一个名为MinIO ``_REPLICAS_HISTORY 的 ConfigMap 键值。该值记录了每次副本数变更的历史，例如：[4,8,16]，代表集群经历了 3 次扩容，每次扩容后集群的节点总数。示例逻辑如下：

key=" MinIO _REPLICAS_HISTORY"cur=$(kubectl get configmaps "$name" -n "$namespace" -o jsonpath="{.data.$key}")...new="[$cur,$KB_COMP_REPLICAS]"kubectl patch configmap "$name" -n "$namespace" --type strategic -p "{\"data\":{\"$key\":\"$new\"}}"

1. **构建多个 Server Pool 地址段:**在主容器（ MinIO ）启动参数中，读取历史副本变化，逐段生成对应的 Server Pool 地址。例如：

for ((i=0; i < ${#replicas[@]}; i++)); doif [ $i -eq 0 ]; thencur=${replicas[i]}server+="{{ $scheme }}:// MinIO -{0...$((cur-1))}. MinIO -headless.$namespace.svc/data"elseprev=${replicas[i-1]}cur=${replicas[i]}server+=" {{ $scheme }}:// MinIO -{$((prev))...$((cur-1))}. MinIO -headless.$namespace.svc/data"fidone

通过维护副本历史并自动生成多段 Server Pool 地址， KubeBlocks 成功绕过了 MinIO 原生集群节点数固定的限制，实现了逻辑上的水平扩容，并保持集群的连续可用与数据一致性。

MinIO 集群管理实践

现在让我们部署一个 MinIO 集群，并执行一些运维变更操作。

部署集群

# 添加helm repohelm repo add KubeBlocks https://apecloud.github.io/helm-charts# 安装 MinIO addonhelm install MinIO KubeBlocks -addons/ MinIO --version 0.9.1# 创建 MinIO clusterhelm install MinIO -cluster KubeBlocks -addons/ MinIO -cluster --version 0.9.1 --set replicas=2

查看集群和 pod 的状态

水平扩容

# 扩容节点数到4kbcli cluster hscale MinIO -cluster --replicas 4 --components<u>MinIO </u># 重启集群，让旧节点可以感知到新的server poolkbcli cluster restart MinIO -cluster

查看集群和 pod 的状态

可视化界面

MinIO 在容器运行时自带 Web 控制台（ MinIO Console），用于后台管理和可视化操作。该控制台默认监听在 9001 端口，并支持以下功能：

• Bucket 和对象管理（上传、浏览、删除、设置策略）

• 用户与访问密钥管理

• 服务运行状态监控（磁盘使用、节点状态、访问日志等）

• 支持界面化配置 IAM 策略、生命周期策略等

在 KubeBlocks 中， MinIO Console 被作为组件 services 中的一个端口暴露出来，用户可通过 NodePort、LoadBalancer 或 Ingress 的方式访问。示例如下：

# 暴露端口kubectl port-forward MinIO -cluster- MinIO -1 9001:9001

然后在浏览器中打开http://localhost:9001/login即可。

其它操作

以 Addon 形式介入 KubeBlocks 后，天然支持了很多集群运维操作。除了上述介绍的水平扩容外，还支持以下操作：

• 垂直扩容，增加集群 cpu 或 memory

• 集群重启、停止和删除

• 小版本升级

• 监控（配置 Prometheus exporter 采集指标）

• 参数配置，修改集群参数

总结与展望

在云原生环境中运行 MinIO 同样面临部署复杂、扩容受限、运维繁琐等挑战。KubeBlocks 作为面向有状态服务的开源 Kubernetes Operator，通过模块化的 MinIO Addon 实现了集群部署自动化、服务高可用、Server Pool 弹性扩容等能力，有效提升了 MinIO 的容器化体验。尽管如此， MinIO 在动态扩容灵活性、生态兼容性等方面仍有优化空间。我们也将持续打磨相关能力，助力 MinIO 成为云原生场景下更具竞争力的分布式存储解决方案。