4. 环境准备
在部署MinIO存储集群之前，必须确保底层Kubernetes环境满足最低资源与版本要求，并完成Helm包管理工具、kubectl命令行工具以及存储类(StorageClass)的配置。本章将逐一梳理这些前置条件，避免后续部署因环境不一致而失败。
4.1 Kubernetes集群最低要求
MinIO Operator与分布式MinIO集群对Kubernetes版本、节点资源及网络插件有明确要求。下表列出了生产环境推荐的最低配置：
| 类别 | 最低要求 | 生产推荐 |
|---|---|---|
| Kubernetes版本 | v1.21+ | v1.27+ |
| 工作节点数量 | 3 节点 | 4+ 节点（跨可用区） |
| 每节点CPU | 2 核 | 4+ 核 |
| 每节点内存 | 4 GB | 8+ GB |
| 每节点本地磁盘 | 20 GB（系统盘） | 100+ GB（数据盘） |
| CNI网络插件 | Calico / Flannel / Cilium | Cilium（支持NetworkPolicy） |
| 存储后端 | 支持ReadWriteMany的StorageClass | NVMe SSD + 分布式文件系统 |
⚠ 版本兼容性提示： 如果使用Kubernetes v1.24及以下版本，MinIO Operator v5.x可能无法正常工作。建议在部署前查阅MinIO官方兼容性矩阵，确保Operator版本与集群版本匹配。
4.2 Helm安装与配置
Helm是Kubernetes的包管理工具，用于简化MinIO Operator的安装与升级。以下步骤适用于Helm v3.x版本：
- 下载Helm二进制文件：从官方GitHub Release页面获取最新稳定版。
- 安装Helm：将二进制文件移动到
/usr/local/bin/并赋予执行权限。 - 验证安装：执行
helm version确认版本信息。 - 添加MinIO Helm仓库：
helm repo add minio https://operator.min.io/ - 更新仓库索引：
helm repo update
# 安装Helm v3（以Linux amd64为例）
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
# 验证版本
helm version --short
# 添加MinIO官方仓库
helm repo add minio https://operator.min.io/
helm repo update
💡 离线环境安装： 如果集群无法访问外网，可先在有网络的机器上下载Helm二进制及MinIO Chart包（
helm pull minio/operator），再通过scp或挂载方式传输到集群节点。
4.3 kubectl配置与集群访问验证
kubectl是与Kubernetes API Server交互的命令行工具。配置kubeconfig文件后，需验证集群连通性与权限：
| 验证项 | 命令 | 预期输出 |
|---|---|---|
| 节点状态 | kubectl get nodes |
所有节点状态为 Ready |
| 集群版本 | kubectl version --short |
Server Version 显示集群版本 |
| 命名空间列表 | kubectl get ns |
至少包含 default、kube-system |
| 存储类列表 | kubectl get sc |
显示已配置的StorageClass名称 |
| RBAC权限 | kubectl auth can-i create deployment |
yes |
# 设置kubeconfig路径（默认 ~/.kube/config）
export KUBECONFIG=/path/to/your/cluster-config.yaml
# 验证集群连通性
kubectl cluster-info
# 检查节点状态
kubectl get nodes -o wide
# 检查当前上下文
kubectl config current-context
🔑 多集群管理： 如果同时管理多个Kubernetes集群，建议使用
kubectx 工具快速切换上下文，或通过 kubectl config use-context <context-name> 手动切换。
4.4 存储类(StorageClass)准备
MinIO分布式集群需要持久化存储来保存对象数据。StorageClass定义了动态制备PV的存储后端类型、回收策略及挂载参数。对于MinIO，推荐使用支持 ReadWriteMany (RWX) 访问模式的存储类，以便多个Pod同时读写同一卷。
4.4.1 存储类对比与选择
| 存储后端 | 访问模式 | 性能 | 适用场景 |
|---|---|---|---|
| NFS (nfs-csi) | RWX | 中等 | 跨节点共享卷，适合MinIO纠删码 |
| CephFS (csi-cephfs) | RWX | 高 | 大规模生产集群，支持快照 |
| Longhorn | RWO / RWX | 高 | 本地存储聚合，适合边缘部署 |
| Local Path Provisioner | RWO | 极高 | 单节点测试或开发环境 |
| 云厂商块存储 (EBS/PDD) | RWO | 高 | 云原生环境，需配合StatefulSet |
4.4.2 创建自定义StorageClass（以NFS CSI为例）
如果集群中没有现成的RWX存储类，可以手动创建一个使用NFS CSI驱动的StorageClass：
# nfs-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-csi-minio
provisioner: nfs.csi.k8s.io
parameters:
server: 192.168.1.100 # NFS服务器IP
share: /exported/path # NFS导出路径
csi.storage.k8s.io/provisioner-secret-name: nfs-secret
csi.storage.k8s.io/provisioner-secret-namespace: default
reclaimPolicy: Retain
volumeBindingMode: Immediate
mountOptions:
- hard
- nfsvers=4.1# 应用StorageClass
kubectl apply -f nfs-storageclass.yaml
# 验证StorageClass已创建
kubectl get sc nfs-csi-minio -o yaml
⚠ 存储类选择关键点： MinIO Operator在创建租户(Tenant)时，如果指定了
requestAutoCert: false 且使用RWX存储类，则所有MinIO Pod可以共享同一组PV，简化运维。如果使用RWO存储类，则每个Pod需要独立的PV，且必须通过StatefulSet管理。
4.5 环境准备总览图
下图展示了从底层基础设施到上层MinIO部署的完整环境依赖关系：
4.6 环境验证清单
在进入下一章之前，建议逐项核对以下清单，确保所有前置条件均已满足：
- ☑ 集群版本：
kubectl version --short输出中Server Version ≥ v1.21 - ☑ 节点健康：所有节点
Ready，且无NotReady或DiskPressure异常 - ☑ Helm安装：
helm version显示v3.x，且helm repo list包含minio仓库 - ☑ kubectl权限：当前用户具有创建Namespace、Deployment、PVC、StorageClass的权限
- ☑ StorageClass就绪：至少有一个支持RWX的StorageClass，且
kubectl get sc显示其PROVISIONER正确 - ☑ 网络连通性：节点之间可以互相通信，且DNS解析正常（
kubectl run test --image=busybox -- nslookup kubernetes.default）
✅ 快速自检脚本： 可以将上述验证命令写入一个Shell脚本，一键执行并输出通过/失败状态，避免手动逐条检查遗漏。