跳转到主要内容

这是本节的多页打印视图。 .

返回本页常规视图.

部署与升级

选择部署方式，安装 SILO，并按实际组件版本安排升级。

选择部署方式，安装 SILO，并按实际组件版本安排升级。

继承的 MinIO Operator 指南不构成对任意上游版本的发布验收承诺。正式维护组合为 SILO、SILO Console、mcli 和 silo-pkg；上游兼容性尽最大努力提供。

1 - MinIO Kubernetes Operator

Silo 是兼容 S3 的对象存储。MinIO Operator 是上游 Kubernetes 组件，其仓库已于 2026-03-20 归档并设为只读。最后一个版本 v7.1.1 可以通过 Tenant CRD 管理 Silo 服务端镜像。Operator 名称、API 组、CRD kind、资源名、镜像名和环境变量都属于上游契约，因此不在此改名。

MinIO Operator 会安装 Custom Resource Definition (CRD)，其中包括用于把托管对象存储工作负载描述为 Kubernetes object 的 Tenant kind。

固定的 v7.1.1 Kustomize 清单会在 minio-operator 命名空间部署一个 minio-operator Deployment，其中包含两个控制器副本；它不会部署独立的 Operator Console pod。

本站验证的是部署示例中的 Silo 镜像覆盖。归档后的 Operator 不再有持续的上游平台支持或商业支持承诺，本站也不会建立此类承诺。

上游 CRD 契约请参阅固定版本的 MinIO Operator v7.1.1 CRD Reference。

Operator 前提条件

Kubernetes 版本

归档的 v7.1.1 README 要求 Kubernetes 1.30.0 或更高版本。请选择仍在维护且 API 兼容的 Kubernetes 版本，并在自己的集群中验证精确组合。可参阅 受维护的 Kubernetes 版本 与 Operator v7.1.1 发布页；Silo 不另行声明更宽的平台支持矩阵。

如果 Kubernetes 基础设施运行的是生命周期已结束的 API 版本，在部署 Operator 时可能出现意料之外或不期望的行为。

Kustomize 和 kubectl

Kustomize 是一个基于 YAML 的模板工具，可让你以声明式、可重复的方式定义 Kubernetes 资源。 Kustomize 已内置在 kubectl 命令行工具中。

本步骤默认你的本地主机既安装了与 Kubernetes 集群版本匹配的 kubectl，也具备在该集群中创建新资源所需的访问权限。

固定版本的 MinIO Operator v7.1.1 Kustomize 模板 提供了可复现的起点。你可以修改该 Kustomization 文件，或应用自己的 patches 适配集群。不要推断还存在受支持的上游新版；任何分支或替代实现都必须独立审查。

Kubernetes TLS Certificate API

MinIO Operator 使用 Kubernetes certificates.k8s.io TLS certificate management API 管理 TLS Certificate Signing Requests (CSR)，并在以下场景中创建已签名的 TLS 证书：

MinIO Operator 会读取 operator-ca-tls secret 中的证书，并在 tenant 命名空间内同步该 secret，以信任私有证书颁发机构，例如使用 cert-manager 时的场景。

在上述任一场景下，MinIO Operator 都 要求 Kubernetes kube-controller-manager 的配置中包含以下 配置项：

  • --cluster-signing-key-file - 指定用于签发集群级证书的 PEM 编码 RSA 或 ECDSA 私钥。
  • --cluster-signing-cert-file - 指定用于签发集群级证书的 PEM 编码 x.509 Certificate Authority 证书。

Kubernetes TLS API 会使用 CA 的签名算法生成新证书。与 RSA 相比，ECDSA（例如 NIST P-256 curve）或 EdDSA（例如 Curve25519）通常需要更少的计算资源。Silo 服务端支持的套件请参阅 支持的 TLS Cipher Suite。

如果 Kubernetes 集群未配置为对生成的 CSR 作出响应，Operator 将无法完成初始化。 某些 Kubernetes 提供方默认不会指定这些配置值。

若要检查 kube-controller-manager 是否指定了集群签名密钥和证书文件，请使用以下命令：

kubectl get pod kube-controller-manager-$CLUSTERNAME-control-plane \
  -n kube-system -o yaml
  • 将 $CLUSTERNAME 替换为 Kubernetes 集群名称。

确认输出中包含高亮标出的行。 上例命令的输出可能与你终端中的实际输出不同：

 spec:
 containers:
 - command:
     - kube-controller-manager
     - --allocate-node-cidrs=true
     - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
     - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
     - --bind-address=127.0.0.1
     - --client-ca-file=/etc/kubernetes/pki/ca.crt
     - --cluster-cidr=10.244.0.0/16
     - --cluster-name=my-cluster-name
     - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
     - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
 ...
警告

重要

MinIO Operator 可以使用指定的 Certificate Authority (CA) 为 Tenant pod 生成 TLS 证书。Kubernetes 集群外部的客户端必须信任该 CA，才能连接到 Silo Tenant 端点。

禁用 TLS 校验仅适用于受控测试。生产客户端应信任签发 CA，或使用其本来就信任的 CA 所签发的证书。

另一种方式是生成由已知且受信任 CA 签发的 x.509 TLS 证书，并通过 Tenant CRD 提供这些证书。更完整的文档请参阅 网络加密（TLS）。

2 - 安装 Silo Server

请使用当前的 服务端制品 与本节的平台说明，在物理机或虚拟化主机上安装 Silo。可执行文件、服务、软件包与环境变量契约仍保留 MinIO 兼容名称。

3 - 安装与管理

Silo 部署拓扑与安装说明

本节介绍如何在 Kubernetes 和 裸机或虚拟化 基础设施上安装与管理采用 AGPLv3 许可的 Silo 对象存储服务端。

minio 可执行文件、MINIO_* 环境变量、S3 与 Admin API、盘上格式，以及 MinIO Operator 资源名都是兼容契约。叙述使用 Silo 品牌，命令和标识符则保留兼容名称。

Silo 是兼容 S3 的软件定义分布式对象存储服务端。下载页面 是当前已发布操作系统与架构制品的事实来源。

Silo 使用 纠删码 保护对象数据。你可以选择以下拓扑：

单机单盘 （SNSD，即”单机”模式）

适用于本地开发与评估，可靠性有限或无冗余

单机多盘 （SNMD，即”单机多盘”模式）

适用于对性能、规模和容量要求较低的工作负载

提供驱动器级可靠性，可配置为最多容忍 1/2 驱动器丢失

适合评估多驱动器拓扑和故障切换行为。

多机多盘 （MNMD，即”分布式”模式）

企业级高性能对象存储

提供节点/驱动器级可靠性，可配置为最多容忍 1/2 节点/驱动器丢失

可作为 AI/ML、分布式查询、分析及其他数据湖组件的主存储

可扩展到 PB+ 级工作负载，同时扩展存储容量与性能

Kubernetes

已经归档的 MinIO Kubernetes Operator v7.1.1 可以管理运行 Silo 服务端镜像的 Tenant 资源。Operator、Chart、CRD 与 Tenant Kind 保留上游名称；其上游发布周期现已冻结。

这些保留的 Operator 指南描述一份兼容快照。上游仓库已于 2026-03-20 归档，因此请根据 Kubernetes 发行版验证 v7.1.1，并将 Tenant 镜像覆盖为 pgsty/silo；Silo 项目不继承上游原厂商曾经的平台支持矩阵声明。

裸金属

Silo 可以运行在物理机、虚拟化主机或容器中。请查阅当前下载矩阵和各平台页面，确认已验证的制品与范围。

警告

重要

发布制品的存在不代表所有平台都有同等的生产验证范围。长期工作负载应优先使用经过测试的 Linux 或 Kubernetes 部署，固定确切的软件包/镜像版本，并根据所选拓扑验证存储、故障域、升级与恢复行为。

4 - 部署 Silo Tenant

本步骤说明如何使用 MinIO Operator v7.1.1 管理运行 Silo 服务端镜像的 Tenant。上游 Operator 仓库已于 2026-03-20 归档并设为只读，因此这是一份冻结的兼容基线，而不是仍在维护的 Operator 路径。MinIO Operator、Tenant、minio.min.io API 组以及 CRD 字段名属于上游 Kubernetes 契约，因此保留原名。

下文验证过的基线会创建一个四服务端 Tenant。单节点拓扑适合本地测试，但其生产故障模型与存储布局不在本文档覆盖范围内。

本文档默认你已经熟悉所有被引用的 Kubernetes 概念、工具和操作流程。 虽然本文档 可能 会以 best-effort 方式提供 Kubernetes 相关资源的配置或部署指导，但它不能替代官方 Kubernetes Documentation。

使用 Kustomize 部署 Silo Tenant

以下步骤使用 MinIO Operator v7.1.1 仓库 中的 base Kustomization 模板，然后将其中默认的上游 MinIO 镜像替换为固定版本的 Silo 镜像。

你也可以从 v7.1.1 的其他 示例 中选择起点，或者依据 MinIO Custom Resource Documentation 自行构建资源。上游没有更晚的受支持版本；离开此固定快照前，应独立审查任何分支、替代实现或 CRD 变化。

警告

重要

如果你使用 Kustomize 部署 MinIO Tenant，就必须使用 Kustomize 来管理或升级该部署。 不要使用 kubectl krew、Helm Chart 或类似方式来管理或升级该 MinIO Tenant。

本步骤并未穷尽 Tenant CRD 中的所有可配置项。 它只提供一个基线，你可以在此基础上按需修改和定制 Tenant。

  1. 为 Tenant 创建 YAML 对象

    克隆固定版本的 Operator，并使用 kubectl kustomize 生成一个 YAML 文件，其中包含部署 base Tenant 所需的全部 Kubernetes 资源：

    git clone --branch v7.1.1 --depth 1 https://github.com/minio/operator.git
kubectl kustomize operator/examples/kustomization/base > tenant-base.yaml

    该命令会创建一个单独的 YAML 文件，多个对象之间使用 --- 分隔。 请使用你偏好的编辑器打开此文件。

    上游模板默认使用 quay.io/minio/minio。应用前，请在 kind: Tenant 对象中把 spec.image 改为已验证的 Silo 版本，并关闭继承而来的原地更新器：

    spec:
  image: pgsty/silo:RELEASE.2026-09-03T13-18-01Z
  env:
    - name: MINIO_UPDATE
      value: "off"

    请按标签或摘要固定镜像。若选择更新的 Silo 镜像，应单独审查并测试该版本，而不是沿用 Operator 模板中的上游镜像。

    下文各步骤将根据对象的 kind 和 metadata.name 字段来引用这些对象：

  2. 配置 Tenant 拓扑

    kind: Tenant 对象用于描述由 MinIO Operator 管理的 Silo 工作负载。

    以下字段都带有 spec.pools[0] 前缀，用于控制 Tenant 中所有 pod 的 server 数量、每个 server 的卷数量以及存储类：

    字段

    描述

    servers

    要在服务器池中部署的 Silo pod 数量。

    volumesPerServer

    每个 Silo pod（servers）要挂载的持久卷数量。 Operator 会为该 Tenant 生成 volumesPerServer x servers 个 Persistent Volume Claim。

    volumeClaimTemplate.spec.storageClassName

    与生成的 Persistent Volume Claim 关联的 Kubernetes 存储类。

    如果不存在与指定值匹配的存储类，或者 指定的存储类无法满足所请求的 PVC 数量或存储容量，Tenant 可能无法启动。

    volumeClaimTemplate.spec.resources.requests.storage

    为每个生成的 PVC 请求的存储容量。

  3. 配置 Tenant Affinity 或 Anti-Affinity

    MinIO Operator 支持以下 Kubernetes Affinity 和 Anti-Affinity 配置：

    • Node Affinity (spec.pools[n].nodeAffinity)
    • Pod Affinity (spec.pools[n].podAffinity)
    • Pod Anti-Affinity (spec.pools[n].podAntiAffinity)

    生产环境应为 Tenant 配置 Pod Anti-Affinity，避免 Kubernetes 调度器将多个 Tenant pod 放到同一个 worker node 上。

    如果你希望将 Tenant 部署到特定 worker node 上，请将对应的 node label 或过滤条件传入 nodeAffinity 字段，以约束调度器仅在这些节点上放置 pod。

  4. 配置网络加密

    MinIO Tenant CRD 提供以下字段，用于配置 Tenant 的 TLS 网络加密：

    字段

    描述

    spec.requestAutoCert

    启用或禁用 Silo 自动 TLS 证书生成。

    若省略该字段，默认值为 true。

    spec.certConfig

    在启用的情况下，自定义 自动 TLS 的行为。

    spec.externalCertSecret

    通过 Server Name Indication (SNI) 为多个主机名启用 TLS

    指定一个或多个类型为 kubernetes.io/tls 或 cert-manager 的 Kubernetes secret。

    spec.externalCaCertSecret

    启用对由未知、第三方或内部 Certificate Authorities (CA) 签发的客户端 TLS 证书的校验。

    指定一个或多个类型为 kubernetes.io/tls 的 Kubernetes secret，其中包含某个 CA 的完整证书链。

  5. 配置 Silo 环境变量

    Silo 保留上游 MINIO_* 环境变量契约。你可以通过 Tenant CRD 的 spec.configuration 字段所引用的 Secret 提供这些变量，也可以使用 spec.env 设置 MINIO_UPDATE 等单项变量。

    字段

    描述

    spec.configuration.name

    指定一个 Kubernetes opaque Secret，其 config.env 键包含要设置的上游兼容环境变量。

    按 v7.1.1 基础模板使用 stringData.config.env 时填写明文；若改用 data.config.env，其值必须经过 base64 编码。

    该 YAML 中包含一个 kind: Secret 且 metadata.name: storage-configuration 的对象，用于设置 root 用户名、密码、纠删码校验设置，以及启用 Tenant Console。

    请根据 Tenant 的实际需求修改这些值。

  6. 检查命名空间

    YAML 对象 kind: Namespace 将 Tenant 的默认命名空间设置为 minio-tenant。

    你可以修改该值，为 Tenant 创建不同的命名空间。 你必须同时修改 YAML 文件中 所有 metadata.namespace 的值，使其与该命名空间保持一致。

  7. 部署 Tenant

    使用 kubectl apply -f 命令部署 Tenant。

    kubectl apply -f tenant-base.yaml

    该命令会在配置好的命名空间中创建 YAML 对象里定义的每一项资源。

    你可以使用以下命令监控进度：

    watch kubectl get all -n minio-tenant

  8. 暴露 Tenant 的 S3 API 端口

    若要在本地机器上测试 Silo 客户端 mc，请转发 S3 API 端口并创建别名。

    • 转发 Tenant 的 S3 API 端口：
    kubectl port-forward svc/MINIO_TENANT_NAME-hl 9000 -n MINIO_TENANT_NAMESPACE
    • 为 Tenant 服务创建别名：
    mc alias set myminio https://localhost:9000 minio minio123 --insecure

    你可以使用 mc mb 在 Tenant 上创建存储桶：

    mc mb myminio/mybucket --insecure

    如果你为 Tenant 部署的是由受信任 Certificate Authority (CA) 签发的 TLS 证书，则可以省略 --insecure 参数。

    具体说明请参阅 连接到 Tenant。

连接到 Tenant

MinIO Operator 会为 Silo Tenant 创建 Kubernetes Service；这些生成名称仍属于 Operator 契约。

使用 kubectl get svc -n NAMESPACE 命令查看已部署的服务。 如果你的 Kubernetes 环境使用自定义的 kubectl 替代程序，也可以替换为对应程序名。

kubectl get svc -n minio-tenant-1
NAME                               TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
minio                              LoadBalancer   10.97.114.60     <pending>     443:30979/TCP    2d3h
TENANT-NAMESPACE-console           LoadBalancer   10.106.103.247   <pending>     9443:32095/TCP   2d3h
TENANT-NAMESPACE-hl                ClusterIP      None             <none>        9000/TCP         2d3h
  • minio 服务暴露 Tenant S3 API。应用程序应通过该服务对 Silo 执行 S3 操作。
  • *-console 服务暴露 Silo Console。管理员可以通过该服务进行浏览器管理。

其余服务用于支撑 Tenant 内部操作，并不面向用户或管理员直接使用。

默认情况下，每个服务仅在 Kubernetes 集群内部可见。 部署在集群内部的应用可以通过 CLUSTER-IP 访问这些服务。

位于 Kubernetes 集群外部的应用可以通过 EXTERNAL-IP 访问这些服务。 该值只有在 Kubernetes 集群配置了 Ingress 或类似网络访问服务时才会被填充。 Kubernetes 提供了多种对 service 开放外部访问的方式。

有关如何配置 service 的外部访问，请参阅 Kubernetes 文档中的 Publishing Services (ServiceTypes) 和 Ingress。

对于 OpenShift、Rancher 等特定 Kubernetes 发行版，请以其服务文档中关于对内或对外暴露 Service 的首选或可用方式为准。

5 - 使用 Helm 部署 Operator

概览

Helm 是一个用于将应用自动部署到 Kubernetes 集群的工具。 Helm chart 是一组定义部署细节的 YAML 文件、模板和其他文件。 以下步骤使用 Helm Chart 将 MinIO Kubernetes Operator 安装到 Kubernetes 集群中。

警告

上游 MinIO Operator 仓库已于 2026 年 3 月 20 日归档。本流程固定到其最终版本 v7.1.1，仅作为冻结的兼容基线；这不代表上游仍在维护或提供支持。用于生产环境前，请针对你的 Kubernetes 平台完成验证。

前提条件

基础要求请参阅 Operator 前提条件。 使用 Helm 安装还需要满足以下额外要求：

  • Helm 使用与你的 Kubernetes API 版本匹配的 Helm 版本。
  • yq

有关 Operator 安装要求的更多信息，包括受支持的 Kubernetes 版本和 TLS 证书，请参阅 Operator 部署前提条件。

本步骤默认你已经熟悉相关 Kubernetes 概念和工具。 虽然本文档可能会以 best-effort 方式提供 Kubernetes 相关资源的配置或部署指导，但它不能替代官方 Kubernetes Documentation。

使用 Helm Charts 安装 MinIO Operator

以下步骤使用 MinIO Operator Chart Repository 安装 Operator。 与 本地 chart 安装 相比，这种方式的安装路径更简单。 安装完成后，你仍可继续修改 Operator 部署。

警告

重要

如果你使用 Helm charts 安装 Operator，就必须使用 Helm 来管理该安装。 不要使用 kubectl krew、Kustomize 或类似方式更新或管理 MinIO Operator 安装。

  1. 将 MinIO Operator Repo 添加到 Helm

    已归档项目的仓库端点 https://operator.min.io 当前仍提供 v7.1.1 Chart。将该仓库添加到 Helm：

    helm repo add minio-operator https://operator.min.io

    你可以使用 helm search 验证仓库内容：

    helm search repo minio-operator

    返回结果应类似如下：

    NAME                            CHART VERSION   APP VERSION     DESCRIPTION
minio-operator/minio-operator   4.3.7           v4.3.7          A Helm chart for MinIO Operator
minio-operator/operator         7.1.1           v7.1.1          A Helm chart for MinIO Operator
minio-operator/tenant           7.1.1           v7.1.1          A Helm chart for MinIO Operator

    minio-operator/minio-operator 是旧版 chart，正常情况下 不应 安装。

  2. 安装 Operator

    运行 helm install 命令安装 Operator。 以下命令会指定并创建一个专用命名空间 minio-operator 用于安装。 MinIO 强烈建议为 Operator 使用专用命名空间。

    helm install \
  --namespace minio-operator \
  --create-namespace \
  --version 7.1.1 \
  operator minio-operator/operator

  3. 验证 Operator 安装

    检查指定命名空间（minio-operator）中的内容，确保所有 pod 和 service 均已成功启动。

    kubectl get all -n minio-operator

    返回结果应类似如下：

    NAME                                  READY   STATUS    RESTARTS   AGE
pod/minio-operator-699f797b8b-th5bk   1/1     Running   0          25h
pod/minio-operator-699f797b8b-nkrn9   1/1     Running   0          25h

NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/operator   ClusterIP   10.43.44.204    <none>        4221/TCP            25h
service/sts        ClusterIP   10.43.70.4      <none>        4223/TCP            25h

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/minio-operator   2/2     2            2           25h

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/minio-operator-79f7bfc48    2         2         2       123m

现在你可以 使用 Helm Charts 部署租户。

使用本地 Helm Charts 安装 MinIO Operator

以下步骤使用 Helm Charts 的本地副本安装 Operator。 与 基于仓库的安装 相比，这种方式可能更便于在安装前完成 Operator 预配置。

  1. 下载 Helm charts

    在本地主机上，将 Operator Helm charts 下载到一个合适的目录：

    curl -O https://operator.min.io/helm-releases/operator-7.1.1.tgz

  2. （可选）修改 values.yaml

    该 chart 包含一个可按需定制的 values.yaml 文件。 有关 MinIO Operator values.yaml 可用选项的详细信息，请参阅 Operator Helm 图表。

    例如，你可以修改 operator.replicaCount 的副本数，以增加或减少部署中的 pod 可用性。 有关 Operator Helm Chart 和 Values 的更完整文档，请参阅 Operator Helm 图表。

    有关定制方式的更多信息，请参阅 Helm Charts。

  3. 安装 Helm Chart

    使用 helm install 命令安装已下载的 Chart 归档文件。

    helm install \
--namespace minio-operator \
--create-namespace \
minio-operator ./operator-7.1.1.tgz

  4. 要验证安装，请运行以下命令：

    kubectl get all --namespace minio-operator

    如果你使用自定义命名空间初始化了 Operator，请将 minio-operator 替换为该命名空间。

    使用 Chart 默认值时，该命名空间中应包含一个具有两个就绪副本的 minio-operator Deployment、端口为 4221 的 operator ClusterIP Service，以及端口为 4223 的 sts ClusterIP Service。Pod 哈希、Cluster IP 与运行时长会因安装而异。

现在你可以 使用 Helm Charts 部署租户。

6 - 在 Kubernetes 上部署 Silo

Silo 是可在 Kubernetes 中运行的 S3 兼容对象存储服务端。MinIO Kubernetes Operator 的最后一个上游版本 v7.1.1 可以部署使用 Silo 镜像的 Tenant：将 tenant.image.repository 覆盖为 pgsty/silo，并固定经过测试的标签或摘要。

这些指南默认你熟悉所引用的 Kubernetes 概念、工具和操作流程。它们不能替代官方 Kubernetes Documentation；Silo 项目也不继承原 MinIO 厂商针对各 Kubernetes 发行版的支持矩阵。

MinIO Operator、Helm Chart、CRD 与 Tenant Kind 都是独立于 Silo 发布的上游契约。上游 minio/operator 仓库已于 2026-03-20 归档并设为只读，因此其发布周期已经冻结，这些指南只是一份兼容快照。

归档的 Operator 代码提供 MinIO 兼容的 Tenant 管理与配置功能。在部署或升级前，请针对实际集群验证固定的 Operator 与 Chart；上游不再提供持续的兼容性或支持承诺。

你可以通过 Operator 的 Custom Resource Definition (CRD) 与其交互。

CRD 为 Kustomize、Helm 和 kubectl 等工具部署与管理使用 Silo 镜像的 Tenant 提供可定制入口。

警告

重要

MinIO Operator Console UI 已被弃用，并在 MinIO Operator 6.0.0 中移除。

你仍可继续使用标准 Kubernetes 方式管理 MinIO 租户，例如 Kustomize 模板、Helm Charts，以及用于查看租户命名空间和资源的 kubectl 命令。

7 - 在 RHEL 兼容 Linux 上部署 Silo

本页介绍如何在 RHEL 及其二进制兼容 Linux 发行版上部署 Silo。

Silo 为 x86-64 与 ARM64 发布 RPM 软件包和独立 Linux 归档。项目没有单独发布 RHEL 支持生命周期矩阵，因此已删除继承文档中的时间点版本清单。请选择仍处于发行商支持期内的版本，保持内核与系统库更新，并在生产使用前验证精确的存储与工作负载配置。

本步骤重点介绍生产级 多机多盘 (MNMD)“Distributed”配置。 MNMD 部署可提供企业级性能、可用性和可扩展性，是所有生产工作负载的推荐拓扑。

本步骤也包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

MinIO 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。 你可以在设置集群时配置按对象生效的 parity，也可以让 MinIO 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。 可使用 MinIO 纠删码计算器 选择适合你集群的纠删码校验级别。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

基于容量的规划

MinIO 建议在存储使用率达到 70% 之前，预先规划足以存放 至少 2 年数据的存储容量。 过于频繁地执行 服务器池 扩容，或按“just-in-time”方式扩容，通常说明架构或规划存在问题。

例如，假设某套应用每年预计至少生成 100 TiB 数据，并以 3 年后再扩容为目标。 若在部署初期就提供约 500 TiB 可用存储，集群即可在安全满足 70% 阈值的同时，为每年的数据增长预留额外缓冲。

建议使用 MinIO 纠删码计算器，围绕具体纠删码设置进行容量规划。

步骤

1. 下载 Silo RPM 包

从下载与安装获取 x86-64 或 ARM64 RPM，校验发布摘要后安装：

sudo dnf install ./minio-*.rpm

当前 Silo 发布不提供继承文档中提到的 ppc64le 或 s390x 软件包变体。

2. 查看 systemd 服务文件

.rpm 软件包会将以下 systemd 服务文件安装到 /usr/lib/systemd/system/minio.service：

[Unit]
Description=MinIO
Documentation=https://silo.pgsty.com/zh/docs/
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio-user
Group=minio-user
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

# Disable killing of MinIO by the kernel's OOM killer
OOMScoreAdjust=-1000

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

3. 为 MinIO 创建用户和组

minio.service 文件默认以 minio-user 用户和组身份运行。 你可以使用 groupadd 和 useradd 命令创建该用户和组。 以下示例创建用户、组，并为计划供 MinIO 使用的文件夹路径设置访问权限。 这些命令通常需要 root（sudo）权限。

groupadd -r minio-user
useradd -M -r -g minio-user minio-user

以上命令创建的用户 不包含 主目录，这对系统服务账户来说是典型做法。

你 必须 对计划供 MinIO 使用的驱动器路径执行 chown。 如果 minio-user 用户或组无法读取、写入或列出任一驱动器的内容，MinIO 进程会在启动时返回错误。

例如，以下命令将 /mnt/drives-n 下所有驱动器的属主和属组设置为 minio-user:minio-user，其中 n 的范围为 1 到 16：

chown -R minio-user:minio-user /mnt/drives-{1...16}

4. 启用 TLS 连接

为 MinIO 创建或提供 传输层安全 (TLS) 证书，以自动启用 server 与客户端之间的 HTTPS 安全连接。

请将证书放置在 minio-user 用户/组可访问的目录中：

mkdir -p /opt/minio/certs
chown -R minio-user:minio-user /opt/minio/certs

cp private.key /opt/minio/certs
cp public.crt /opt/minio/certs

对于本地测试或开发环境，你可以使用 MinIO certgen 生成自签名证书。 例如，以下命令会生成一组带有 IP 和 DNS Subject Alternate Names (SANs) 的自签名证书，这些 SAN 与 MinIO 服务端 主机关联：

certgen -host "localhost,minio-*.example.net"

将生成的 public.crt 和 private.key 放入 /path/to/certs 目录，以为 MinIO 部署启用 TLS。 应用程序可以将 public.crt 作为受信任的证书颁发机构，从而在不禁用证书校验的情况下连接到 MinIO 部署。

当 MinIO 启用 TLS 运行时，它还会根据操作系统中的受信任证书颁发机构列表来验证连接客户端的证书。 若要启用对第三方证书或内部签发证书的验证，请将 CA 文件放入 /opt/minio/certs/CAs 目录。 CA 文件应包含从叶子证书到根证书的完整信任链，以确保验证成功。

有关为 MinIO 配置 TLS 的更具体指导，包括通过 Server Name Indication (SNI) 支持多域名，请参阅 网络加密（TLS）。 你也可以跳过此步骤，以在未启用 TLS 的情况下部署。MinIO 强烈 不建议 在早期开发之外的场景中进行非 TLS 部署。

5. 创建 MinIO 环境文件

在 /etc/default/minio 创建环境文件。 MinIO 服务将该文件作为 MinIO 以及 minio.service 文件所用全部 环境变量 的来源。

请根据你的部署拓扑修改示例。

在生产环境中使用 多机多盘（“Distributed”）部署拓扑。

# Set the hosts and volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following example covers four MinIO hosts
# with 4 drives each at the specified hostname and drive locations.
#
# The command includes the port that each MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio{1...4}.example.net:9000/mnt/disk{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

在开发和评估环境中使用 单机多盘 部署。 对于能够容忍节点停机带来数据丢失或不可用的小型存储工作负载，也可以使用该拓扑。

# Set the volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following specifies a single host with 4 drives at the specified location
#
# The command includes the port that the MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio1.example.net:9000/mnt/drive{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

在早期开发和评估环境中使用 单机单盘（“Standalone”）部署。 MinIO 不建议在生产环境中使用 单机部署，因为节点或其存储介质丢失会导致数据丢失。

警告

重要

SNSD 部署不支持通过添加新的 服务器池 来扩展存储。

# Set the volume MinIO uses at startup
#
# The following specifies the drive or folder path

MINIO_VOLUMES="/mnt/drive1/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

请根据部署需要，指定其他 环境变量 或 server 命令行选项。

对于分布式部署，所有节点的 /etc/default/minio 环境文件 必须 完全一致。 可在每个节点上使用 shasum -a 256 /etc/default/minio 等工具验证其是否完全匹配。

6. 启动 MinIO 部署

使用 systemctl start minio 启动部署中的每个节点。

你可以在每个节点上使用 journalctl -u minio 跟踪启动状态。

启动成功后，MinIO 进程会输出一段部署摘要，类似如下：

MinIO 对象存储服务端
Copyright: 2015-2024 MinIO, Inc.
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Version: RELEASE.2024-06-07T16-42-07Z (go1.22.4 linux/amd64)

API: https://minio-1.example.net:9000 https://203.0.113.10:9000 https://127.0.0.1:9000
   RootUser: minioadmin
   RootPass: minioadmin

WebUI: https://minio-1.example.net:9001 https://203.0.113.10:9001 https://127.0.0.1:9001
   RootUser: minioadmin
   RootPass: minioadmin

CLI: https://silo.pgsty.com/zh/reference/minio-mc/#quickstart
   $ mc alias set 'myminio' 'https://minio-1.example.net:9000' 'minioadmin' 'minioadmin'

Docs: https://silo.pgsty.com/zh/docs/
Status:         16 Online, 0 Offline.

在集群启动和同步期间，你可能会看到日志明显增多。

启动失败的常见原因包括：

  • MinIO 进程对指定驱动器没有读、写、列出权限
  • 驱动器不是空的，或其中包含非 MinIO 数据
  • 驱动器未正确格式化或挂载
  • 一个或多个主机无法通过网络访问

遵循我们的检查清单通常可以降低遇到这些或类似问题的风险。

7. 连接到部署

打开浏览器，并通过任一 MinIO 主机名的 :9001 端口访问 MinIO Console 登录页。 例如：https://minio1.example.com:9001。

使用上一步中的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 登录。

MinIO Console 登录页

你可以使用 MinIO Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。 每个 MinIO server 都包含自身内嵌的 MinIO Console。

请按照本地主机上的 mc 安装说明 完成安装。 运行 mc --version 验证安装结果。

如果你的 MinIO 部署使用第三方或自签名 TLS 证书，请将 CA 文件复制到 ~/.mc/certs/CAs，以便 mc 信任该证书链。

安装完成后，为该 MinIO 部署创建一个别名：

mc alias set myminio https://minio-1.example.net:9000 USERNAME PASSWORD

请根据你的部署修改主机名、用户名和密码。 主机名可以是部署中的任意一个 MinIO 节点。 你也可以指定负责处理部署连接的负载均衡器、反向代理或类似网络控制平面的主机名。

8. 后续步骤

8 - 升级 MinIO Operator

你可以随时升级 MinIO Operator，而不会影响其管理的 MinIO Tenant。

在升级过程中，Operator 可能会更新并重启 Tenant，以支持 MinIO 自定义资源定义（CRD）的变更。 这些变更不需要操作员或管理员采取额外操作，也不会影响 Tenant 的运行。

本页说明如何将 Operator 从 5.0.15 升级到 7.1.1。 如果在开始本流程前需要先升级到 Operator 5.0.15，请参阅 将 MinIO Operator 4.5.8 及更高版本升级到 5.0.15。

说明

Operator 6.0.0 弃用 Operator Console

从 Operator 6.0.0 开始，MinIO Operator Console 已被弃用并移除。

你可以继续使用 Kustomize 或 Helm 等标准 Kubernetes 方式来管理和部署 MinIO Tenant。

将 MinIO Operator 从 5.0.15 升级到 7.1.1

警告

重要

Operator 6.0.0 弃用 MinIO Operator Console，并从 MinIO Operator CRD 中移除相关资源。 其中包括 Operator Console 的 service、pod 等资源。

后续请改用 Kustomize 或 Helm 来管理 Tenant。

以下步骤使用 Kustomize 升级 MinIO Operator。 对于使用 Operator 5.0.0 到 5.0.14 的部署，请先按照 将 MinIO Operator 4.5.8 及更高版本升级到 5.0.15 完成升级，再执行本流程。

如果你是通过 Helm 安装 Operator，请改用 使用 Helm 升级 步骤。

  1. (可选) 将每个 MinIO Tenant 升级到最新稳定版 MinIO。

    定期升级 MinIO 可确保 Tenant 获得最新特性和性能改进。 在将升级应用到生产 Tenant 之前，请先在 Dev 或 QA Tenant 等较低环境中验证。 升级 MinIO Tenant 的具体流程请参阅 升级 MinIO Tenant。

  2. 验证现有 Operator 安装。 使用 kubectl get all -n minio-operator 验证所有 Operator pod 和 service 的健康状态与运行状态。

    如果你将 Operator 安装到了自定义命名空间，请在命令中指定 -n <NAMESPACE>。

    你可以通过获取该命名空间中某个 operator pod 的对象规范，确认当前安装的 Operator 版本。 以下示例使用 jq 工具从 kubectl 输出中过滤出所需信息：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

    输出类似如下：

    {
   "env": [
      {
         "name": "CLUSTER_DOMAIN",
         "value": "cluster.local"
      }
   ],
   "image": "minio/operator:v5.0.15",
   "imagePullPolicy": "IfNotPresent",
   "name": "minio-operator"
}

    如果本地主机未安装 jq，你也可以只执行命令的前半部分，然后在输出中查找 spec.containers 段落。

  3. 使用 Kustomize 升级 Operator

    以下命令会将 Operator 升级到 7.1.1：

    kubectl apply -k github.com/minio/operator

    在下面的示例输出中，configured 表示更新后的 CRD 已应用对应变更：

    namespace/minio-operator unchanged
customresourcedefinition.apiextensions.k8s.io/miniojobs.job.min.io configured
customresourcedefinition.apiextensions.k8s.io/policybindings.sts.min.io configured
customresourcedefinition.apiextensions.k8s.io/tenants.minio.min.io configured
serviceaccount/minio-operator unchanged
clusterrole.rbac.authorization.k8s.io/minio-operator-role configured
clusterrolebinding.rbac.authorization.k8s.io/minio-operator-binding unchanged
service/operator unchanged
service/sts unchanged
deployment.apps/minio-operator configured

  4. 验证 Operator 升级结果

    你可以使用前面相同的 kubectl 命令检查新的 Operator 版本：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

以下步骤使用 Helm 升级现有的 MinIO Operator 安装。

如果你是使用 Kustomize 安装 Operator，请改用 使用 Kustomize 升级 步骤。

  1. (可选) 将每个 MinIO Tenant 升级到最新稳定版 MinIO。

    定期升级 MinIO 可确保 Tenant 获得最新特性和性能改进。 在将升级应用到生产 Tenant 之前，请先在 Dev 或 QA Tenant 等较低环境中验证。 升级 MinIO Tenant 的具体流程请参阅 升级 MinIO Tenant。

  2. 验证现有 Operator 安装。

    使用 kubectl get all -n minio-operator 验证所有 Operator pod 和 service 的健康状态与运行状态。

    如果你将 Operator 安装到了自定义命名空间，请在命令中指定 -n <NAMESPACE>。

    使用 helm list 查看该命名空间中已安装的 chart：

    helm list -n minio-operator

    结果应类似如下：

    NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
operator        minio-operator  1               2023-11-01 15:49:54.539724775 -0400 EDT deployed        operator-5.0.x v5.0.x

  3. 更新 Operator 仓库

    使用 helm repo update minio-operator 更新 MinIO Operator 仓库。 如果你为 MinIO Operator 仓库设置了不同别名，请在命令中使用该别名替代 minio-operator。 你可以使用 helm repo list 查看当前已安装的仓库。

    更新 Operator 仓库后，使用 helm search 检查最新可用的 chart 版本：

    helm search repo minio-operator

    返回结果应类似如下：

    NAME                            CHART VERSION   APP VERSION     DESCRIPTION
minio-operator/minio-operator   4.3.7           v4.3.7          A Helm chart for MinIO Operator
minio-operator/operator         7.1.1          v7.1.1         A Helm chart for MinIO Operator
minio-operator/tenant           7.1.1          v7.1.1         A Helm chart for MinIO Operator

    minio-operator/minio-operator 是旧版 chart，正常情况下 不应 安装。

  4. 运行 helm upgrade

    Helm 会使用最新 chart 升级 MinIO Operator：

    helm upgrade -n minio-operator \
operator minio-operator/operator

    如果你将 MinIO Operator 安装到了其他命名空间，请在 -n 参数中指定该命名空间。

    如果你使用的安装名不是 operator，请将上面的值替换为实际安装名。

    命令应返回成功，并且 REVISION 值会递增。

  5. 验证 Operator 升级结果

    你可以使用前面相同的 kubectl 命令检查新的 Operator 版本：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

9 - 升级 Silo 部署

警告

从上游旧版本迁移

如果部署仍运行早于 RELEASE.2024-03-30T09-41-56Z 的上游 MinIO，且启用了 AD/LDAP，请先阅读上游 RELEASE.2024-04-18T19-09-19Z 的发布说明，并完成其中的迁移步骤，再切换到 Silo。这里的名称与链接用于标识上游发布契约，刻意保留不改。

升级 Silo 时，应先在每个节点安装经过校验的服务端制品，再把整个部署作为一次协调操作重启。全量集群重启会造成短暂不可用；应用应重试失败或中断的请求，对象操作的原子性并不能替代重试处理。

本页覆盖由 systemctl 管理和手工管理的裸机部署。若服务由 Ansible、Terraform、容器或其他编排器管理，请通过该工具落实同样的发布、校验与重启边界，不要手工修改其管理的文件。

升级前准备

  1. 备份集群设置。 使用 mc admin cluster bucket export 与 mc admin cluster iam export 导出存储桶元数据和 IAM 配置。
  2. 选择已经公开发布的 Silo 版本。 以下载与安装、Silo 发布说明和 GitHub Releases为准。本地标签、分支提交、草稿 Release 或上传到草稿中的制品都不等于公开发布。
  3. 校验制品。 将 SHA-256 摘要与该精确版本随附的校验和核对；所有节点固定到同一个版本。
  4. 阅读跨越的全部发布说明。 特别关注格式、身份认证、配置和降级限制。
  5. 在低环境验证完全相同的升级。 上生产前覆盖代表性的读写、策略、生命周期、复制、通知与恢复流程。
  6. 禁用继承的原地更新器。 在服务端环境中设置 MINIO_UPDATE=off，并重启服务让配置生效。
  7. 检查桶级策略中的对象级资源。 在导出的 IAM 配置里，查找那些把十二个桶级写动作之一（或 s3:*）授在含 / 的资源模式上、且同一个桶没有裸桶 ARN 的语句。这些语句不再授权那些动作。请在对象模式旁边补上裸桶 ARN，参见存储桶资源与对象资源。内置策略以及任何使用 arn:aws:s3:::* 的语句都不受影响。
注意

不要对 Silo 使用 mc admin update ALIAS

截至 2026-08-05，最新公开 Silo 服务端在省略更新 URL 时，仍会选择上游 dl.min.io 发布源和上游 MinIO 签名密钥。因此该命令可能把 Silo 替换成上游二进制。请使用下面经过校验的软件包或二进制流程。另一个客户端命令 mc update 已被禁用，不能执行升级。

systemctl 管理的部署

  1. 从下载与安装为每个节点下载同一个公开服务端版本，并校验其摘要。

  2. 在 不单独重启部分集群 的前提下，在每个节点安装软件包或替换二进制：

    sudo dnf install /path/to/minio.rpm
    sudo dpkg -i /path/to/minio.deb
    sha256sum ./minio
sudo install -m 0755 ./minio /usr/local/bin/minio

    如果安装位置不同，请把 /usr/local/bin/minio 替换成 command -v minio 返回的路径。

  3. 在每个节点运行 minio --version。只有所有节点都报告同一个预期版本时才能继续。

  4. 把所有服务端进程作为一次协调操作重启。管理 API 可用时执行：

    mc admin service restart ALIAS

    否则通过自动化在所有节点协调执行 systemctl restart minio。除非目标发布明确支持混合版本，否则不要临时改成滚动升级。

  5. 使用 mc admin info 验证部署，然后测试代表性的 S3 读写、控制台访问、身份登录以及已配置的复制或通知。

  6. 从下载与安装单独升级客户端。独立制品使用 mcli，源码构建与容器保留 mc。

手工管理的部署

对于由用户脚本或其他 supervisor 管理的进程，请在每个节点下载并校验同一个 Silo 二进制，替换 supervisor 实际使用路径上的可执行文件，确认 minio --version，再把所有节点作为一次协调操作重启。服务账户必须能够执行新二进制，执行替换的运维用户必须能够写入安装路径。

重启后执行与上文相同的验证。验证完成前保留上一个经过校验的二进制，使任何回滚决定都能遵循目标版本发布说明中的降级限制。

10 - 使用 Helm Charts 部署 Silo Tenant

概览

Helm 是一个用于将应用自动部署到 Kubernetes 集群的工具。 Helm chart 是一组定义部署细节的 YAML 文件、模板和其他文件。 以下步骤使用 Helm Chart 部署由 MinIO Operator 管理的 Tenant。

本步骤要求 Kubernetes 集群中已存在一个有效的 Operator 部署。 你不能使用 MinIO Operator Tenant chart 在脱离 Operator 的情况下独立部署 Tenant。

警告

重要

MinIO Operator Tenant Chart 与服务端仓库中的旧社区 MinIO Chart 不同。本指南使用 Operator Tenant Chart，因为它提供明确的 Tenant 镜像覆盖。上游 Operator 仓库已于 2026 年 3 月 20 日归档，因此本文固定其最终 v7.1.1 Chart，仅作为冻结的兼容基线；Silo 不继承上游厂商的支持承诺。

前提条件

要使用 Helm 安装 MinIO Tenant，你必须满足以下要求：

  • 一个现有的 Kubernetes 集群
  • 本地主机上安装了与集群版本匹配的 kubectl CLI 工具
  • Helm 3.8 或更高版本
  • yq 4.18.1 或更高版本
  • 一个现有的 MinIO Operator 安装

本步骤默认你对 Kubernetes 集群的访问权限具备较广泛的管理能力。

有关 Tenant 安装要求的更多信息，包括受支持的 Kubernetes 版本和 TLS 证书，请参阅 Tenant 部署前提条件。

本步骤默认你已经熟悉相关 Kubernetes 概念和工具。 虽然本文档可能会以 best-effort 方式提供 Kubernetes 相关资源的配置或部署指导，但它不能替代官方 Kubernetes Documentation。

命名空间

租户必须使用自己的命名空间，不能与其他租户共享命名空间。 此外，MinIO 强烈建议为租户使用专用命名空间，且该命名空间内不要运行其他应用。

使用 Helm Charts 部署 Silo Tenant

以下步骤使用 MinIO Operator Chart Repository 部署 MinIO Tenant。 与 本地 chart 安装 相比，这种方式的安装路径更简单。

以下步骤使用 Helm 通过已归档上游项目的 v7.1.1 Tenant Chart 部署 MinIO Tenant。

警告

重要

如果你使用 Helm 部署 MinIO Tenant，就必须使用 Helm 来管理或升级该部署。 不要使用 kubectl krew、Kustomize 或类似方式来管理或升级 MinIO Tenant。

本步骤并未穷尽 Tenant Chart 中所有可能的配置项。 它只提供一个基线，你可以在此基础上按需修改和定制 Tenant。

  1. 验证 MinIO Operator Repo 配置

    已归档项目的端点 https://operator.min.io 当前仍提供 v7.1.1 Chart。 如果该仓库尚未存在于本地 Helm 配置中，请先添加后再继续：

    helm repo add minio-operator https://operator.min.io

    你可以使用 helm search 验证仓库内容：

    helm search repo minio-operator

    返回结果应类似如下：

    NAME                            CHART VERSION   APP VERSION     DESCRIPTION
minio-operator/minio-operator   4.3.7           v4.3.7          A Helm chart for MinIO Operator
minio-operator/operator         7.1.1           v7.1.1          A Helm chart for MinIO Operator
minio-operator/tenant           7.1.1           v7.1.1          A Helm chart for MinIO Operator

  2. 创建 Helm values.yaml 的本地副本以供修改

    curl -sLo values.yaml https://raw.githubusercontent.com/minio/operator/v7.1.1/helm/tenant/values.yaml

    请使用文本编辑器打开 values.yaml。继续之前，替换上游服务端镜像默认值，并禁用继承的原地更新器：

    tenant:
  image:
    repository: pgsty/silo
    tag: RELEASE.2026-09-03T13-18-01Z
    pullPolicy: IfNotPresent
  env:
    - name: MINIO_UPDATE
      value: "off"

    仅当更新标签已在 Silo 下载页 发布，并通过你的部署验证后才应使用。Silo 生产环境的 values 文件不应保留 quay.io/minio/minio 或 latest。

  3. 配置 Tenant 拓扑

    以下字段都带有 tenant.pools[0] 前缀，用于控制 Tenant 中所有 pod 的 server 数量、每个 server 的卷数量以及存储类：

    字段

    描述

    servers

    要在 服务器池 中部署的 MinIO pod 数量。

    volumesPerServer

    每个 MinIO pod（servers）要挂载的持久卷数量。 Operator 会为该 Tenant 生成 volumesPerServer x servers 个 Persistent Volume Claim。

    storageClassName

    与生成的 Persistent Volume Claim 关联的 Kubernetes 存储类。

    如果不存在与指定值匹配的存储类，或者 指定的存储类无法满足所请求的 PVC 数量或存储容量，Tenant 可能无法启动。

    size

    为每个生成的 PVC 请求的存储容量。

  4. 配置 Tenant Affinity 或 Anti-Affinity

    Tenant Chart 支持以下 Kubernetes Selector、Affinity 和 Anti-Affinity 配置：

    • Node Selector (tenant.nodeSelector)
    • Node/Pod Affinity or Anti-Affinity (spec.pools[n].affinity)

    MinIO 建议为 Tenant 配置 Pod Anti-Affinity，以确保 Kubernetes 调度器不会将多个 pod 调度到同一个 worker node 上。

    如果你希望将租户部署到特定 worker node 上，请将对应的 node label 或过滤条件传入 nodeSelector 或 affinity 字段，以约束调度器仅在这些节点上放置 pod。

  5. 配置网络加密

    MinIO Tenant CRD 提供了以下字段，你可以通过它们配置租户的 TLS 网络加密：

    字段

    描述

    tenant.certificate.requestAutoCert

    启用或禁用 MinIO 自动 TLS 证书生成。

    若省略该字段，默认值为 true，即启用。

    tenant.certificate.certConfig

    在启用的情况下，自定义 自动 TLS 的行为。

    tenant.certificate.externalCertSecret

    通过 Server Name Indication (SNI) 为多个主机名启用 TLS。

    指定一个或多个类型为 kubernetes.io/tls 或 cert-manager 的 Kubernetes secret。

    tenant.certificate.externalCACertSecret

    启用对由未知、第三方或内部 Certificate Authorities (CA) 签发的客户端 TLS 证书的校验。

    指定一个或多个类型为 kubernetes.io/tls 的 Kubernetes secret，其中包含某个 CA 的完整证书链。

  6. 配置 Silo 环境变量

    你可以使用 tenant.configuration 字段设置服务端 MINIO_* 环境变量。这些名称属于 MinIO 兼容契约，不得改名。

    字段

    描述

    tenant.configuration

    指定一个 Kubernetes opaque secret，其数据负载 config.env 包含你希望设置的每一个 MinIO 环境变量。

    config.env 数据负载 必须 是一个 base64 编码字符串。 你可以先创建一个本地文件，在其中设置环境变量，再通过 cat LOCALFILE | base64 生成该负载。

    该 YAML 中包含一个 kind: Secret 且 metadata.name: storage-configuration 的对象，用于设置 root 用户名、密码、纠删码校验设置，以及启用 Tenant Console。

    请根据 Tenant 的实际需求修改这些值。

  7. 部署 Tenant

    使用 helm 安装 Tenant Chart，并将 values.yaml 作为覆盖配置：

    helm install \
--namespace TENANT-NAMESPACE \
--create-namespace \
--version 7.1.1 \
--values values.yaml \
TENANT-NAME minio-operator/tenant

    你可以使用以下命令监控进度：

    watch kubectl get all -n TENANT-NAMESPACE

  8. 暴露 Tenant 的 MinIO S3 API 端口

    若要在本地机器上测试 MinIO Client mc，请转发 MinIO 端口并创建别名。

    • 转发 Tenant 的 MinIO 端口：
    kubectl port-forward svc/TENANT-NAME-hl 9000 -n TENANT-NAMESPACE
    • 为 Tenant 服务创建别名：
    mc alias set myminio https://localhost:9000 minio minio123 --insecure

    你可以使用 mc mb 在 Tenant 上创建存储桶：

    mc mb myminio/mybucket --insecure

    如果你为 MinIO Tenant 部署的是由受信任 Certificate Authority (CA) 签发的 TLS 证书，则可以省略 --insecure 参数。

    有关连接 Tenant 的更多文档，请参阅 连接到 Tenant。

使用本地 Helm Chart 部署 Tenant

以下步骤使用 Helm Charts 的本地副本部署 Tenant。 与 基于仓库的安装 相比，这种方式可能更便于在安装前完成 Tenant 预配置。

  1. 下载 Helm charts

    在本地主机上拉取已固定的 Tenant Chart，并将默认 values 提取为单独覆盖文件：

    helm pull minio-operator/tenant --version 7.1.1
helm show values tenant-7.1.1.tgz > values.yaml

    每个 chart 都包含一个可按需定制的 values.yaml 文件。 有关 MinIO Tenant values.yaml 可用选项的详细信息，请参阅 租户 Helm Charts。

    请使用文本编辑器打开 values.yaml：将 tenant.image.repository 设为 pgsty/silo，将 tenant.image.tag 固定为已发布 Silo 版本，并在 tenant.env 中加入 MINIO_UPDATE=off，与 基于仓库的流程 中的示例一致。

  2. 配置 Tenant 拓扑

    以下字段都带有 tenant.pools[0] 前缀，用于控制 Tenant 中所有 pod 的 server 数量、每个 server 的卷数量以及存储类：

    字段

    描述

    servers

    要在 服务器池 中部署的 MinIO pod 数量。

    volumesPerServer

    每个 MinIO pod（servers）要挂载的持久卷数量。 Operator 会为该 Tenant 生成 volumesPerServer x servers 个 Persistent Volume Claim。

    storageClassName

    与生成的 Persistent Volume Claim 关联的 Kubernetes 存储类。

    如果不存在与指定值匹配的存储类，或者 指定的存储类无法满足所请求的 PVC 数量或存储容量，Tenant 可能无法启动。

    size

    为每个生成的 PVC 请求的存储容量。

  3. 配置 Tenant Affinity 或 Anti-Affinity

    Tenant Chart 支持以下 Kubernetes Selector、Affinity 和 Anti-Affinity 配置：

    • Node Selector (tenant.nodeSelector)
    • Node/Pod Affinity or Anti-Affinity (spec.pools[n].affinity)

    MinIO 建议为 Tenant 配置 Pod Anti-Affinity，以确保 Kubernetes 调度器不会将多个 pod 调度到同一个 worker node 上。

    如果你希望将租户部署到特定 worker node 上，请将对应的 node label 或过滤条件传入 nodeSelector 或 affinity 字段，以约束调度器仅在这些节点上放置 pod。

  4. 配置网络加密

    MinIO Tenant CRD 提供了以下字段，你可以通过它们配置租户的 TLS 网络加密：

    字段 描述
    tenant.certificate.requestAutoCert 启用或禁用 MinIO 自动 TLS 证书生成
    tenant.certificate.certConfig 控制 自动 TLS 的设置。 需要 spec.requestAutoCert: true
    tenant.certificate.externalCertSecret 指定一个或多个类型为 kubernetes.io/tls 或 cert-manager 的 Kubernetes secret。 MinIO 会基于主机名（Server Name Indication）使用这些证书执行 TLS 握手。
    tenant.certificate.externalCACertSecret 指定一个或多个类型为 kubernetes.io/tls 的 Kubernetes secret，其中包含 Tenant 为允许客户端 TLS 连接而必须信任的 Certificate Authority (CA) 证书链。

  5. 配置 Silo 环境变量

    你可以使用 tenant.configuration 字段设置服务端 MINIO_* 环境变量。这些名称仍属兼容契约。

    该字段必须指定一个 Kubernetes opaque secret，其数据负载 config.env 包含你希望设置的每一个 MinIO 环境变量。

    该 YAML 中包含一个 kind: Secret 且 metadata.name: storage-configuration 的对象，用于设置 root 用户名、密码、纠删码校验设置，以及启用 Tenant Console。

    请根据 Tenant 的实际需求修改这些值。

  6. 以下 Helm 命令使用已固定的本地 Chart 与经审查 values 创建 Silo Tenant：

    helm install \
--namespace TENANT-NAMESPACE \
--create-namespace \
--values values.yaml \
TENANT-NAME tenant-7.1.1.tgz

    若要部署多个 Tenant，请创建一个包含新 Tenant 详细配置的 Helm chart，并重复上述部署步骤。 重新部署同一个 chart 会更新此前已部署的 Tenant。

  7. 暴露 Tenant 的 MinIO 端口

    若要在本地机器上测试 MinIO Client mc，请转发 MinIO 端口并创建别名。

    • 转发 Tenant 的 MinIO 端口：

      kubectl port-forward svc/TENANT-NAME-hl 9000 -n TENANT-NAMESPACE

    • 为 Tenant 服务创建别名：

      mc alias set myminio https://localhost:9000 minio minio123 --insecure

      该示例使用 HTTPS，但本地客户端可能不信任 Tenant 提供的证书，因此包含 --insecure。如果 Tenant 提供客户端信任的证书，请省略该参数。应确认当前 Tenant 实际生成的服务名，而不要假定固定为 svc/minio。

    你可以使用 mc mb 在 Tenant 上创建存储桶：

    mc mb myminio/mybucket --insecure

有关连接 Tenant 的更多文档，请参阅 连接到 Tenant。

11 - 使用 MinIO Operator 的 Silo 租户

一个 MinIO 租户由部署在单个命名空间中的一整组 Kubernetes 资源组成，用于支撑 MinIO 对象存储服务。

本文默认目标 Kubernetes 基础设施上已经完成 MinIO Operator 安装。

前提条件

你的 Kubernetes 基础设施必须满足以下前提，才能部署 MinIO 租户。

MinIO Kubernetes Operator

本页步骤 要求 已有一个有效的 MinIO Kubernetes Operator 安装，并默认本地主机也安装了与之匹配的 Operator。本页使用仓库归档前的最终上游版本 v7.1.1，仅作为冻结的兼容基线。

有关部署 MinIO Operator 的完整文档，请参阅 在 Kubernetes 上部署 MinIO。

带本地存储的 Worker Node

MinIO 强烈建议 将租户部署到带有本地直连存储的 Kubernetes worker node 上。

这些 Worker Node 应满足 MinIO 面向生产环境的 硬件检查清单。

应避免将 MinIO 租户与其他高性能软件部署在同一 worker node 上；如果确有必要，则必须配置合适的限制和约束，以保证 MinIO 获得所需的计算与存储资源。

持久卷

说明

磁盘独占访问

MinIO 要求 对用于对象存储的磁盘或卷拥有 独占 访问权限。 任何其他进程、软件、脚本或人员都不应直接对提供给 MinIO 的磁盘或卷， 或 MinIO 在其上放置的对象或文件执行 任何 操作。

除非得到 MinIO Engineering 的明确指示，否则不要使用脚本或工具直接修改、 删除或移动这些磁盘上的任何数据分片、校验分片或元数据文件，包括在磁盘或节点 之间迁移这些文件。 这类操作极有可能导致大范围损坏和数据丢失，超出 MinIO 的自愈能力。

MinIO 通常可以使用任何支持 ReadWriteOnce 访问模式的 Kubernetes Persistent Volume (PV)。 MinIO 的一致性保证依赖于 ReadWriteOnce 提供的独占存储访问。 此外，MinIO 建议将 PVC StorageClass 的回收策略设置为 Retain。 在条件允许的情况下，应配置 PV 底层的 Storage Class、CSI 或其他 provisioner 使用 XFS 格式化卷，以确保最佳性能。

对于节点具有 Direct Attached Storage 的 Kubernetes 集群，MinIO 强烈建议使用 DirectPV CSI driver。 DirectPV 提供了一个分布式持久卷管理器，可在 Kubernetes 节点之间发现、格式化、挂载、调度和监控驱动器。 DirectPV 解决了手动配置和监控 local persistent volumes 的局限性。

对于部署到 Amazon Elastic、Azure 或 Google Kubernetes 上的租户，请选择下方标签页查看针对 PV 配置的具体建议：

EKS 上的 MinIO 租户必须使用 EBS CSI Driver 来配置所需的底层持久卷。 MinIO 强烈建议使用基于 SSD 的 EBS 卷以获得最佳性能。 MinIO 也强烈建议为基于 EBS 的 PV 使用 XFS 文件系统。 请为 MinIO EBS PV 创建一个 StorageClass，并将 csi.storage.k8s.io/fstype parameter 设置为 xfs。

MinIO 推荐以下 EBS 卷类型：

  • io2 (Provisioned IOPS SSD) Preferred
  • io1 (Provisioned IOPS SSD)
  • gp3 (General Purpose SSD)
  • gp2 (General Purpose SSD)

有关 EBS 资源的更多信息，请参阅 EBS Volume Types。 有关 StorageClass 参数的更多信息，请参阅 StorageClass Parameters。

GKE 上的 MinIO 租户应使用 Compute Engine Persistent Disk CSI Driver 来配置所需的底层持久卷。

MinIO 推荐以下 GKE CSI Driver 存储类：

  • standard-rwo (Balanced Persistent SSD)
  • premium-rwo (Performance Persistent SSD)

MinIO 强烈建议使用基于 SSD 的磁盘类型以获得最佳性能。 有关 GKE 磁盘类型的更多信息，请参阅 Persistent Disks。

AKS 上的 MinIO 租户应使用 Azure Disks CSI 驱动配置所需的底层持久卷。

MinIO 推荐以下 AKS CSI Driver 存储类：

  • managed-csi (Standard SSD)
  • managed-csi-premium (Premium SSD)

MinIO 强烈建议使用 SSD 磁盘以获得最佳性能。有关 AKS 磁盘类型的更多信息，请参阅 Azure 磁盘类型。

租户命名空间

当你使用 Operator 创建租户时，该租户 必须 拥有自己的命名空间。 在该命名空间内，Operator 会根据租户配置生成所需的 pod。

每个租户 pod 运行三个容器：

  • MinIO Container：运行所有标准 MinIO 功能，等价于裸机场景下的基础 MinIO 安装。 该容器在提供的挂载点（持久卷）上存储和读取对象。
  • InitContainer：仅在 pod 启动期间存在，用于在启动过程中管理配置 secret。 启动完成后，该容器会终止。
  • SideCar container：监控租户的配置 secret，并在其发生变化时进行更新。 该容器还会检查 root 凭证，如果未找到 root 凭证则会产生错误。

从 v5.0.6 起，MinIO Operator 支持自定义 init containers，以满足特定环境所需的额外 pod 初始化逻辑。

租户通过 Persistent Volume Claim 与实际存储对象的 Persistent Volume 交互。

展示 MinIO Operator 使用或维护的命名空间和 pod 的示意图。

12 - 在 Ubuntu Linux 上部署 Silo

本页介绍如何在 Ubuntu Linux 上部署 Silo。

Silo 为 x86-64 与 ARM64 发布 DEB 软件包和独立 Linux 归档。项目没有单独发布 Ubuntu 支持生命周期矩阵，因此已删除继承文档中的时间点版本清单。请选择仍处于发行商支持期内的 Ubuntu 版本，保持内核与系统库更新，并在生产使用前验证精确的存储与工作负载配置。

本步骤重点介绍生产级 多机多盘 (MNMD)“Distributed”配置。 MNMD 部署可提供企业级性能、可用性和可扩展性，是所有生产工作负载的推荐拓扑。

本步骤也包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

MinIO 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。 你可以在设置集群时配置按对象生效的 parity，也可以让 MinIO 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。 可使用 MinIO 纠删码计算器 选择适合你集群的纠删码校验级别。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

基于容量的规划

MinIO 建议在存储使用率达到 70% 之前，预先规划足以存放 至少 2 年数据的存储容量。 过于频繁地执行 服务器池 扩容，或按“just-in-time”方式扩容，通常说明架构或规划存在问题。

例如，假设某套应用每年预计至少生成 100 TiB 数据，并以 3 年后再扩容为目标。 若在部署初期就提供约 500 TiB 可用存储，集群即可在安全满足 70% 阈值的同时，为每年的数据增长预留额外缓冲。

建议使用 MinIO 纠删码计算器，围绕具体纠删码设置进行容量规划。

步骤

1. 下载 Silo DEB 包

从下载与安装获取对应架构的 DEB，校验发布摘要后安装。ARM64 主机请使用名称中带 arm64 的文件。

sudo dpkg -i ./minio_*_amd64.deb

2. 查看 systemd 服务文件

.deb 软件包会将以下 systemd 服务文件安装到 /usr/lib/systemd/system/minio.service：

[Unit]
Description=MinIO
Documentation=https://silo.pgsty.com/zh/docs/
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio-user
Group=minio-user
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

# Disable killing of MinIO by the kernel's OOM killer
OOMScoreAdjust=-1000

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

3. 为 MinIO 创建用户和组

minio.service 文件默认以 minio-user 用户和组身份运行。 你可以使用 groupadd 和 useradd 命令创建该用户和组。 以下示例创建用户、组，并为计划供 MinIO 使用的文件夹路径设置访问权限。 这些命令通常需要 root（sudo）权限。

groupadd -r minio-user
useradd -M -r -g minio-user minio-user

以上命令创建的用户 不包含 主目录，这对系统服务账户来说是典型做法。

你 必须 对计划供 MinIO 使用的驱动器路径执行 chown。 如果 minio-user 用户或组无法读取、写入或列出任一驱动器的内容，MinIO 进程会在启动时返回错误。

例如，以下命令将 /mnt/drives-n 下所有驱动器的属主和属组设置为 minio-user:minio-user，其中 n 的范围为 1 到 16：

chown -R minio-user:minio-user /mnt/drives-{1...16}

4. 启用 TLS 连接

你可以跳过此步骤，以在未启用 TLS 的情况下部署。 MinIO 强烈 不建议 在早期开发之外的场景中进行非 TLS 部署。

为 MinIO 创建或提供 传输层安全 (TLS) 证书，以自动启用服务端与客户端之间的 HTTPS 安全连接。

MinIO 要求私钥和公钥证书的默认文件名分别为 private.key 和 public.crt。 请将证书放置在 minio-user 用户/组可访问的目录中：

mkdir -p /opt/minio/certs
chown -R minio-user:minio-user /opt/minio/certs

cp private.key /opt/minio/certs
cp public.crt /opt/minio/certs

MinIO 会根据操作系统/系统默认的受信任证书颁发机构列表来验证客户端证书。 若要启用对第三方证书或内部签发证书的验证，请将 CA 文件放入 /opt/minio/certs/CAs 目录。 CA 文件应包含从叶子证书到根证书的完整信任链，以确保验证成功。

有关为 MinIO 配置 TLS 的更具体指导，包括通过 Server Name Indication (SNI) 支持多域名，请参阅 网络加密（TLS）。

早期开发环境证书

对于本地测试或开发环境，你可以使用 MinIO certgen 生成自签名证书。 例如，以下命令会生成一组带有 IP 和 DNS Subject Alternate Names (SANs) 的自签名证书，这些 SAN 与 MinIO 服务端 主机关联：

certgen -host "localhost,minio-*.example.net"

将生成的 public.crt 和 private.key 放入 /path/to/certs 目录，以为 MinIO 部署启用 TLS。 应用程序可以将 public.crt 作为受信任的证书颁发机构，从而在不禁用证书校验的情况下连接到 MinIO 部署。

5. 创建 MinIO 环境文件

在 /etc/default/minio 创建环境文件。 MinIO 服务将该文件作为 MinIO 以及 minio.service 文件所用全部 环境变量 的来源。

请根据你的部署拓扑修改示例。

在生产环境中使用 多机多盘（“Distributed”）部署拓扑。

# Set the hosts and volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following example covers four MinIO hosts
# with 4 drives each at the specified hostname and drive locations.
#
# The command includes the port that each MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio{1...4}.example.net:9000/mnt/disk{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

在开发和评估环境中使用 单机多盘 部署。 对于能够容忍节点停机带来数据丢失或不可用的小型存储工作负载，也可以使用该拓扑。

# Set the volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following specifies a single host with 4 drives at the specified location
#
# The command includes the port that the MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio1.example.net:9000/mnt/drive{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

在早期开发和评估环境中使用 单机单盘（“Standalone”）部署。 MinIO 不建议在生产环境中使用 单机部署，因为节点或其存储介质丢失会导致数据丢失。

警告

重要

SNSD 部署不支持通过添加新的 服务器池 来扩展存储。

# Set the volume MinIO uses at startup
#
# The following specifies the drive or folder path

MINIO_VOLUMES="/mnt/drive1/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

请根据部署需要，指定其他 环境变量 或 server 命令行选项。

对于分布式部署，所有节点的 /etc/default/minio 环境文件 必须 完全一致。 可在每个节点上使用 shasum -a 256 /etc/default/minio 等工具验证其是否完全匹配。

6. 启动 MinIO 部署

使用 systemctl start minio 启动部署中的每个节点。

你可以在每个节点上使用 journalctl -u minio 跟踪启动状态。

启动成功后，MinIO 进程会输出一段部署摘要，类似如下：

MinIO 对象存储服务端
Copyright: 2015-2024 MinIO, Inc.
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Version: RELEASE.2024-06-07T16-42-07Z (go1.22.4 linux/amd64)

API: https://minio-1.example.net:9000 https://203.0.113.10:9000 https://127.0.0.1:9000
   RootUser: minioadmin
   RootPass: minioadmin

WebUI: https://minio-1.example.net:9001 https://203.0.113.10:9001 https://127.0.0.1:9001
   RootUser: minioadmin
   RootPass: minioadmin

CLI: https://silo.pgsty.com/zh/reference/minio-mc/#quickstart
   $ mc alias set 'myminio' 'https://minio-1.example.net:9000' 'minioadmin' 'minioadmin'

Docs: https://silo.pgsty.com/zh/docs/
Status:         16 Online, 0 Offline.

在集群启动和同步期间，你可能会看到日志明显增多。

启动失败的常见原因包括：

  • MinIO 进程对指定驱动器没有读、写、列出权限
  • 驱动器不是空的，或其中包含非 MinIO 数据
  • 驱动器未正确格式化或挂载
  • 一个或多个主机无法通过网络访问

遵循我们的检查清单通常可以降低遇到这些或类似问题的风险。

7. 连接到部署

打开浏览器，并通过任一 MinIO 主机名的 :9001 端口访问 MinIO Console 登录页。 例如：https://minio1.example.com:9001。

使用上一步中的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 登录。

MinIO Console 登录页

你可以使用 MinIO Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。 每个 MinIO Server 都包含自身内嵌的 MinIO Console。

请按照本地主机上的 mc 安装说明 完成安装。 运行 mc --version 验证安装结果。

如果你的 MinIO 部署使用第三方或自签名 TLS 证书，请将 CA 文件复制到 ~/.mc/certs/CAs，以便 mc 信任该证书链。

安装完成后，为该 MinIO 部署创建一个别名：

mc alias set myminio https://minio-1.example.net:9000 USERNAME PASSWORD

请根据你的部署修改主机名、用户名和密码。 主机名可以是部署中的任意一个 MinIO 节点。 你也可以指定负责处理部署连接的负载均衡器、反向代理或类似网络控制平面的主机名。

8. 后续步骤

13 - 在裸机上部署 Silo

Silo 可以运行在物理机、虚拟化主机或容器中。当前下载页面提供 Linux、macOS 和 Windows 的 x86-64 与 ARM64 服务端制品；请遵循各平台页面的说明，不要假定所有操作系统拥有相同的生产验证范围。

14 - 扩展分布式 Silo 部署

Silo 支持通过添加新的服务器池扩展现有分布式部署。每个 pool 都会增加集群的总可用存储容量。

扩容并不能提供 Business Continuity/Disaster Recovery (BC/DR) 级别的保护。 虽然每个 pool 都是一组相互独立的服务器，并通过各自的 纠删码集合 提供可用性，但只要其中一个 pool 完全丢失，MinIO 就会停止该部署中所有 pool 的 I/O。 同样地，只要某个 pool 中的某个纠删码集合失去 quorum，该集合中存储的对象就会发生数据丢失，而不受其他纠删码集合或 pool 数量的影响。

新的 服务器池 不必 与现有任一 服务器池 使用相同类型或规格的硬件和软件配置，不过保持一致通常有助于简化集群管理，并让各 pool 间的性能表现更可预测。 新 pool 内的所有驱动器 应当 保持相同类型和容量。 有关如何选择合适配置的完整建议，请参阅 MinIO 的 硬件建议。

若要为单 pool 或多 pool 的 MinIO 部署提供 BC/DR 级别的故障切换与恢复支持，请使用 站点复制。

本页步骤用于为现有 分布式 MinIO 部署增加一个额外的 服务器池。

警告

重要

MinIO 不支持扩展 单机单盘 拓扑。

前提条件

网络与防火墙

部署中的每个节点都应当与其他所有节点具备完整的双向网络访问能力。 对于容器化或编排式基础设施，这可能需要针对 Ingress、负载均衡器等网络和路由组件进行专门配置。 某些操作系统还可能需要设置防火墙规则。 例如，以下命令会在使用 firewalld 的服务器上显式开放 MinIO server 默认 API 端口 9000：

firewall-cmd --permanent --zone=public --add-port=9000/tcp
firewall-cmd --reload

部署中的所有 MinIO server 必须 使用相同的监听端口。

如果你为 MinIO Console 设置了静态端口（例如 :9001）， 则还必须允许外部客户端访问该端口，以确保连接可用。

MinIO 强烈建议 使用负载均衡器管理到集群的连接。 由于部署中的任意 MinIO 节点都可以接收、转发或处理客户端请求，因此负载均衡器应采用 “Least Connections” 算法将请求路由到 MinIO 部署。

以下负载均衡器已知可与 MinIO 良好配合：

如何配置防火墙或负载均衡器以支持 MinIO 不在本步骤范围内。 为 MinIO Server 配置 NGINX 代理 参考页提供了一个将 NGINX 作为反向代理并启用基础负载均衡的基线配置。

连续主机名

MinIO 在创建 服务器池 时，要求 使用扩展表示法 {x...y} 来表示一组连续的 MinIO 主机。 因此，MinIO 要求 使用连续编号的主机名来表示 pool 中的每个 minio server 进程。

在开始本步骤之前，请先创建所需的 DNS 主机名映射。 例如，以下主机名可用于一个 4 节点分布式 服务器池：

  • minio5.example.com
  • minio6.example.com
  • minio7.example.com
  • minio8.example.com

你可以使用扩展表示法 minio{5...8}.example.com 来指定完整的主机名范围。

如何配置 DNS 以支持 MinIO 不在本步骤范围内。

存储要求

以下要求概括了 MinIO 硬件建议中的 存储 一节：

使用本地存储

直连存储（DAS）相比网络存储 （NAS、SAN、 NFS）在性能和一致性方面具有显著优势。 对于主数据或“热”数据，MinIO 强烈建议使用闪存存储（NVMe、SSD）。

磁盘使用 XFS 格式

MinIO 强烈建议为存储配置使用 XFS 格式化的磁盘。 MinIO 在内部测试和验证套件中使用 XFS，因此对其在各种规模下的性能和行为更有信心。

对于 EXT4、BTRFS 或 ZFS 等其他文件系统，MinIO 既不 测试，也不推荐。

使用一致的磁盘类型

MinIO 不区分磁盘类型，也无法从混合存储类型中获益。 每个 pool 都必须使用相同类型的磁盘（NVMe、SSD）

例如，部署一个仅由 NVMe 磁盘组成的 pool。 如果你在其中混用 SSD 或 HDD，MinIO 会将这些磁盘与 NVMe 磁盘一视同仁。 这可能导致性能问题，因为某些磁盘的读写特性不同或更差，无法以与 NVMe 磁盘相同 的速率响应。

使用一致的磁盘容量

MinIO 会将每块磁盘的可用容量限制为 pool 中最小磁盘的容量。

例如，部署一个由相同数量、容量均为 7.68TiB 的 NVMe 磁盘组成的 pool。 如果其中有一块磁盘容量为 3.84TiB，MinIO 会将 pool 中所有磁盘都视为只有 该较小容量。

配置顺序编号的磁盘挂载

MinIO 在创建新的 服务器池 时使用 Go 扩展表示法 {x...y} 表示顺序连续的 磁盘序列，其中 服务器池 中所有节点都挂载了完全相同的一组磁盘。 最好将磁盘挂载路径也配置成顺序序列，以便支持这种表示法。 例如，可按 /mnt/drive-n 的模式挂载磁盘，其中 n 从 1 开始，并随每块 磁盘按 1 递增。

在重启后保持磁盘挂载与映射一致

使用 /etc/fstab 确保节点重启前后磁盘到挂载点的映射保持一致。

非 Linux 操作系统应使用等效的磁盘挂载管理工具。

说明

磁盘独占访问

MinIO 要求 对用于对象存储的磁盘或卷拥有 独占 访问权限。 任何其他进程、软件、脚本或人员都不应直接对提供给 MinIO 的磁盘或卷， 或 MinIO 在其上放置的对象或文件执行 任何 操作。

除非得到 MinIO Engineering 的明确指示，否则不要使用脚本或工具直接修改、 删除或移动这些磁盘上的任何数据分片、校验分片或元数据文件，包括在磁盘或节点 之间迁移这些文件。 这类操作极有可能导致大范围损坏和数据丢失，超出 MinIO 的自愈能力。

满足纠删码校验的最小驱动器数量

MinIO 要求每个 pool 都满足部署的 纠删码 设置。 具体来说，新 pool 的拓扑必须为每个 纠删码集合 提供至少 2 x EC:N 个驱动器，其中 EC:N 是该部署的 Standard 校验存储类。 这一要求可确保新的 服务器池 满足该部署预期的 SLA。

你可以使用 MinIO Erasure Code Calculator 检查新 pool 的 Erasure Code Stripe Size (K+M)。 如果列出的最大值至少为 2 x EC:N，则该 pool 支持部署当前的纠删码校验设置。

时间同步

多节点系统必须保持时间和日期同步，才能维持稳定的节点间操作与交互。 请确保所有节点都定期同步到同一时间服务器。 不同操作系统可采用不同方式同步时间和日期，例如 ntp、timedatectl 或 timesyncd。

请查阅所用操作系统的文档，了解如何在各节点之间建立并维护准确且一致的系统时钟。

先备份集群设置

在开始扩容前，使用 mc admin cluster bucket export 和 mc admin cluster iam export 命令分别为存储桶元数据和 IAM 配置创建快照。 必要时，你可以使用这些快照恢复 存储桶 和 IAM 设置，以从用户错误或流程错误中恢复。

注意事项

写入文件

MinIO 不会自动在新的 服务器池 之间重新平衡对象。 相反，MinIO 会根据某个 pool 的空闲空间占所有可用 pool 总空闲空间的比例，将新的写入操作分配到空闲空间最多的 pool。

用于计算某个 pool 被选中执行写操作概率的公式如下：

FreeSpaceOnPoolA/FreeSpaceOnAllPoolsFreeSpaceOnPoolA / FreeSpaceOnAllPools

假设有一个由三个 pool 组成的部署，总空闲空间为 10 TiB，分布如下：

  • Pool A 有 3 TiB 空闲空间
  • Pool B 有 2 TiB 空闲空间
  • Pool C 有 5 TiB 空闲空间

MinIO 计算各 pool 被用于写入操作的概率如下：

  • Pool A：30% (3TiB/10TiB3TiB / 10TiB)
  • Pool B：20% (2TiB/10TiB2TiB / 10TiB)
  • Pool C：50% (5TiB/10TiB5TiB / 10TiB)

除空闲空间计算外，如果某次写入（含校验）会导致驱动器使用率超过 99%，或已知剩余 inode 数量低于 1000，MinIO 也不会写入该 pool。

如有需要，你可以使用 mc admin rebalance 手动启动重平衡过程。 有关重平衡工作方式的更多信息，请参阅 跨部署管理对象。

同样地，MinIO 不会向正在退役中的 pool 执行写入。

扩容是无中断的

新增 服务器池 需要在大致同一时间重启部署中的 所有 MinIO server 进程。

MinIO 强烈建议同时重启一个部署中的所有 MinIO 服务端进程。 MinIO 操作具有原子性并保持严格一致。 因此，该重启过程不会中断应用或正在进行的操作。

不要 执行“滚动”重启（例如一次只重启一个节点）。

基于容量的规划

MinIO 建议预先规划足以存放 至少 2 年数据的存储容量，并在使用率达到 70% 之前完成准备。 如果过于频繁地执行 服务器池 扩容，或按“just-in-time”方式扩容，通常意味着架构或规划存在问题。

例如，假设某套应用每年预计至少产生 100 TiB 数据，并计划在 3 年后再扩容。 初始 服务器池 为该部署提供了约 500 TiB 的可用存储，使集群能够在安全满足 70% 阈值的同时，为数据增长保留一定缓冲。 理想情况下，新 服务器池 至少 也应提供 500 TiB 的额外存储，以便在下次扩容前维持类似的生命周期。

由于 MinIO 纠删码 需要预留部分存储用于校验，因此总 原始 存储容量必须高于计划中的 可用 容量。 建议使用 MinIO 纠删码计算器，围绕具体纠删码设置进行容量规划。

推荐的操作系统

本教程默认所有运行 MinIO 的主机都使用 推荐的 Linux 操作系统。

部署中的所有主机都应采用一致的 软件配置。

扩展分布式 MinIO 部署

以下步骤将向现有 MinIO 部署中添加一个 服务器池。 每个 Pool 都会在保持集群整体 可用性 的同时，扩展集群的总可用存储容量。

以下所有命令都使用示例值。 请将这些值替换为适用于你部署的实际值。

开始本步骤前，请先阅读 前提条件。

在 退役旧硬件 pool 之前，请先完成所有计划中的硬件扩容。

1) 在新服务器池的每个节点上安装 Silo 二进制

安装与现有 pool 完全相同的公开 Silo 版本。从下载与安装获取 x86-64 或 ARM64 的 RPM、DEB 或独立归档，并在安装前校验摘要。当前 Silo 发布只提供这两种 Linux 架构，因此已删除继承文档中指向未发布 ppc64le 与 s390x 制品的说明。

sudo dnf install ./minio-*.rpm
sudo dpkg -i ./minio_*_amd64.deb

ARM64 主机请使用名称中带 arm64 的软件包。

tar -xzf minio_*_linux_*.tar.gz
sudo install -m 0755 ./minio /usr/local/bin/minio
minio --version

在每个新节点运行 minio --version 并与现有 pool 比对；不要把版本不同的节点加入集群。需要升级时，请遵循systemctl 管理的 Silo 升级流程。

2) 添加 TLS/SSL 证书

当 MinIO 检测到 ${HOME}/.minio/certs 目录中存在有效的 x.509 证书 （.crt）和私钥（.key）时，会自动启用 传输层安全（TLS） 1.2+。

对于由 systemd 管理的部署，请使用运行 MinIO server 进程的用户对应的 $HOME 目录。提供的 minio.service 文件会以 minio-user 身份运行 该进程。前一步已经包含了如何创建该用户及其主目录 /home/minio-user 的说明。

  • 在每个主机上将 TLS 证书放置到 /home/minio-user/.minio/certs 中。
  • 如果 任何 MinIO server 或客户端使用了由未知证书颁发机构签名的证书 （自签或内部 CA），你 必须 将 CA 证书放到该部署中所有 MinIO 主机的 /home/minio-user/.minio/certs/CAs 下。MinIO 会拒绝无效证书 （不受信任、已过期或格式错误）。

如果 minio.service 文件指定了其他用户账户，请改用该账户对应的 $HOME 目录。或者，也可以通过 minio server --certs-dir 命令行参数指定 自定义证书目录。修改 /etc/default/minio 中的 MINIO_OPTS 变量即可设置 此选项。运行 MinIO server 进程的 systemd 用户 必须 对指定目录具有读取和 列目录权限。

有关为 MinIO 配置 TLS 的更具体指导，包括通过 Server Name Indication (SNI) 支持多域名，请参见 网络加密（TLS）。你也可以跳过这一步，以不启用 TLS 的方式 部署。除了早期开发阶段以外，MinIO 强烈 不建议 使用非 TLS 部署。

3) 创建 systemd 服务文件

.deb 或 .rpm 软件包会将以下 systemd 服务文件 安装到 /usr/lib/systemd/system/minio.service。 对于二进制安装方式，请在所有 MinIO 主机上手动创建该文件。

说明

说明

systemd 会先检查 /etc/systemd/... 路径，再检查 /usr/lib/systemd/... 路径， 并使用它找到的第一个文件。 为避免配置冲突或意外选项，请确认该文件仅存在于 /usr/lib/systemd/system/minio.service 路径下。

关于文件路径搜索顺序的详细信息，请参阅 systemd.unit 的 man page。

[Unit]
Description=MinIO
Documentation=https://silo.pgsty.com/zh/docs/
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio-user
Group=minio-user
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

# Disable killing of MinIO by the kernel's OOM killer
OOMScoreAdjust=-1000

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

The minio.service file runs as the minio-user User and Group by default. You can create the user and group using the groupadd and useradd commands. The following example creates the user, group, and sets permissions to access the folder paths intended for use by MinIO. These commands typically require root (sudo) permissions.

groupadd -r minio-user
useradd -M -r -g minio-user minio-user
chown minio-user:minio-user /mnt/disk1 /mnt/disk2 /mnt/disk3 /mnt/disk4

The specified drive paths are provided as an example. Change them to match the path to those drives intended for use by MinIO.

Alternatively, change the User and Group values to another user and group on the system host with the necessary access and permissions.

MinIO publishes additional startup script examples on github.com/minio/minio-service.

To update deployments managed using systemctl, see 升级由 systemctl 管理的 MinIO 部署.

4) 创建服务环境文件

在 /etc/default/minio 创建环境文件。 MinIO 服务会将该文件作为 MinIO 以及 minio.service 文件所用全部 环境变量 的来源。

以下示例假设：

  • 该部署当前只有一个 服务器池，由四台使用连续主机名的 MinIO server 主机构成。

    minio1.example.com   minio3.example.com
minio2.example.com   minio4.example.com

    每台主机都有 4 块本地直连驱动器，挂载点连续：

    /mnt/disk1/minio   /mnt/disk3/minio
/mnt/disk2/minio   /mnt/disk4/minio

  • 新的 服务器池 由八台使用连续主机名的新 MinIO 主机构成：

    minio5.example.com   minio9.example.com
minio6.example.com   minio10.example.com
minio7.example.com   minio11.example.com
minio8.example.com   minio12.example.com

  • 所有主机都具有八块本地直连驱动器，挂载点连续：

    /mnt/disk1/minio  /mnt/disk5/minio
/mnt/disk2/minio  /mnt/disk6/minio
/mnt/disk3/minio  /mnt/disk7/minio
/mnt/disk4/minio  /mnt/disk8/minio

  • 该部署有一个运行在 https://minio.example.net 的负载均衡器，用于管理到所有 MinIO 主机的连接。 在此步骤中，负载均衡器不应将请求路由到新主机，但应已准备好所需的配置更新计划。

请根据你的部署拓扑修改示例：

# Set the hosts and volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following example starts the MinIO server with two 服务器池s.
#
# The space delimiter indicates a seperate 服务器池
#
# The second set of hostnames and volumes is the newly added pool.
# The pool has sufficient stripe size to meet the existing erasure code
# parity of the deployment (2 x EC:4)
#
# The command includes the port on which the MinIO servers listen for each
# 服务器池.

MINIO_VOLUMES="https://minio{1...4}.example.net:9000/mnt/disk{1...4}/minio https://minio{5...12}.example.net:9000/mnt/disk{1...8}/minio"

# Set all MinIO server options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces. The default behavior is dynamic
# port selection.

MINIO_OPTS="--console-address :9001"

# Set the root username. This user has unrestricted permissions to
# perform S3 and administrative API operations on any resource in the
# deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

你可以根据部署需要指定其他 环境变量 或 server 命令行选项。 部署中的所有 MinIO 节点都应包含相同且取值一致的环境变量。

5) 使用扩展后的配置重启 MinIO 部署

在部署中的每个节点上 同时 执行以下命令，以重启 MinIO 服务：

sudo systemctl restart minio.service

Use the following commands to confirm the service is online and functional:

sudo systemctl status minio.service
journalctl -f -u minio.service

MinIO may log an increased number of non-critical warnings while the server processes connect and synchronize. These warnings are typically transient and should resolve as the deployment comes online.

MinIO 强烈建议同时重启一个部署中的所有 MinIO 服务端进程。 MinIO 操作具有原子性并保持严格一致。 因此，该重启过程不会中断应用或正在进行的操作。

不要 执行“滚动”重启（例如一次只重启一个节点）。

6) 后续步骤

  • 更新所有负载均衡器、反向代理或其他网络控制平面，使客户端请求能够路由到 MinIO 分布式部署中的新主机。 虽然 MinIO 会在内部自动管理路由，但由控制平面处理初始连接通常可以减少网络跳数并提升效率。
  • 查看 MinIO Console，确认更新后的集群拓扑并监控性能。

15 - 修改 Silo Tenant

部署完成后，你可以修改租户以调整可变配置项。 有关 MinIO Custom Resource Definition 中可用设置的完整说明，请参阅 MinIO 自定义资源定义。

修改租户的方法取决于你最初如何部署该租户：

对于使用 Kustomize 部署的租户，你可以修改基础 Kustomization 资源，并在包含 kustomization.yaml 的目录上运行 kubectl apply -k 进行应用。

kubectl apply -k ~/kustomization/TENANT-NAME/

请根据本地配置修改 Kustomization 目录路径。

对于使用 Helm 部署的租户，你可以修改基础 values.yaml，并通过 chart 升级租户：

helm upgrade TENANT-NAME minio-operator/tenant -f values.yaml -n TENANT-NAMESPACE

上述命令默认使用的是 MinIO Operator Chart 仓库。 如果你是手动安装 Chart，或使用了不同的仓库名称，请在命令中指定相应的 chart 或名称。

分别将 TENANT-NAME 和 TENANT-NAMESPACE 替换为租户的名称和命名空间。 你可以使用 helm list -n TENANT-NAMESPACE 验证租户名称。

添加受信任的证书颁发机构

MinIO 租户会使用主机系统的受信任根证书存储，校验每个连接客户端提供的 TLS 证书。 MinIO Operator 可以为租户挂载额外的第三方 Certificate Authorities (CA)，以便校验由这些 CA 签发的客户端 TLS 证书。

若要自定义挂载到每个租户 MinIO pod 的受信任 CA，请启用 Custom Certificates 开关。 点击 Add CA Certificate + 按钮即可添加第三方 CA 证书。

如果 MinIO 租户无法在容器操作系统的信任库 或 显式挂载的 CA 中匹配到传入客户端 TLS 证书的签发者，MinIO 会将该连接视为无效并拒绝。

管理租户 Pool

指定 Runtime Class

说明

新增: Console

0.23.1

在为租户添加新 pool 或修改现有 pool 时，你可以为这些 pool 指定 Runtime Class Name。

退役租户 服务器池

MinIO Operator 4.4.13 及更高版本支持退役租户中的 服务器池。 具体而言，你可以遵循 Decommission a Server pool 步骤先从租户中移除该 pool，然后编辑租户 YAML，将该 pool 从 StatefulSet 中移除。 移除租户 pool 时，请确保所有剩余 pool 的 spec.pools.[n].name 字段都具有明确取值。

说明

先下线再新增时保持 pool 顺序

如果你在多 pool 部署中下线了一个 pool，就不能在新 pool 中复用相同的节点编号序列。 例如，假设某个部署包含以下几个 pool：

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{5...8}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}

如果你下线了 minio-{5...8} 这个 pool，就不能再用相同的节点编号新增一个 pool。你必须将新 pool 添加在 minio-{9...12} 之后：

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}
https://minio-{13...16}.example.net/mnt/drive-{1...4}

16 - 以容器方式部署 Silo

本页说明如何在支持容器化进程的操作系统上以容器方式部署 Silo。

本文档假定已安装 Docker、Podman 或其他支持标准容器镜像格式的类似 runtime。已发布的 pgsty/silo 发行镜像使用 Red Hat Universal Base Image 9 Micro。

Silo 容器的功能和性能可能会受到基础操作系统的限制。

本步骤包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

警告

重要

下面的示例仅覆盖用于开发或评估的单机单盘和单机多盘部署；它们不构成 Docker Compose、Docker Swarm 或其他容器编排器上的生产级多机多盘拓扑或升级契约。生产环境的分布式部署应使用经过验证的 Kubernetes Tenant 流程，并针对实际环境验证持久化、网络、故障域与升级。

为便于阅读，示例使用 pgsty/silo:latest。生产环境必须固定经过测试的 Silo 发行标签或镜像摘要；latest 不是版本契约。

SILO 禁止原地自更新，MINIO_UPDATE=off 不会重新启用它。容器升级应替换为经过验证的 SILO 标签或摘要，不应调用 mc admin update。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

Silo 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。你可以在设置集群时配置按对象生效的 parity，也可以让 Silo 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。可使用上游 MinIO 纠删码计算器 比较校验级别，但应将它视为上游规划工具，而不是 Silo 支持契约。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

容器存储

本步骤假定你会将一个或多个专用存储设备挂载到容器中，作为 Silo 的持久化存储。

存储在容器临时路径上的数据会在容器重启或删除时丢失。 使用此类路径的风险需自行承担。

步骤

  1. 启动容器

本步骤提供 Podman 和 Docker 在 rootfull 模式下的说明。 对于 rootless 部署，请参考各 runtime 自身的文档完成配置和容器启动。

对于其他容器 runtime，请参阅对应文档，并使用等效的选项、参数或配置。

以下命令会先在你的主目录中创建一个文件夹，然后使用 Podman 启动 Silo 容器：

mkdir -p ~/silo/data

podman run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v ~/silo/data:/data \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/silo:latest server /data --console-address ":9001"

该命令分别将端口 9000 和 9001 绑定到 S3 API 和 Web Console。

本地驱动器 ~/silo/data 会挂载到容器内的 /data 目录。你可以按需修改 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 变量，以变更 root 登录信息。

对于多驱动器部署，请将每个本地驱动器或其所在文件夹绑定到容器中按顺序编号的路径。 然后修改 minio server 启动命令以指定这些路径：

mkdir -p ~/minio/data-{1..4}

podman run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v /mnt/drive-1:/mnt/drive-1 \
   -v /mnt/drive-2:/mnt/drive-2 \
   -v /mnt/drive-3:/mnt/drive-3 \
   -v /mnt/drive-4:/mnt/drive-4 \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/silo:latest server /mnt/drive-{1...4} --console-address ":9001"

对于 Windows 主机，请使用 Windows 文件系统语义指定本地文件夹路径，例如 C:\minio\:/data。

以下命令会先在你的主目录中创建一个文件夹，然后使用 Docker 启动 Silo 容器：

mkdir -p ~/silo/data

docker run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v ~/silo/data:/data \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/silo:latest server /data --console-address ":9001"

该命令分别将端口 9000 和 9001 绑定到 S3 API 和 Web Console。

本地驱动器 ~/silo/data 会挂载到容器内的 /data 目录。你可以按需修改 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 变量，以变更 root 登录信息。

对于多驱动器部署，请将每个本地驱动器或其所在文件夹绑定到容器中按顺序编号的路径。 然后修改 minio server 启动命令以指定这些路径：

mkdir -p ~/minio/data-{1..4}

docker run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v /mnt/drive-1:/mnt/drive-1 \
   -v /mnt/drive-2:/mnt/drive-2 \
   -v /mnt/drive-3:/mnt/drive-3 \
   -v /mnt/drive-4:/mnt/drive-4 \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/silo:latest server /mnt/drive-{1...4} --console-address ":9001"

对于 Windows 主机，请使用 Windows 文件系统语义指定本地文件夹路径，例如 C:\minio\:/data。

2. 连接到部署

在浏览器中打开 http://localhost:9001 以访问 Silo Console 登录页。

使用上一步中的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 进行登录。

MinIO Console 登录页

你可以使用内嵌 Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。

请按照 Silo 客户端安装说明 安装 mcli，并运行 mcli --version 验证。已发布的独立归档与 Linux 软件包安装 mcli；源码构建和客户端容器则保留 mc 可执行文件名。

安装完成后，为该 Silo 部署创建一个别名：

mcli alias set silo http://localhost:9000 USERNAME PASSWORD

请根据你的部署修改主机名、用户名和密码。

17 - 升级 Silo Tenant

以下步骤用于使用 Kustomize 或 Helm 升级单个 Silo Tenant。请先在非生产 Tenant 中测试确切的服务端镜像、Operator/Chart 版本与回滚流程。

注意

服务端镜像必须保持为 pgsty/silo，并仅使用 Silo 下载页 已发布的标签或摘要。上游 Tenant 默认值使用 MinIO 镜像。同时保留 MINIO_UPDATE=off；继承的原地更新器仍指向上游 MinIO 发布源，不是 Silo 升级路径。

警告

重要

对于使用早于 RELEASE.2024-03-30T09-41-56Z 的 MinIO Image 且启用了 AD/LDAP 的 Tenant，在开始本步骤前，你 必须 先完整阅读 RELEASE.2024-04-18T19-09-19Z 的发布说明。 你必须将该发布说明中记录的额外步骤纳入升级过程。

使用 Kustomize 升级 Tenant

以下步骤使用 Kustomize 和 kubectl CLI 升级 MinIO Tenant。 如果你是使用 Helm 部署 Tenant，请改用 使用 MinIO Helm Chart 升级 Tenant 步骤。

若要使用 Kustomize 升级 Tenant：

如果 Tenant 是通过 Operator Console 部署的，则在升级前还需要额外步骤来创建基础配置文件。

如果 Tenant 是通过 Kustomize 部署的，则基础配置就是原始 Tenant 部署中已有的 kustomization 文件。

请根据 Tenant 的部署方式选择下方标签页：

  1. 创建基础配置文件：

    1. 在一个合适的目录中，使用 kubectl get 将当前 Tenant 配置保存到文件：

      kubectl get tenant/my-tenant -n my-tenant-ns -o yaml > my-tenant-base.yaml

      将 my-tenant 和 my-tenant-ns 替换为待升级 Tenant 的名称和命名空间。

      编辑该文件，删除以下几行：

      • creationTimestamp:
      • resourceVersion:
      • uid:
      • selfLink:（如果存在）

      例如，删除高亮显示的这些行：

      metadata:
  creationTimestamp: "2024-05-29T21:22:20Z"
  generation: 1
  name: my-tenant
  namespace: my-tenant-ns
  resourceVersion: "4699"
  uid: d5b8e468-3bed-4aa3-8ddb-dfe1ee0362da

    2. 在同一目录中，创建一个 kustomization.yaml 文件，其内容类似如下：

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- my-tenant-base.yaml

patches:
- path: upgrade-minio-tenant.yaml

      如果你在上一步为 kubectl get 输出使用了不同的文件名，请将 my-tenant-base.yaml 替换为对应文件名。

  1. 你可以使用原始部署中的 kustomization 文件作为基础配置来升级 Tenant。 如果你已经没有这些文件，请按照 Operator Console-Deployed Tenant 标签页中的说明操作。
  1. 创建一个 upgrade-minio-tenant.yaml 文件，其内容类似如下：
apiVersion: minio.min.io/v2
kind: Tenant

metadata:
  name: my-tenant
  namespace: my-tenant-ns

spec:
  image: pgsty/silo:RELEASE.2026-09-03T13-18-01Z
  env:
    - name: MINIO_UPDATE
      value: "off"

该文件会指示 Kustomize 使用指定镜像升级 Tenant。 该文件名 upgrade-minio-tenant.yaml 必须与上一步创建的 kustomization.yaml 中 patches.path 指定的文件名一致。

将 my-tenant 和 my-tenant-ns 替换为待升级 Tenant 的名称和命名空间。仅当更新的 Silo 发布已公开发布且经过验证时，才替换示例镜像标签。

或者，你也可以按照本地流程直接更新基础配置。 更多信息请参阅 Kustomize Documentation。

  1. 在与上述文件相同的目录中，使用 kubectl apply 将更新后的配置应用到 Tenant：
kubectl apply -k ./

输出类似如下：

tenant.minio.min.io/my-tenant configured

使用 MinIO Helm Chart 升级 Tenant

本步骤使用 Helm Charts 升级现有 MinIO Tenant。

如果你是通过 Kustomize 部署 Tenant，请改用 使用 Kustomize 升级 Tenant 步骤。

  1. 验证现有 Silo Tenant 安装。

    使用 kubectl get all -n TENANT_NAMESPACE 验证所有 Tenant pod 和 service 的健康状态。

    使用 helm list 命令查看该命名空间中已安装的 chart：

    helm list -n TENANT_NAMESPACE

    结果应类似如下：

    NAME            NAMESPACE         REVISION        UPDATED                                 STATUS          CHART           APP VERSION
CHART_NAME      TENANT_NAMESPACE  1               2023-11-01 15:49:58.810412732 -0400 EDT deployed        tenant-5.0.x   v5.0.x

  2. 更新 Operator 仓库

    使用 helm repo update minio-operator 更新 MinIO Operator 仓库。 如果你为 MinIO Operator 仓库设置了不同的别名，请在命令中指定该别名。 你可以使用 helm repo list 查看已安装的仓库列表。

    在更新 Operator 仓库后，使用 helm search 检查最新可用的 chart 版本：

    helm search repo minio-operator

    返回结果应类似如下：

    NAME                            CHART VERSION   APP VERSION     DESCRIPTION
minio-operator/minio-operator   4.3.7           v4.3.7          A Helm chart for MinIO Operator
minio-operator/operator         7.1.1          v7.1.1         A Helm chart for MinIO Operator
minio-operator/tenant           7.1.1          v7.1.1         A Helm chart for MinIO Operator

    minio-operator/minio-operator 是旧版 chart，正常情况下 不应 安装。

  3. 保留并审查 Tenant values

    导出当前发布由用户提供的 values，然后确认该文件保留了所有拓扑、存储、TLS、凭据与调度设置：

    helm get values CHART_NAME -n TENANT_NAMESPACE -o yaml > values.yaml

    将 tenant.image.repository 设为 pgsty/silo，将 tenant.image.tag 固定为经测试的已发布 Silo 版本，并确保 tenant.env 包含 MINIO_UPDATE=off。不得让 Chart 升级默默恢复上游镜像默认值。

  4. 运行已固定的 helm upgrade

    Chart 版本与 Silo 服务端镜像应分别固定，并传入经过审查的 values 文件：

    helm upgrade -n TENANT_NAMESPACE \
  --version 7.1.1 \
  --values values.yaml \
  CHART_NAME minio-operator/tenant

    命令结果应返回成功，并且 REVISION 值会递增。

  5. 验证 Tenant 升级

    检查所有 service 和 pod 是否都已在线，确认实际运行的镜像摘要，并执行经过认证的 S3 读写冒烟测试后再完成发布。

18 - 退役 服务器池

MinIO 支持从包含两个或更多 pool 的部署中退役并移除 服务器池s。 执行退役前，至少必须保留一个具有足够可用空间的 pool，以接收被退役 pool 中的对象。

从 RELEASE.2023-01-18T04-36-38Z 起，MinIO 支持在一条退役命令中排队 多个 pool。 每个被列出的 pool 会立即进入只读状态，但实际排空过程一次只处理一个 pool。

退役功能适用于移除那些相较于当前部署中其他 pool 而言，硬件能力或性能已经不足的旧 服务器池。 MinIO 会根据各 pool 的空闲空间占比，自动将被退役 pool 中的数据迁移到部署中其余 pool。

在退役过程中，MinIO 会像平常一样路由读取操作（例如 GET、LIST、HEAD）。 写入操作（例如 PUT、带版本的 DELETE）会被路由到部署中其余仍处于“active”状态的 pool。 带版本对象在迁移过程中会保持其顺序。

本页步骤用于从至少包含两个 服务器池 的 分布式 MinIO 部署中退役并移除一个或多个 服务器池。

说明

退役是永久性的

一旦 MinIO 开始退役某个 pool，就会将其标记为 永久 非活跃（“draining”）状态。 取消或以其他方式中断退役流程，不会 将该 pool 恢复为 active 状态。 退役多个 pool 时必须格外谨慎。

退役是一项重大的管理操作，规划与执行都需要谨慎对待，并不是轻量或“日常型”的任务。

MinIO SUBNET 用户可以 登录 并创建与退役相关的新工单。 通过 SUBNET 与 MinIO Engineering 协作，可提高退役成功率，包括性能测试和健康诊断。

社区用户可以在 MinIO Community Slack 寻求支持。 社区支持仅为 best-effort，不对响应速度提供任何 SLA。

前提条件

先备份集群设置

在开始退役前，使用 mc admin cluster bucket export 和 mc admin cluster iam export 命令分别为存储桶元数据和 IAM 配置创建快照。 必要时，你可以使用这些快照恢复存储桶/IAM 设置，以从用户错误或流程错误中恢复。

网络与防火墙

部署中的每个节点都应当与其他所有节点具备完整的双向网络访问能力。 对于容器化或编排式基础设施，这可能需要针对 Ingress、负载均衡器等网络和路由组件进行专门配置。 某些操作系统还可能需要设置防火墙规则。 例如，以下命令会在使用 firewalld 的服务器上显式开放 MinIO server 默认 API 端口 9000：

firewall-cmd --permanent --zone=public --add-port=9000/tcp
firewall-cmd --reload

如果你为 MinIO Console 设置了静态端口（例如 :9001）， 则还必须允许外部客户端访问该端口，以确保连接可用。

MinIO 强烈建议 使用负载均衡器管理到集群的连接。 由于部署中的任意 MinIO 节点都可以接收、转发或处理客户端请求，因此负载均衡器应采用 “Least Connections” 算法将请求路由到 MinIO 部署。

以下负载均衡器已知可与 MinIO 良好配合：

如何配置防火墙或负载均衡器以支持 MinIO 不在本步骤范围内。

部署必须具备足够的存储空间

退役过程会将目标 pool 中的对象迁移到部署中的其他 pool。 该部署的总可用存储空间 必须 大于被退役 pool 的总存储量。

使用 纠删码计算器 确认可用存储容量。 然后再减去部署中现有对象已占用的空间。

例如，假设某个部署的已用和空闲存储分布如下：

Pool 1

100TB 已用

200TB 总计

Pool 2

100TB 已用

200TB 总计

Pool 3

100TB 已用

200TB 总计

退役 Pool 1 需要将这 100TB 已用存储分散到其余 pool 上。 Pool 2 和 Pool 3 各自都有 100TB 未使用存储空间，因此可以安全接收 Pool 1 上的数据。

但如果 Pool 1 已满（例如已使用 200TB），退役会将剩余 pool 完全填满，并可能阻止任何后续写入操作。

注意事项

替换 服务器池

对于通过新 pool 硬件替换旧 pool 硬件的升级周期，你应先通过 扩容 添加新 pool，再开始退役旧 pool。 先添加新 pool，有助于退役过程在所有可用 pool（包括现有 pool 和新 pool）之间更均衡地迁移对象。

在退役旧硬件 pool 之前，请先完成所有计划中的 硬件扩容。

退役要求集群拓扑在整个 pool 排空过程中保持稳定。 不要 试图在同一步骤中同时执行扩容和退役变更。

退役可恢复继续执行

如果退役因部署重启、网络故障等瞬时问题而中断，MinIO 会自动继续该过程。

对于人工取消或失败的退役尝试，只有在你手动重新发起退役操作后，MinIO 才会恢复执行。

无论中断原因为何，该 pool 都会持续保持在退役状态。 退役一旦开始，该 pool 永远 无法恢复为 active 状态。

退役是无中断的

移除已退役的 服务器池 需要在大致同一时间重启部署中的 所有 MinIO 节点。

MinIO 强烈建议同时重启一个部署中的所有 MinIO 服务端进程。 MinIO 操作具有原子性并保持严格一致。 因此，该重启过程不会中断应用或正在进行的操作。

不要 执行“滚动”重启（例如一次只重启一个节点）。

退役会忽略已过期对象和尾部 DeleteMarker

从 RELEASE.2023-05-27T05-56-19Z 起，退役过程会忽略那些仅剩 DeleteMarker 版本的对象。 这样可以避免为实际上已被完全删除的对象，在剩余 服务器池 上生成空元数据。

从 RELEASE.2023-06-23T20-26-00Z 起，退役还会忽略那些已根据父存储桶配置的 生命周期规则 过期的对象版本。 从 RELEASE.2023-06-29T05-12-28Z 起，你可以使用 mc admin trace --call decommission 在退役过程中监控被忽略的 delete marker 和已过期对象。

退役过程完成后，你就可以安全关闭该 pool。 由于剩余数据要么已计划删除，要么仅为 DeleteMarker，因此你可以按照内部流程安全清空或销毁这些驱动器。

行为说明

最终列表检查

在退役过程结束时，MinIO 会检查该 pool 上是否还有对象列表。 如果列表为空，MinIO 会将退役标记为成功完成。 如果仍返回任何对象，MinIO 会报错，指出退役过程失败。

如果退役失败，客户应在重新尝试退役前先提交 MinIO SUBNET 工单以获取进一步协助。 没有 SUBNET 订阅的社区用户可以重试退役流程，或通过 MinIO Community Slack 寻求额外支持。 MinIO 的社区支持仅为 best-effort，不提供任何响应速度方面的 SLA。

对已启用 Tiering 的 Server 执行退役

说明

变更: RELEASE.2023-03-20T20-16-18Z

对于已启用并处于活动状态的 tiering 部署，退役会将对象引用迁移到新的 active pool。 应用程序仍可继续对这些对象发出 GET 请求，MinIO 会透明地从远端 tier 中检索对象。

在旧版本 MinIO 中，tiering 配置会阻止退役操作。

退役单个 服务器池

1) 查看 MinIO 部署拓扑

mc admin decommission 命令会返回 MinIO 部署中所有 pool 的列表：

mc admin decommission status myminio

命令返回的输出类似如下：

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Active │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  60 TiB (used) / 100 TiB (total) │ Active │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 100 TiB (total) │ Active │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴────────┘

上例部署共有三个 pool。 每个 pool 都有四台服务器，每台服务器有四块驱动器。

确定要退役的目标 pool，并检查当前容量。 部署中其余 pool 的总容量 必须 足以迁移被退役 pool 中存储的所有对象。

在上述示例中，该部署总存储为 210TiB，其中已使用 110TiB。 第一个 pool（minio-{01...04}）是退役目标，因为它是在 MinIO 部署创建时配置的，并且已经完全写满。 其余较新的 pool 可以吸收该 pool 中的所有对象，而不会显著影响总可用存储。

2) 启动退役过程

说明

退役是永久性的

一旦 MinIO 开始退役某个 pool，就会将其标记为 永久 非活跃（“draining”）状态。 取消或以其他方式中断退役流程，不会 将该 pool 恢复为 active 状态。

在运行以下命令前，请先确认并验证你要退役的是正确的 pool。

使用 mc admin decommission start 命令开始退役目标 pool。 指定部署的 alias，以及待退役 pool 的完整描述，包括所有主机、磁盘和文件路径。

mc admin decommission start myminio/ https://minio-{01...04}.example.net:9000/mnt/disk{1...4}/minio

该示例命令会在 myminio 部署上启动对匹配 服务器池 的退役。

在退役过程中，对于尚未迁移的对象，MinIO 会继续将读取操作（GET、LIST、HEAD）路由到该 pool。 所有新的写入操作（PUT）都会被路由到部署中其余 pool。

此时，负责管理部署连接的负载均衡器、反向代理或其他网络控制组件无需修改其配置。

3) 监控退役过程

使用 mc admin decommission status 命令监控退役过程。

mc admin decommission status myminio

命令返回的输出类似如下：

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬──────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status   │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Draining │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  60 TiB (used) / 100 TiB (total) │ Active   │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 100 TiB (total) │ Active   │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴──────────┘

你可以在命令中指定 服务器池 的描述，以获取更详细的信息：

mc admin decommission status myminio https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio

命令返回的输出类似如下：

Decommissioning rate at 100MiB/sec [1TiB/10TiB]
Started: 30 minutes ago

mc admin decommission status 会在退役完成后将 Status 标记为 Complete。 一旦退役完成，你就可以继续下一步。

如果 Status 显示为 failed，你可以重新运行 mc admin decommission start 命令以恢复该过程。 如果失败持续存在，请使用 mc admin logs 或查看 systemd 日志（例如 journalctl -u minio），以定位更具体的错误。

4) 从部署配置中移除已退役的 Pool

每当一个 pool 完成退役后，你都可以安全地将其从部署配置中移除。 请修改部署中每个剩余 MinIO server 的启动命令，并移除已退役 pool。

.deb 或 .rpm 软件包会将 systemd 服务文件安装到 /lib/systemd/system/minio.service。 对于二进制安装，本步骤默认该文件已按照 安装与管理 流程手动创建。

minio.service 文件使用位于 /etc/default/minio 的环境文件读取配置设置，其中也包括启动配置。 具体来说，MINIO_VOLUMES 变量定义了启动命令：

cat /etc/default/minio | grep "MINIO_VOLUMES"

命令返回的输出类似如下：

MINIO_VOLUMES="https://minio-{1...4}.example.net:9000/mnt/disk{1...4}/minio https://minio-{5...8}.example.net:9000/mnt/disk{1...4}/minio https://minio-{9...12}.example.net:9000/mnt/disk{1...4}/minio"

编辑该环境文件，并从 MINIO_VOLUMES 的值中移除已退役 pool。

5) 更新网络控制平面

更新所有负载均衡器、反向代理或其他网络控制平面，从 MinIO 部署的连接配置中移除已退役的 服务器池。

网络控制平面组件的具体配置说明不在本步骤范围内。

6) 重启 MinIO 部署

在部署中的每个节点上 同时 执行以下命令，以重启 MinIO 服务：

sudo systemctl restart minio.service

Use the following commands to confirm the service is online and functional:

sudo systemctl status minio.service
journalctl -f -u minio.service

MinIO may log an increased number of non-critical warnings while the server processes connect and synchronize. These warnings are typically transient and should resolve as the deployment comes online.

MinIO 强烈建议同时重启一个部署中的所有 MinIO 服务端进程。 MinIO 操作具有原子性并保持严格一致。 因此，该重启过程不会中断应用或正在进行的操作。

不要 执行“滚动”重启（例如一次只重启一个节点）。

部署重新上线后，使用 mc admin info 确认部署中所有剩余 server 的运行状态。

退役多个 服务器池

说明

变更: RELEASE.2023-01-18T04-36-38Z

在执行退役命令时，你可以一次性启动多个 服务器池 的退役过程。

输入该命令后：

  • MinIO 会立即停止对所有待退役 pool 的写访问。
  • 退役一次只处理一个 pool。
  • 每个 pool 完成排空后，MinIO 才会开始排空下一个 pool。

若要通过一条命令退役多个 服务器池，请将每个待退役 服务器池 的完整描述以逗号分隔列表的形式追加到命令中。

执行多 server 退役时，其他所有关于退役的注意事项同样适用。

  • 退役是永久性的。
  • 一旦将这些 pool 标记为退役，你就 无法 恢复它们。
  • 请确认你选择的是预期的 pool。

1) 查看 MinIO 部署拓扑

mc admin decommission 命令会返回 MinIO 部署中所有 pool 的列表：

mc admin decommission status myminio

命令返回的输出类似如下：

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Active │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  95 TiB (used) / 100 TiB (total) │ Active │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 500 TiB (total) │ Active │
│ 4th │ https://minio-{13...16}.example.com:9000/mnt/disk{1...4}/minio │  0  TiB (used) / 500 TiB (total) │ Active │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴────────┘

上例部署共有三个 pool。 每个 pool 都有四台服务器，每台服务器有四块驱动器。

确定要退役的目标 pool，并检查当前容量。 部署中其余 pool 的总容量 必须 足以迁移被退役 pool 中存储的所有对象。

在上述示例中，该部署总存储为 1110TiB，其中已使用 145TiB。

  • 第一个 pool（minio-{01...04}）是第一个退役目标，因为它是在 MinIO 部署创建时配置的，并且已经完全写满。
  • 第二个 pool（minio-{05...08}）是第二个退役目标，因为它同样是在部署创建时配置的，并且已接近写满。
  • 第四个 pool（minio-{13...16}）是一个刚通过 server 扩容加入的新硬件 pool。

第三个和第四个 pool 可以吸收第一个 pool 上的全部对象，而不会显著影响总可用存储。

警告

重要

在开始退役前，请先完成所有新增存储资源所需的 server 扩容。

2) 启动退役过程

说明

退役是永久性的

一旦 MinIO 开始退役这些 pool，就会将它们标记为 永久 非活跃（“draining”）状态。 取消或以其他方式中断退役流程，不会 将这些 pool 恢复为 active 状态。

在运行以下命令前，请先确认并验证你要退役的是正确的 pool。

使用 mc admin decommission start 命令开始退役目标 pool。 指定部署的 alias，以及以逗号分隔的每个待退役 pool 的完整描述，包括所有主机、磁盘和文件路径。

mc admin decommission start myminio/ https://minio-{01...04}.example.net:9000/mnt/disk{1...4}/minio,https://minio-{05...08}.example.net:9000/mnt/disk{1...4}/minio

该示例命令会在 myminio 部署上启动对所列两个匹配 服务器池 的退役。

在退役过程中，对于尚未迁移的对象，MinIO 会继续将读取操作（GET、LIST、HEAD）路由到这些 pool。 所有新的写入操作（PUT）都会被路由到部署中那些未计划退役的其余 pool。

已退役 pool 的排空一次只处理一个 pool，并按顺序依次完成每个 pool 的退役。 排空过程 不会 对所有待退役 pool 并发执行。

此时，负责管理部署连接的负载均衡器、反向代理或其他网络控制组件无需修改其配置。

3) 监控退役过程

使用 mc admin decommission status 命令监控退役过程。

mc admin decommission status myminio

命令返回的输出类似如下：

┌─────┬────────────────────────────────────────────────────────────────┬──────────────────────────────────┬──────────┐
│ ID  │ Pools                                                          │ Capacity                         │ Status   │
│ 1st │ https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio │  10 TiB (used) / 10  TiB (total) │ Draining │
│ 2nd │ https://minio-{05...08}.example.com:9000/mnt/disk{1...4}/minio │  95 TiB (used) / 100 TiB (total) │ Pending  │
│ 3rd │ https://minio-{09...12}.example.com:9000/mnt/disk{1...4}/minio │  40 TiB (used) / 500 TiB (total) │ Active   │
│ 4th │ https://minio-{13...16}.example.com:9000/mnt/disk{1...4}/minio │  0  TiB (used) / 500 TiB (total) │ Active   │
└─────┴────────────────────────────────────────────────────────────────┴──────────────────────────────────┴──────────┘

你可以在命令中指定 服务器池 的描述，以获取更详细的信息：

mc admin decommission status myminio https://minio-{01...04}.example.com:9000/mnt/disk{1...4}/minio

命令返回的输出类似如下：

Decommissioning rate at 100MiB/sec [1TiB/10TiB]
Started: 30 minutes ago

mc admin decommission status 会在退役完成后将 Status 标记为 Complete。 当 MinIO 完成所有 pool 的退役后，你就可以继续下一步。

如果 Status 显示为 failed，你可以重新运行 mc admin decommission start 命令以恢复该过程。 如果失败持续存在，请使用 mc admin logs 或查看 systemd 日志（例如 journalctl -u minio），以定位更具体的错误。

4) 从部署配置中移除已退役的 Pool

退役完成后，你就可以安全地将这些 pool 从部署配置中移除。 请修改部署中每个剩余 MinIO server 的启动命令，并移除已退役 pool。

.deb 或 .rpm 软件包会将 systemd 服务文件安装到 /lib/systemd/system/minio.service。 对于二进制安装，本步骤默认该文件已按照 安装与管理 流程手动创建。

minio.service 文件使用位于 /etc/default/minio 的环境文件读取配置设置，其中也包括启动配置。 具体来说，MINIO_VOLUMES 变量定义了启动命令：

cat /etc/default/minio | grep "MINIO_VOLUMES"

命令返回的输出类似如下：

MINIO_VOLUMES="https://minio-{1...4}.example.net:9000/mnt/disk{1...4}/minio https://minio-{5...8}.example.net:9000/mnt/disk{1...4}/minio https://minio-{9...12}.example.net:9000/mnt/disk{1...4}/minio"

编辑该环境文件，并从 MINIO_VOLUMES 的值中移除已退役 pool。

5) 更新网络控制平面

更新所有负载均衡器、反向代理或其他网络控制平面，从 MinIO 部署的连接配置中移除已退役的 服务器池。

网络控制平面组件的具体配置说明不在本步骤范围内。

6) 重启 MinIO 部署

在部署中的每个节点上 同时 执行以下命令，以重启 MinIO 服务：

sudo systemctl restart minio.service

Use the following commands to confirm the service is online and functional:

sudo systemctl status minio.service
journalctl -f -u minio.service

MinIO may log an increased number of non-critical warnings while the server processes connect and synchronize. These warnings are typically transient and should resolve as the deployment comes online.

MinIO 强烈建议同时重启一个部署中的所有 MinIO 服务端进程。 MinIO 操作具有原子性并保持严格一致。 因此，该重启过程不会中断应用或正在进行的操作。

不要 执行“滚动”重启（例如一次只重启一个节点）。

部署重新上线后，使用 mc admin info 确认部署中所有剩余 server 的运行状态。

19 - 在 macOS 上部署 Silo

本页介绍如何在 Apple macOS 主机上部署 Silo，用于开发与评估。

Silo 分别为 Intel 与 Apple Silicon 发布 macOS 归档。当前项目 CI 在 Linux 上运行，不能据此建立 macOS 支持生命周期保证，因此已删除继承自上游、已经过时的“支持版本”清单。在生产使用前，请验证精确的操作系统版本与工作负载。

本步骤包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

本指南没有验证 macOS 主机上的多机多盘（MNMD）分布式配置。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

MinIO 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。 你可以在设置集群时配置按对象生效的 parity，也可以让 MinIO 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。 可使用 MinIO 纠删码计算器 选择适合你集群的纠删码校验级别。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

步骤

1. 下载 Silo 二进制文件

从下载与安装选择 Intel（darwin_amd64）或 Apple Silicon（darwin_arm64）归档。使用同一发布随附的校验和核验后，解压并安装 minio 兼容二进制：

tar -xzf minio_*_darwin_*.tar.gz
sudo install -m 0755 ./minio /usr/local/bin/minio
minio --version

本页原有 Homebrew 命令安装的是上游 MinIO formula，而不是 Silo，因此已经删除。

2. 启用 TLS 连接

你可以跳过此步骤，以在未启用 TLS 的情况下部署。 MinIO 强烈 不建议 在早期开发之外的场景中进行非 TLS 部署。

为 MinIO 创建或提供 传输层安全 (TLS) 证书，以自动启用 server 与客户端之间的 HTTPS 安全连接。

MinIO 要求私钥和公钥证书的默认文件名分别为 private.key 和 public.crt。 请将证书放入专用目录：

mkdir -p /opt/minio/certs

cp private.key /opt/minio/certs
cp public.crt /opt/minio/certs

MinIO 会根据操作系统/系统默认的受信任证书颁发机构列表来验证客户端证书。 若要启用对第三方证书或内部签发证书的验证，请将 CA 文件放入 /opt/minio/certs/CAs 目录。 CA 文件应包含从叶子证书到根证书的完整信任链，以确保验证成功。

有关为 MinIO 配置 TLS 的更具体指导，包括通过 Server Name Indication (SNI) 支持多域名，请参阅 网络加密（TLS）。

早期开发环境证书

对于本地测试或开发环境，你可以使用 MinIO certgen 生成自签名证书。 例如，以下命令会生成一组带有 IP 和 DNS Subject Alternate Names (SANs) 的自签名证书，这些 SAN 与 MinIO 服务端 主机关联：

certgen -host "localhost,minio-*.example.net"

将生成的 public.crt 和 private.key 放入 /path/to/certs 目录，以为 MinIO 部署启用 TLS。 应用程序可以将 public.crt 作为受信任的证书颁发机构，从而在不禁用证书校验的情况下连接到 MinIO 部署。

3. 创建 MinIO 环境文件

在 /etc/default/minio 创建环境文件。 MinIO 服务将该文件作为 MinIO 以及 minio.service 文件所用全部 环境变量 的来源。

请根据你的部署拓扑修改示例。

在开发和评估环境中使用 单机多盘 部署。 对于能够容忍节点停机带来数据丢失或不可用的小型存储工作负载，也可以使用该拓扑。

# Set the volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following specifies a single host with 4 drives at the specified location
#
# The command includes the port that the MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio1.example.net:9000/mnt/drive{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

在早期开发和评估环境中使用 单机单盘（“Standalone”）部署。 MinIO 不建议在生产环境中使用 单机部署，因为节点或其存储介质丢失会导致数据丢失。

# Set the volume MinIO uses at startup
#
# The following specifies the drive or folder path

MINIO_VOLUMES="/mnt/drive1/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

请根据部署需要，指定其他 环境变量 或 server 命令行选项。

MINIO_CONFIG_ENV_FILE 由服务器自行解析，并不会作为 shell 脚本 source。需要保留 value 首尾空格时必须加引号；命名配置 target 可以包含 my-hook 这样的可见标点。畸形键、NUL 与不可见字符会阻止启动，并返回不含 value 的文件/行号错误。详见配置环境文件不是 Shell 脚本。

4. 启动 MinIO Server

以下命令会启动附着在当前终端/shell 窗口上的 MinIO Server：

export MINIO_CONFIG_ENV_FILE=/etc/default/minio
minio server --console-address :9001

命令输出类似如下：

MinIO 对象存储服务端
Copyright: 2015-2024 MinIO, Inc.
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Version: RELEASE.2024-06-07T16-42-07Z (go1.22.4 linux/amd64)

API: https://minio-1.example.net:9000 https://203.0.113.10:9000 https://127.0.0.1:9000
   RootUser: minioadmin
   RootPass: minioadmin

WebUI: https://minio-1.example.net:9001 https://203.0.113.10:9001 https://127.0.0.1:9001
   RootUser: minioadmin
   RootPass: minioadmin

CLI: https://silo.pgsty.com/zh/reference/minio-mc/#quickstart
   $ mc alias set 'myminio' 'https://minio-1.example.net:9000' 'minioadmin' 'minioadmin'

Docs: https://silo.pgsty.com/zh/docs/
Status:         1 Online, 0 Offline.

API 区块列出了客户端可访问 MinIO S3 API 的网络接口和端口。 Console 区块列出了客户端可访问 MinIO Web Console 的网络接口和端口。

若要在后台运行 MinIO server 进程或以守护进程方式运行，请参阅 macOS 文档中的最佳实践和操作步骤。

5. 连接到部署

打开浏览器，并通过任一 MinIO 主机名的 :9001 端口访问 MinIO Console 登录页。 例如：https://minio1.example.com:9001。

使用上一步中的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 登录。

MinIO Console 登录页

你可以使用 MinIO Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。 每个 MinIO server 都包含自身内嵌的 MinIO Console。

请按照本地主机上的 mc 安装说明 完成安装。 运行 mc --version 验证安装结果。

如果你的 MinIO 部署使用第三方或自签名 TLS 证书，请将 CA 文件复制到 ~/.mc/certs/CAs，以便 mc 信任该证书链。

安装完成后，为该 MinIO 部署创建一个别名：

mc alias set myminio https://minio-1.example.net:9000 USERNAME PASSWORD

请根据你的部署修改主机名、用户名和密码。 主机名可以是部署中的任意一个 MinIO 节点。 你也可以指定负责处理部署连接的负载均衡器、反向代理或类似网络控制平面的主机名。

6. 后续步骤

20 - 从 Gateway 或 Filesystem 模式迁移

背景

MinIO Gateway 及相关 filesystem 模式自 2020 年 7 月起进入功能冻结状态。 2022 年 2 月，MinIO 宣布 弃用 MinIO Gateway。 在该弃用公告中，MinIO 同时宣布该功能将在六个月后移除。

从 RELEASE.2022-10-29T06-21-33Z 起，MinIO Gateway 和相关 filesystem 模式代码已被移除。 仍在使用 standalone 或 filesystem MinIO 模式的部署，一旦升级到 MinIO 服务端 RELEASE.2022-10-29T06-21-33Z 或更高版本，在尝试启动 MinIO 时会报错。

概览

若要升级到 RELEASE.2022-10-29T06-21-33Z 或更高版本，原先使用 standalone 或 filesystem 部署模式的用户必须新建一个 单机单盘 部署，并将设置和内容迁移到新部署中。

本文概述成功启动并迁移到新部署所需的步骤。

警告

重要

单机/文件系统 模式在截至 MinIO Server RELEASE.2022-10-24T18-35-07Z 的所有版本中仍可使用。 若要继续使用 standalone 部署，请安装该 MinIO 服务端版本以及 MinIO Client RELEASE.2022-10-29T10-09-23Z，或安装任意 更早版本 及其对应的 MinIO 客户端。请注意，MinIO Client 的版本应更新，且尽可能接近 MinIO 服务端的版本。

Filesystem 模式部署至少需要升级到 RELEASE.2022-06-25T15-50-16Z，才能使用 MinIO 客户端 的导入和导出命令。 对于截至 RELEASE.2022-06-20T23-13-45Z 的 filesystem 模式部署，可以通过在新部署上手动重建用户、策略、存储桶和其他资源完成迁移。

步骤

说明

说明

你可以通过环境变量和 mc admin config set 设置 MinIO 配置项。 根据你当前的部署方式，可能需要同时获取这两类配置值。

你可以使用 env | grep MINIO_ 查看运行时设置；对于使用 MinIO systemd 服务的部署，也可以直接检查 /etc/default/minio 的内容。

  1. 对于 filesystem 模式部署：

    如有需要，先升级现有部署。

    可接受的最低版本为：

    可接受的最高版本为：

  2. 创建新的 单机单盘 MinIO 部署。

    按照适用于所选操作系统的 安装说明，将安装配置为 单机单盘 (SNSD) 拓扑。

    部署位置可以是所选存储介质上的任意空目录。 如果现有部署不在磁盘根目录上，则同一块磁盘上的新目录也可以用于新部署。 如果现有 standalone 系统指向磁盘根目录，则新部署必须使用另一块独立磁盘。

    如果旧部署和新部署位于同一主机上：

    • 将新部署安装到不同于现有部署的路径。

    • 将新部署的 Console 和 API 端口设置为不同于现有部署的端口。

      以下命令行选项可在启动时设置端口：

    • 对于由 systemd 管理的部署：

      • 复制现有 /etc/default/minio 环境文件，并使用唯一的新文件名。
      • 在新部署的服务文件中，更新 EnvironmentFile 以引用新的环境文件。

    以下步骤会同时使用两个部署中的 mc 命令行工具。 现有 MinIO Client 指旧部署中的 mc。 新的 MinIO 客户端 指新部署中的 mc。

  3. 使用 mc alias set 和新的 MinIO 客户端 为上一步创建的部署添加别名。

    mc alias set NEWALIAS PATH ACCESSKEY SECRETKEY
    • 使用新的 MinIO 客户端。
    • 将 NEWALIAS 替换为要为该部署创建的别名。
    • 将 PATH 替换为新部署的 IP 地址或主机名及端口。
    • 将 ACCESSKEY 和 SECRETKEY 替换为创建新部署时使用的凭证。

  4. 根据部署类型迁移设置：

    • MinIO Gateway 是一个无状态代理服务，为多种后端存储系统提供 S3 API 兼容层。
    • Filesystem 模式部署为单个 MinIO server 进程和单个存储卷提供 S3 访问层。

    迁移配置设置：

    如果你的部署使用 环境变量 作为配置方式，请将现有部署 /etc/default/minio 文件中的环境变量复制到新部署的同名文件中。 你可以省略所有 MINIO_CACHE_* 和 MINIO_GATEWAY_SSE 环境变量，因为这些变量已不再使用。

    如果你使用 mc admin config set 管理配置，请使用新的 MinIO 客户端将现有设置复制到新部署中。

    说明

    说明

    以下 filesystem 模式步骤默认现有 MinIO Client 支持所需的导出命令。 如果不支持，请在新部署上使用新的 MinIO 客户端 手动重建用户、策略、生命周期规则和存储桶。

    1. 导出现有部署的 配置。

      使用现有 MinIO Client 运行 mc admin config export，导出现有 standalone MinIO 部署中定义的配置。

      mc admin config export ALIAS > config.txt
      • 使用现有 MinIO Client。
      • 将 ALIAS 替换为现有 standalone 部署的别名，也就是你要从中导出配置的目标。

    2. 使用新的 MinIO 客户端将现有 standalone 部署的 配置 导入到新部署。

      mc admin config import ALIAS < config.txt
      • 使用新的 MinIO 客户端。
      • 将 ALIAS 替换为新部署的别名。

      如果 import 对某个配置键报错，请在对应行开头加上 # 注释掉，再重新尝试。 完成迁移后，请根据目标 MinIO 服务端版本核对当前配置语法，并使用 mc admin config set 手动设置所需键值。

    3. 使用新的 MinIO 客户端 重启新部署的服务。

      mc admin service restart ALIAS
      • 使用新的 MinIO 客户端。
      • 将 ALIAS 替换为新部署的别名。

    4. 使用现有 MinIO Client 导出现有 standalone 部署的 存储桶元数据。

      以下命令会将现有部署中的存储桶元数据导出到一个 .zip 文件中。

      数据包括：

      • 存储桶目标
      • 生命周期规则
      • 通知
      • 配额
      • 锁
      • 版本控制

      导出内容仅包含存储桶元数据。 此命令不会导出现有部署中的对象数据。

      mc admin cluster bucket export ALIAS
      • 使用现有 MinIO Client。
      • 将 ALIAS 替换为现有部署的别名。

      此命令会生成 cluster-metadata.zip 文件，其中包含每个存储桶的元数据。

    5. 使用新的 MinIO 客户端将 存储桶元数据 导入到新部署。

      以下命令会读取导出的存储桶 .zip 文件内容，并在新部署上创建具有相同配置的存储桶。

      mc admin cluster bucket import ALIAS cluster-metadata.zip
      • 使用新的 MinIO 客户端。
      • 将 ALIAS 替换为新部署的别名。

      该命令会依据现有部署导出的 .zip 文件中的元数据，在新部署上创建具有相同配置的存储桶。

    6. 使用现有 MinIO 客户端将现有 standalone 部署的 IAM 设置 导出到新部署。

      如果你使用的是外部身份与访问管理提供方，请在新部署中重建这些设置及所有关联策略。

      使用以下命令从现有部署导出 IAM 设置。 此命令会导出：

      • 组和组映射
      • STS 用户和 STS 用户映射
      • 策略
      • 用户和用户映射
      mc admin cluster iam export ALIAS
      • 使用现有 MinIO Client。
      • 将 ALIAS 替换为现有部署的别名。

      此命令会生成包含 IAM 数据的 ALIAS-iam-info.zip 文件。

    7. 使用新的 MinIO 客户端将 IAM 设置 导入到新部署。

      使用导出的文件在新部署上创建 IAM 设置。

      mc admin cluster iam import ALIAS alias-iam-info.zip
      • 使用新的 MinIO 客户端。
      • 将 ALIAS 替换为新部署的别名。
      • 将 zip 文件名替换为现有部署导出的文件名。

  5. 使用 mc mirror 迁移存储桶内容。

    在 standalone 部署上，使用现有 MinIO Client 运行带有 --preserve 和 --watch 参数的 mc mirror，将对象迁移到新的 SNSD 部署中。

    mc mirror --preserve --watch SOURCE/BUCKET TARGET/BUCKET
    • 使用现有 MinIO Client。
    • 将 SOURCE/BUCKET 替换为现有 standalone 部署的别名和存储桶。
    • 将 TARGET/BUCKET 替换为新部署的别名和对应存储桶。

  6. 停止所有 S3 或 POSIX 客户端向 standalone 部署写入数据。

  7. 等待 mc mirror 完成所有存储桶的剩余操作。

  8. 停止两个部署的服务。

  9. 使用之前 standalone 部署所用的端口重启新的 MinIO 部署。

    确保应用所有环境变量和运行时配置设置，并验证新部署的行为是否符合预期。

21 - 扩展 Silo Tenant

本步骤说明如何通过在 Kubernetes 基础设施中部署额外的一组 MinIO pod，来扩展现有 MinIO tenant 的可用存储容量。

警告

重要

MinIO Operator Console 已被弃用，并在 Operator 6.0.0 中移除。

有关将通过 Operator Console 安装的 Tenant 迁移到 Kustomization 的说明，请参阅 修改 MinIO Tenant。

前提条件

MinIO Kubernetes Operator

本页步骤 要求 已有一个有效的 MinIO Kubernetes Operator 安装，并假定本地主机也安装了与之匹配的 Operator。本页使用仓库归档前的最终上游版本 v7.1.1，仅作为冻结的兼容基线。

有关部署 MinIO Operator 的完整文档，请参阅 在 Kubernetes 上部署 MinIO。

可用 Worker Nodes

MinIO 会为新的 Tenant pool 部署额外的 minio server pod。 Kubernetes 集群 必须 具备足够的可用 worker node 来调度这些新 pod。

MinIO Operator 提供了用于控制 pod affinity 和 anti-affinity 的配置，以便将调度定向到特定 worker。

持久卷

说明

磁盘独占访问

MinIO 要求 对用于对象存储的磁盘或卷拥有 独占 访问权限。 任何其他进程、软件、脚本或人员都不应直接对提供给 MinIO 的磁盘或卷， 或 MinIO 在其上放置的对象或文件执行 任何 操作。

除非得到 MinIO Engineering 的明确指示，否则不要使用脚本或工具直接修改、 删除或移动这些磁盘上的任何数据分片、校验分片或元数据文件，包括在磁盘或节点 之间迁移这些文件。 这类操作极有可能导致大范围损坏和数据丢失，超出 MinIO 的自愈能力。

MinIO 可以使用任何支持 ReadWriteOnce 访问模式的 Kubernetes Persistent Volume (PV)。 MinIO 的一致性保证依赖于 ReadWriteOnce 提供的独占存储访问。

对于节点具有 Direct Attached Storage 的 Kubernetes 集群，MinIO 强烈建议使用 DirectPV CSI driver。 DirectPV 提供了一个分布式持久卷管理器，可在 Kubernetes 节点之间发现、格式化、挂载、调度和监控驱动器。 DirectPV 解决了手动配置和监控 local persistent volumes 的局限性。

说明

说明

EKS 上的 MinIO Tenant 必须使用 EBS CSI Driver 来预配所需的底层持久卷。 MinIO 强烈建议使用基于 SSD 的 EBS 卷以获得最佳性能。 有关 EBS 资源的更多信息，请参阅 EBS Volume Types。

步骤

MinIO Operator 支持通过添加额外 pool 来扩展 MinIO Tenant。

  1. 检查描述 Tenant 对象（tenant.yaml）的 Kustomization 对象。

    spec.pools 数组描述当前的 pool 拓扑。

  2. 在 spec.pools 数组中新增一个条目。

    新 pool 必须反映你期望的 Worker node、每个 server 的卷数量、存储类以及 affinity/scheduler 设置组合。 有关与 Pool 相关配置项的更完整文档，请参阅 MinIO 自定义资源定义。

  3. 应用更新后的 Tenant 配置

    使用 kubectl apply 命令更新 Tenant：

    kubectl apply -k ~/kustomization/TENANT-NAME

    请根据本地配置修改 Kustomization 目录路径。

  1. 检查 Helm values.yaml 文件。

    tenant.pools 数组描述当前的 pool 拓扑。

  2. 在 tenant.pools 数组中新增一个条目。

    新 pool 必须反映你期望的 Worker node、每个 server 的卷数量、存储类以及 affinity/scheduler 设置组合。 有关与 Pool 相关配置项的更完整文档，请参阅 租户 Helm Charts。

  3. 应用更新后的 Tenant 配置

    使用 helm upgrade 命令更新 Tenant：

    helm upgrade TENANT-NAME minio-operator/tenant -f values.yaml -n TENANT-NAMESPACE

    上述命令默认使用的是 MinIO Operator Chart 仓库。 如果你是手动安装 Chart，或使用了不同的仓库名称，请在命令中指定相应的 chart 或名称。

    分别将 TENANT-NAME 和 TENANT-NAMESPACE 替换为 Tenant 的名称和命名空间。 你可以使用 helm list -n TENANT-NAMESPACE 验证 Tenant 名称。

你可以使用 kubectl get events -n TENANT-NAMESPACE --watch 监控扩容进度。 MinIO Operator 会更新 service，以便在新节点之间正确路由连接。 如果你使用了自定义 service、route、ingress 或类似 Kubernetes 网络组件，可能还需要针对新的 pod 主机名范围更新这些组件。

22 - 在 Windows 上部署 Silo

本页介绍如何在 Microsoft Windows 主机上部署 Silo，用于开发与评估。

Silo 为 x86-64 与 ARM64 发布 Windows 归档。当前项目 CI 在 Linux 上运行，没有覆盖 Windows 实机运行时，因此已删除继承自上游、已经过时的“正式支持 Windows 版本”清单。在生产使用前，请验证精确的 Windows 版本、文件系统、服务包装方式与工作负载。

本步骤包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

本指南没有验证 Windows 主机上的多机多盘（MNMD）分布式配置。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

MinIO 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。 你可以在设置集群时配置按对象生效的 parity，也可以让 MinIO 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。 可使用 MinIO 纠删码计算器 选择适合你集群的纠删码校验级别。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

步骤

1. 下载 Silo 二进制文件

从下载与安装获取与架构对应的 Windows 归档，使用同一发布随附的校验和核验后，解压得到 minio.exe。

下一步说明如何运行该文件。请从 PowerShell 或命令提示符启动服务端，不要在资源管理器中双击运行。

2. 启动 MinIO Server

在 PowerShell 或命令提示符中，切换到可执行文件所在目录，或将 minio.exe 文件路径加入系统 $PATH。

对于带有多个驱动器的 Windows 主机，你可以指定一组顺序驱动器，以便在 单机多盘 (SNMD) 拓扑中配置 MinIO：

.\minio.exe server {D...G}:\minio --console-address :9001

minio server 进程会将输出打印到系统控制台，类似如下：

API: http://192.0.2.10:9000  http://127.0.0.1:9000
RootUser: minioadmin
RootPass: minioadmin

Console: http://192.0.2.10:9001 http://127.0.0.1:9001
RootUser: minioadmin
RootPass: minioadmin

Command-line: https://silo.pgsty.com/zh/reference/minio-mc/
   $ mc alias set myminio http://192.0.2.10:9000 minioadmin minioadmin

Documentation: https://silo.pgsty.com/zh/docs/

WARNING: Detected default credentials 'minioadmin:minioadmin', we recommend that you change these values with 'MINIO_ROOT_USER' and 'MINIO_ROOT_PASSWORD' environment variables.

该进程绑定到当前 PowerShell 或命令提示符窗口。 关闭窗口会停止 server 并结束该进程。

使用此命令在 C:\minio 文件夹中启动本地 MinIO 实例。 你可以将 C:\minio 替换为本地主机上的其他驱动器或文件夹路径。

.\minio.exe server C:\minio --console-address :9001

minio server 进程会将输出打印到系统控制台，类似如下：

API: http://192.0.2.10:9000  http://127.0.0.1:9000
RootUser: minioadmin
RootPass: minioadmin

Console: http://192.0.2.10:9001 http://127.0.0.1:9001
RootUser: minioadmin
RootPass: minioadmin

Command-line: https://silo.pgsty.com/zh/reference/minio-mc/
   $ mc alias set myminio http://192.0.2.10:9000 minioadmin minioadmin

Documentation: https://silo.pgsty.com/zh/docs/

WARNING: Detected default credentials 'minioadmin:minioadmin', we recommend that you change these values with 'MINIO_ROOT_USER' and 'MINIO_ROOT_PASSWORD' environment variables.

该进程绑定到当前 PowerShell 或命令提示符窗口。 关闭窗口会停止 server 并结束该进程。

3. 使用浏览器连接到 MinIO 服务端

使用浏览器（例如 Microsoft Edge）访问 http://127.0.0.1:9001，或访问 minio server 命令输出中列出的任意 Console 地址，以打开 MinIO 控制台。 例如，示例输出中的 Console: http://192.0.2.10:9001 http://127.0.0.1:9001 表示有两个可用于连接 Console 的地址。

尽管端口 9000 用于连接 API，MinIO 仍会自动将浏览器访问重定向到 MinIO Console。

使用输出中显示的 RootUser 和 RootPass 用户凭证登录 Console。 默认值为 minioadmin | minioadmin。

MinIO Console 显示登录界面

你可以使用 MinIO Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。 每个 MinIO server 都包含自身内嵌的 MinIO Console。

MinIO Console 显示存储桶起始界面

更多信息请参阅 MinIO 控制台 文档。

4. (可选) 安装 Silo 客户端

Silo 客户端允许你从 PowerShell 与部署交互。

从下载与安装获取 Windows 客户端归档，校验后解压得到 mcli.exe。

在命令提示符或 PowerShell 中运行：

\path\to\mcli.exe --help

通过已安装的 mcli.exe 执行 mc alias set，即可认证并连接到部署。

mcli.exe alias set local http://127.0.0.1:9000 minioadmin minioadmin
mcli.exe admin info local

mc alias set 需要四个参数：

  • 别名名称
  • MinIO server 的主机名或 IP 地址及端口
  • MinIO 用户 的 Access Key
  • MinIO 用户 的 Secret Key

有关此命令的更多细节，请参阅 mc alias set。

5. 后续步骤

23 - 删除 Silo Tenant

前提条件

MinIO Kubernetes Operator

本页步骤 要求 已正确安装 MinIO Kubernetes Operator，并假定本地主机也安装了与之匹配的 Operator。本页使用仓库归档前的最终上游版本 v7.1.1，仅作为冻结的兼容基线。

有关部署 MinIO Operator 的完整文档，请参阅 在 Kubernetes 上部署 MinIO。

Tenant 持久卷声明

Tenant 生成的每个 Persistent Volume Claim（PVC）在删除时的行为，取决于其绑定的 Persistent Volume（PV）所配置的 Reclaim Policy：

  • 对于 recycle 或 delete 策略，命令会删除 PVC。
  • 对于 retain 策略，命令会保留 PVC。
注意

警告

无论是自动还是手动删除底层 PV，都会导致 MinIO Tenant 上存储的对象丢失。

在删除 Tenant 之前，请充分确认已存储数据的安全性。

步骤

你可以通过删除命名空间来删除使用 Kustomization 安装的 Tenant：

kubectl delete namespace TENANT-NAMESPACE

将 TENANT-NAMESPACE 替换为要删除的命名空间名称。

警告

重要

在运行命令前，请确认你指定的是正确的待删除命名空间。 命名空间删除发生在 Kubernetes 层，因此 MinIO Operator 无法干预或撤销该操作。

你可以使用 helm uninstall 命令删除通过 Helm 安装的 Tenant：

helm uninstall --namespace MINIO-TENANT TENANT-NAME minio-operator/tenant

上述命令默认使用的是 MinIO Operator Chart 仓库。 如果你是手动安装 Chart，或使用了不同的仓库名称，请在命令中指定相应的 chart 或名称。

分别将 TENANT-NAME 和 TENANT-NAMESPACE 替换为 Tenant 的名称和命名空间。 你可以使用 helm list -n TENANT-NAMESPACE 验证 Tenant 名称。

24 - 升级旧版 MinIO Operator

MinIO 为旧版 MinIO Operator 支持以下升级路径：

当前版本 支持升级到
5.0.15 及更高版本 7.1.1
5.0.0 到 5.0.14 5.0.15
4.2.3 到 4.5.7 4.5.8
4.0.0 到 4.2.2 4.2.3
3.X.X 4.2.2

如果要从 4.5.7 或更早版本升级到 7.1.1，你必须先升级到 4.5.8，然后再升级到 5.0.15。 根据你当前的版本，可能需要经过一个或多个中间升级步骤才能到达 v4.5.8。

升级到 5.0.15 后，请参阅 升级 MinIO Operator 继续升级到最新版本。

将 MinIO Operator 4.5.8 及更高版本升级到 5.0.15

说明

前提条件

本流程需要满足以下条件：

  • 你已有一个运行 4.5.8 或更高版本的 MinIO Operator 部署
  • 你的 Kubernetes 集群版本为 1.21.0 或更高
  • 你的本地主机已安装 kubectl，并已配置好对 Kubernetes 集群的访问

本流程将 MinIO Operator 从任意 4.5.8 及以上版本升级到 5.0.15

Tenant 自定义资源定义变更

以下变更适用于 Operator v5.0.0 或更高版本：

  • .spec.s3 字段被 .spec.features 字段取代。

  • .spec.credsSecret 字段被 .spec.configuration 字段取代。

    .spec.credsSecret 应保存 MinIO 部署中所有包含敏感信息的环境变量，这些变量不应出现在 .spec.env 中。 该变更会影响 Tenant CRD，且只影响直接编辑 tenant YAML 的用户，例如通过 Helm 或 Kustomize 管理的用户。

  • Log Search API （.spec.log）和 Prometheus （.spec.prometheus）部署都已移除。 不过，现有部署会保留为独立的 deployment 或 statefulset 继续运行，不再与 Tenant CR 关联。 删除 Tenant CRD 不会 级联删除日志或 Prometheus 部署。

    警告

    重要

    MinIO 建议你后续创建单独的 YAML 文件来管理这些部署。

Log Search 和 Prometheus

最新版本的 Operator 已将 Log Search 和 Prometheus 从内置工具中移除。 以下步骤会备份现有 YAML 文件、执行一些清理操作，并给出继续使用其中一个或两个功能的方法。

  1. 备份 Prometheus 和 Log Search 的 YAML 文件。

    export TENANT_NAME=myminio
export NAMESPACE=mynamespace
kubectl -n $NAMESPACE get secret $TENANT_NAME-log-secret -o yaml > $TENANT_NAME-log-secret.yaml
kubectl -n $NAMESPACE get cm $TENANT_NAME-prometheus-config-map -o yaml > $TENANT_NAME-prometheus-config-map.yaml
kubectl -n $NAMESPACE get sts $TENANT_NAME-prometheus -o yaml > $TENANT_NAME-prometheus.yaml
kubectl -n $NAMESPACE get sts $TENANT_NAME-log -o yaml > $TENANT_NAME-log.yaml
kubectl -n $NAMESPACE get deployment $TENANT_NAME-log-search-api -o yaml > $TENANT_NAME-log-search-api.yaml
kubectl -n $NAMESPACE get svc $TENANT_NAME-log-hl-svc -o yaml > $TENANT_NAME-log-hl-svc.yaml
kubectl -n $NAMESPACE get svc $TENANT_NAME-log-search-api -o yaml > $TENANT_NAME-log-search-api-svc.yaml
kubectl -n $NAMESPACE get svc $TENANT_NAME-prometheus-hl-svc -o yaml > $TENANT_NAME-prometheus-hl-svc.yaml
    • 将 myminio 替换为正在升级的 operator 部署中对应 tenant 的名称。
    • 将 mynamespace 替换为正在升级的 operator 部署中该 tenant 所在的命名空间。

    对每个 tenant 重复执行。

  2. 对所有 tenant 备份出的文件删除 .metadata.ownerReferences。

  3. (可选) 如果要继续使用 Log Search API 和 Prometheus，请在 tenant 的 YAML 规范文件中，将以下变量添加到 .spec.env 下。

    使用以下命令编辑 tenant：

    kubectl edit tenants <TENANT-NAME> -n <TENANT-NAMESPACE>
    • 将 <TENANT-NAME> 替换为要修改的 tenant 名称。
    • 将 <TENANT-NAMESPACE> 替换为要修改的 tenant 所在命名空间。

    在文件的 .spec.env 下添加以下值：

    - name: MINIO_LOG_QUERY_AUTH_TOKEN
  valueFrom:
    secretKeyRef:
      key: MINIO_LOG_QUERY_AUTH_TOKEN
      name: <TENANT_NAME>-log-secret
- name: MINIO_LOG_QUERY_URL
  value: http://<TENANT_NAME>-log-search-api:8080
- name: MINIO_PROMETHEUS_JOB_ID
  value: minio-job
- name: MINIO_PROMETHEUS_URL
  value: http://<TENANT_NAME>-prometheus-hl-svc:9001
    • 将 name 或 value 行中的 <TENANT_NAME> 替换为你的 tenant 名称。

操作步骤

以下步骤使用 Kustomize 升级 MinIO Operator。

对于通过 MinIO Kubernetes Plugin 安装的 Operator 5.0.1 到 5.0.14 版本，请按照下方 Kustomize 步骤先升级到 5.0.15 或更高版本。 如果你是通过 Helm 安装 Operator，请改用 使用 Helm 升级 步骤。

  1. (可选) 将每个 MinIO Tenant 升级到最新稳定版 MinIO。

    定期升级 MinIO 可确保 Tenant 获得最新特性和性能改进。 在将升级应用到生产 Tenant 之前，请先在 Dev 或 QA Tenant 等较低环境中验证。 升级 MinIO Tenant 的具体流程请参阅 升级 MinIO Tenant。

  2. 验证现有 Operator 安装。 使用 kubectl get all -n minio-operator 验证所有 Operator pod 和 service 的健康状态与运行状态。

    如果你将 Operator 安装到了自定义命名空间，请在命令中指定 -n <NAMESPACE>。

    你可以通过获取该命名空间中某个 operator pod 的对象规范，确认当前安装的 Operator 版本。 以下示例使用 jq 工具从 kubectl 输出中过滤出所需信息：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

    输出类似如下：

    {
   "env": [
      {
         "name": "CLUSTER_DOMAIN",
         "value": "cluster.local"
      }
   ],
   "image": "minio/operator:v5.0.x",
   "imagePullPolicy": "IfNotPresent",
   "name": "minio-operator"
}

    如果本地主机未安装 jq，你也可以只执行命令的前半部分，然后在输出中查找 spec.containers 段落。

  3. 使用 Kustomize 升级 Operator

    以下命令会将 Operator 升级到 5.0.15：

    kubectl apply -k github.com/minio/operator/?ref=v5.0.15

    在下面的示例输出中，行尾的 configured 表示更新后的 CRD 已应用对应变更：

    namespace/minio-operator configured
customresourcedefinition.apiextensions.k8s.io/miniojobs.job.min.io configured
customresourcedefinition.apiextensions.k8s.io/policybindings.sts.min.io configured
customresourcedefinition.apiextensions.k8s.io/tenants.minio.min.io configured
serviceaccount/console-sa unchanged
serviceaccount/minio-operator unchanged
clusterrole.rbac.authorization.k8s.io/console-sa-role unchanged
clusterrole.rbac.authorization.k8s.io/minio-operator-role unchanged
clusterrolebinding.rbac.authorization.k8s.io/console-sa-binding unchanged
clusterrolebinding.rbac.authorization.k8s.io/minio-operator-binding unchanged
configmap/console-env unchanged
secret/console-sa-secret configured
service/console unchanged
service/operator unchanged
service/sts unchanged
deployment.apps/console configured
deployment.apps/minio-operator configured

  4. 验证 Operator 升级结果

    你可以使用前面相同的 kubectl 命令检查新的 Operator 版本：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

以下步骤使用 Helm 升级现有的 MinIO Operator 安装。

如果你是使用 Kustomize 安装 Operator，请改用 使用 Kustomize 升级 步骤。

  1. (可选) 将每个 MinIO Tenant 升级到最新稳定版 MinIO。

    定期升级 MinIO 可确保 Tenant 获得最新特性和性能改进。 在将升级应用到生产 Tenant 之前，请先在 Dev 或 QA Tenant 等较低环境中验证。 升级 MinIO Tenant 的具体流程请参阅 升级 MinIO Tenant。

  2. 验证现有 Operator 安装。

    使用 kubectl get all -n minio-operator 验证所有 Operator pod 和 service 的健康状态与运行状态。

    如果你将 Operator 安装到了自定义命名空间，请在命令中指定 -n <NAMESPACE>。

    使用 helm list 查看该命名空间中已安装的 chart：

    helm list -n minio-operator

    结果应类似如下：

    NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
operator        minio-operator  1               2023-11-01 15:49:54.539724775 -0400 EDT deployed        operator-5.0.x v5.0.x

    你也可以直接查看 operator pod 以确认已安装版本。 以下示例使用 jq 工具从 kubectl 输出中过滤出所需信息：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

    输出类似如下：

    {
   "env": [
      {
         "name": "CLUSTER_DOMAIN",
         "value": "cluster.local"
      }
   ],
   "image": "minio/operator:v5.0.x",
   "imagePullPolicy": "IfNotPresent",
   "name": "minio-operator"
}

    如果本地主机未安装 jq，你也可以只执行命令的前半部分，然后在输出中查找 spec.containers 段落。

  3. 更新 Operator 仓库

    使用 helm repo update minio-operator 更新 MinIO Operator 仓库。 如果你为 MinIO Operator 仓库设置了不同别名，请在命令中使用该别名替代 minio-operator。 你可以使用 helm repo list 查看当前已安装的仓库。

    更新 Operator 仓库后，使用 helm search 检查最新可用的 chart 版本：

    helm search repo minio-operator

    返回结果应类似如下：

    NAME                            CHART VERSION   APP VERSION     DESCRIPTION
minio-operator/minio-operator   4.3.7           v4.3.7          A Helm chart for MinIO Operator
minio-operator/operator         7.1.1          v7.1.1         A Helm chart for MinIO Operator
minio-operator/tenant           7.1.1          v7.1.1         A Helm chart for MinIO Operator

    minio-operator/minio-operator 是旧版 chart，正常情况下 不应 安装。

  4. 运行 helm upgrade

    Helm 会使用最新 chart 升级 MinIO Operator：

    helm upgrade -n minio-operator \
  operator minio-operator/operator

    如果你将 MinIO Operator 安装到了其他命名空间，请在 -n 参数中指定该命名空间。

    如果你使用的安装名不是 operator，请将上面的值替换为实际安装名。

    命令应返回成功，并且 REVISION 值会递增。

  5. 验证 Operator 升级结果

    你可以使用前面相同的 kubectl 命令检查新的 Operator 版本：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

将 MinIO Operator 4.2.3 到 4.5.7 升级到 4.5.8

前提条件

本流程需要满足以下条件：

  • 你已有一个运行 4.2.3 到 4.5.7 的 MinIO Operator 部署
  • 你的 Kubernetes 集群版本为 1.19.0 或更高
  • 你的本地主机已安装 kubectl，并已配置好对 Kubernetes 集群的访问

操作步骤

本流程会将 MinIO Operator 从 4.2.3 到 4.5.7 升级到 4.5.8。 随后你可以再从 4.5.8 升级到 5.0.15。

  1. (可选) 将每个 MinIO Tenant 升级到最新稳定版 MinIO。

    定期升级 MinIO 可确保 Tenant 获得最新特性和性能改进。

    在将升级应用到生产 Tenant 之前，请先在 Dev 或 QA Tenant 等较低环境中验证。

    升级 MinIO Tenant 的具体流程请参阅 升级 MinIO Tenant。

  2. 验证现有 Operator 安装。

    使用 kubectl get all -n minio-operator 验证所有 Operator pod 和 service 的健康状态与运行状态。

    如果你将 Operator 安装到了自定义命名空间，请在命令中指定 -n <NAMESPACE>。

    你可以通过获取该命名空间中某个 operator pod 的对象规范，确认当前安装的 Operator 版本。 以下示例使用 jq 工具从 kubectl 输出中过滤出所需信息：

    kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

    输出类似如下：

    {
   "env": [
      {
         "name": "CLUSTER_DOMAIN",
         "value": "cluster.local"
      }
   ],
   "image": "minio/operator:v4.5.1",
   "imagePullPolicy": "IfNotPresent",
   "name": "minio-operator"
}

  3. 下载最新稳定版 MinIO Kubernetes Plugin

    你可以通过 Kubernetes Krew 插件管理器安装 MinIO 插件， 也可以手动下载插件二进制并安装到本地主机：

    Krew 是由 Kubernetes SIG CLI group 开发的 kubectl 插件管理器。 具体安装方法请参阅 krew installation documentation。 Krew 适用于 Linux、macOS 和 Windows 操作系统。

    你可以使用以下命令，通过 Krew 安装 MinIO kubectl 插件：

    kubectl krew update
kubectl krew install minio

    如果要通过 Krew 更新 MinIO 插件，请使用以下命令：

    kubectl krew upgrade minio

    你可以将 MinIO kubectl 插件下载到本地系统路径中。 kubectl CLI 会自动发现并运行兼容插件。

    以下代码会下载最新版本的 MinIO Kubernetes 插件， 并将其安装到系统路径中：

    curl https://github.com/minio/operator/releases/download/v5.0.14/kubectl-minio_5.0.14_linux_amd64 -o kubectl-minio
chmod +x kubectl-minio
mv kubectl-minio /usr/local/bin/

    上述 mv 命令可能需要 sudo 提权， 具体取决于当前认证用户的权限。

    运行以下命令验证插件是否安装成功：

    kubectl minio version

    输出应显示 Operator 版本为 5.0.14。

    你可以将 MinIO kubectl 插件下载到本地系统路径中。 kubectl CLI 会自动发现并运行兼容插件。

    以下 PowerShell 命令会下载最新版本的 MinIO Kubernetes 插件， 并将其安装到系统路径中：

    Invoke-WebRequest -Uri "https://github.com/minio/operator/releases/download/v5.0.14/kubectl-minio_5.0.14_windows_amd64.exe" -OutFile "C:\kubectl-plugins\kubectl-minio.exe"

    请确保插件目录路径已包含在 Windows PATH 中。

    运行以下命令验证插件是否安装成功：

    kubectl minio version

    输出应显示 Operator 版本为 5.0.14。

  4. 运行初始化命令以升级 Operator

    使用 kubectl minio init 命令升级现有 MinIO Operator 安装：

    kubectl minio init

  5. 验证 Operator 升级结果

    你可以通过前一步中查看 Operator Pod 对象规范的方法，确认升级后的 Operator 版本。

将 MinIO Operator 4.0.0 到 4.2.2 升级到 4.2.3

前提条件

本流程假定满足以下条件：

  • 你已有一个运行 4.0.0 到 4.2.2 任意版本的 MinIO Operator 部署
  • 你的 Kubernetes 集群版本为 1.19.0 或更高
  • 你的本地主机已安装 kubectl，并已配置好对 Kubernetes 集群的访问

操作步骤

本流程涵盖将运行 4.0.0 到 4.2.2 任意版本的 MinIO Operator 部署升级到 4.2.3 所需的步骤。 随后你可以执行 将 MinIO Operator 从 5.0.15 升级到 7.1.1，完成升级到 7.1.1。

从 4.0.0 到 4.2.2 的安装无法直接升级到 7.1.1。

  1. (可选) 将每个 MinIO Tenant 升级到最新稳定版 MinIO。

    定期升级 MinIO 可确保 Tenant 获得最新特性和性能改进。 在将升级应用到生产 Tenant 之前，请先在 Dev 或 QA Tenant 等较低环境中验证。

    升级 MinIO Tenant 的具体流程请参阅 升级 MinIO Tenant。

  2. 检查每个 Tenant Pool 的 Security Context

    使用以下命令检查每个受管 MinIO Tenant 的规范：

    kubectl get tenants <TENANT-NAME> -n <TENANT-NAMESPACE> -o yaml

    如果某个 Tenant 不存在 spec.pools.securityContext 字段，则该 tenant pod 很可能以 root 身份运行。

    从 4.2.3 及后续版本开始，作为 Operator 升级的一部分，pod 将使用受限权限集运行。 但对于以 root 身份运行 pod 的 Tenant，可能会因为 security context 不匹配而启动失败。 你可以为这些 Tenant 显式设置允许 pod 以 root 身份运行的 Security Context：

    securityContext:
  runAsUser: 0
  runAsGroup: 0
  runAsNonRoot: false
  fsGroup: 0

    你可以使用以下命令编辑 tenant 并应用变更：

    kubectl edit tenants <TENANT-NAME> -n <TENANT-NAMESPACE>
# 按需修改 securityContext

    更多有关 Kubernetes Security Context 的信息，请参阅 Pod Security Standards。

  3. 升级到 Operator 4.2.3

    下载 MinIO Kubernetes Plugin 4.2.3，并使用它升级 Operator。 在浏览器中打开 https://github.com/minio/operator/releases/tag/v4.2.3，下载与你本地主机操作系统匹配的二进制文件。

    例如，使用 Intel 或 AMD 处理器的 Linux 主机可以运行以下命令：

    wget https://github.com/minio/operator/releases/download/v4.2.3/kubectl-minio_4.2.3_linux_amd64 -o kubectl-minio_4.2.3
chmod +x kubectl-minio_4.2.3
./kubectl-minio_4.2.3 init

  4. 验证所有 Tenant 和 Operator pod

    检查 Operator 和 MinIO Tenant 命名空间，确保所有 pod 和 service 都已成功启动。

    例如：

    kubectl get all -n minio-operator
kubectl get pods -l "v1.min.io/tenant" --all-namespaces

  5. 升级到 7.1.1

    按照 将 MinIO Operator 从 5.0.15 升级到 7.1.1 中的流程，升级到仓库归档前的最终上游版本 v7.1.1。

将 MinIO Operator 3.0.0 到 3.0.29 升级到 4.2.2

前提条件

本流程假定满足以下条件：

  • 你已有一个运行 3.X.X 的 MinIO Operator 部署
  • 你的 Kubernetes 集群版本为 1.19.0 或更高
  • 你的本地主机已安装 kubectl，并已配置好对 Kubernetes 集群的访问

操作步骤

本流程涵盖将运行 3.0.0 到 3.2.9 任意版本的 MinIO Operator 部署升级到 4.2.2 所需的步骤。 随后你可以执行 将 MinIO Operator 4.0.0 到 4.2.2 升级到 4.2.3，再执行 将 MinIO Operator 从 5.0.15 升级到 7.1.1。

3.X.X 系列安装无法直接升级到 7.1.1。

  1. (可选) 将每个 MinIO Tenant 升级到最新稳定版 MinIO。

    定期升级 MinIO 可确保 Tenant 获得最新特性和性能改进。

    在将升级应用到生产 Tenant 之前，请先在 Dev 或 QA Tenant 等较低环境中验证。

    升级 MinIO Tenant 的具体流程请参阅 升级 MinIO Tenant。

  2. 验证 Tenant tenant.spec.zones 的值

    使用以下命令检查每个受管 MinIO Tenant 的规范：

    kubectl get tenants <TENANT-NAME> -n <TENANT-NAMESPACE> -o yaml
    • 确保每个 tenant.spec.zones 元素都设置了 name 字段，且值为该 zone 的名称。 同一个 Tenant 中每个 zone 的名称都必须唯一，例如第一个和第二个 zone 分别使用 zone-0 与 zone-1。
    • 确保每个 tenant.spec.zones 都显式设置了 securityContext，以描述 pod 在集群中运行时使用的权限集。

    以下 Tenant YAML 片段设置了这些字段：

    image: "minio/minio:$(LATEST-VERSION)"
...
zones:
- servers: 4
  name: "zone-0"
  volumesPerServer: 4
  volumeClaimTemplate:
     metadata:
     name: data
     spec:
     accessModes:
        - ReadWriteOnce
     resources:
        requests:
           storage: 1Ti
  securityContext:
     runAsUser: 0
     runAsGroup: 0
     runAsNonRoot: false
     fsGroup: 0
- servers: 4
  name: "zone-1"
  volumesPerServer: 4
  volumeClaimTemplate:
     metadata:
     name: data
     spec:
     accessModes:
        - ReadWriteOnce
     resources:
        requests:
           storage: 1Ti
  securityContext:
     runAsUser: 0
     runAsGroup: 0
     runAsNonRoot: false
     fsGroup: 0

    你可以使用以下命令编辑 tenant 并应用变更：

    kubectl edit tenants <TENANT-NAME> -n <TENANT-NAMESPACE>

  3. 升级到 Operator 4.2.2

    下载 MinIO Kubernetes Plugin 4.2.2，并使用它升级 Operator。 在浏览器中打开 https://github.com/minio/operator/releases/tag/v4.2.2，下载与你本地主机操作系统匹配的二进制文件。 例如，使用 Intel 或 AMD 处理器的 Linux 主机可以运行以下命令：

    wget https://github.com/minio/operator/releases/download/v4.2.3/kubectl-minio_4.2.2_linux_amd64 -o kubectl-minio_4.2.2
chmod +x kubectl-minio_4.2.2

./kubectl-minio_4.2.2 init

  4. 验证所有 Tenant 和 Operator pod

    检查 Operator 和 MinIO Tenant 命名空间，确保所有 pod 和 service 都已成功启动。

    例如：

    kubectl get all -n minio-operator

kubectl get pods -l "v1.min.io/tenant" --all-namespaces

  5. 升级到 4.2.3

    按照 将 MinIO Operator 4.0.0 到 4.2.2 升级到 4.2.3 中的流程升级到 Operator 4.2.3。 随后你可以继续升级到 7.1.1。