不能用裸StatefulSet硬编码节点地址，因为MinIO分布式启动要求所有节点动态发现彼此，而硬编码地址导致扩容需重建StatefulSet、节点重调度后握手失败、args无法参数化、不支持故障剔除与拓扑重平衡。
生产环境必须用分布式集群模式，单节点只适合本地验证；直接写死节点地址的 StatefulSet 配置无法扩容、不能滚动升级，容易卡在维护阶段。
为什么不能用裸 StatefulSet 硬编码节点地址
MinIO 分布式启动要求所有节点能动态发现彼此，传统 StatefulSet 中把地址写成 http://minio-0.minio.svc.cluster.local:9000/data 这类固定字符串，会导致：
- 扩容时必须重建整个
StatefulSet，因为新 Pod 的 DNS 名不在原列表里 - 任意节点重启或重调度后，其他节点仍尝试连接旧 IP，握手失败，集群 hang 住
-
args字段无法参数化，不同副本要靠模板生成 YAML，CI/CD 难以收敛 - 不支持自动故障剔除和纠删码拓扑重平衡
Operator 模式是唯一可运维的选择
MinIO 官方推荐且生产就绪的方式是通过 MinIOOperator 管理租户（Tenant），它把集群生命周期抽象为 CRD：MinIOCluster。Operator 自动处理：
- 节点发现：基于 Kubernetes Headless Service + EndpointSlice 动态构建服务器列表
- 配置同步：Secret 更新后自动 reload 控制台和 root 凭据
- 滚动升级：逐个替换 Pod，保持
read/write quorum不中断 - 存储绑定：校验 PVC 是否满足
ReadWriteOnce，拒绝挂载共享卷
部署 Operator 本身只需一条命令：kubectl apply -k "github.com/minio/operator?ref=v5.0.18"（注意：必须用 kubectl kustomize 或 kubectl -k，不能混用 Helm）。
PV 必须独占、格式化为 XFS、回收策略设为 Retain
MinIO 对底层存储有强约束，违反会导致静默数据损坏：
- 每个 PV 必须由单个 MinIO Pod 独占使用，禁止多个 Pod mount 同一个 PV
- 强烈建议用
DirectPVCSI 驱动管理裸盘，避免中间文件系统层干扰 - 如果用云盘（如 AWS EBS、Azure Disk），需确保底层格式化为
XFS（非 ext4），否则大对象写入性能断崖下跌 - PVC 的
storageClassName对应的 StorageClass 必须设置reclaimPolicy: Retain，防止误删 PV 导致数据清空
错误示例：reclaimPolicy: Delete —— 删除 PVC 后自动销毁 PV，不可逆。
Service 类型选 LoadBalancer 还是 NodePort 取决于网络边界
MinIO 需暴露两个端口：9000（S3 API）和 9001（Web Console）。选择依据很实际：
- 公有云（EKS/GKE/AKS）：直接用
type: LoadBalancer，云厂商自动分配公网 IP 或内网 VIP - 私有云 / 机房：若已有 Ingress Controller（如 Nginx、Traefik），则 Service 设为
ClusterIP，再配 Ingress 路由到/和/minio/ - 测试环境：用
NodePort最快，但需确认节点防火墙放行30000–32767端口段
别忽略 console 端口：MINIO_CONSOLE_ADDRESS 环境变量必须显式设为 :9001，否则控制台会尝试绑定到 localhost，Pod 内无法访问。
