升级 Silo Tenant

版本说明： 本页命令与输出示例以 Server 20261109（RELEASE.2026-11-09T00-00-00Z）为基准；下载与升级要求见下载页和发布说明。

以下步骤说明如何使用 Kustomize 或 Helm 升级单个 Silo Tenant，并涵盖独立 helm/silo Chart 7.0.4 的升级要点。请先在非生产集群中测试确切的服务端镜像、Operator/Chart 版本与回滚流程。

注意

服务端镜像必须保持为 pgsty/silo，并仅使用 Silo 下载页已发布的标签或摘要。上游 Tenant 默认值使用 MinIO 镜像。SILO 已禁用原地自更新；MINIO_UPDATE=off 不会重新启用它。请通过更新 Tenant 或 StatefulSet 的镜像版本执行升级。

如果集群仍运行非常早期的上游版本，切换至 SILO 前请先核对历史上游迁移要求。

警告

旧版 AD/LDAP 迁移要求

对于运行早于 RELEASE.2024-03-30T09-41-56Z 的上游 MinIO 镜像且启用了 AD/LDAP 的 Tenant，升级到 SILO 前必须阅读 RELEASE.2024-04-18T19-09-19Z 发布说明并完成其中的迁移步骤。

升级到 20261109 之前

将任何 Kubernetes Tenant 或独立 helm/silo 部署升级到 SILO 20261109（RELEASE.2026-11-09T00-00-00Z）之前，请完成以下五项检查：

18 Pod 及以上单池布局必须排空停机重启。 若单个存储池内的各纠删集不全共享同一组 Pod/主机（自动布局下通常为 18 个及以上 Pod），必须采用排空全停重启（先将 StatefulSet 缩容至 0 并确认全部旧 Pod 终止，再启动 20261109 Pod），切勿直接执行 StatefulSet 滚动更新，因为旧版与新版的单池删除和复制锁域（#298）在跨纠删集时无法互斥。
混合版本期间暂停归档恢复请求。 只要仍有对端 Pod 运行旧版本或不可达，已升级的 Pod 会对 POST ?restore 返回 503 Service Unavailable。请暂停发起新的恢复请求，直至全部 Pod 升级到 20261109。完整的多池生命周期保护与 S3 批量删除 Object Lock 保护同样要求所有服务 Pod 完成升级。
升级前排空批处理作业。 切换版本前停止提交批处理作业，并排空或取消所有运行中、等待中和暂停中的作业。未完成的旧格式作业需在全部 Pod 升级后重新提交，已完成的作业保持完成状态；在仍有未完成的 20261109 作业时切勿降级。请按批处理升级与回退清单操作。
保留无头服务启动发现并执行数据面校验。 对端发现无头服务（*-hl）必须保留 publishNotReadyAddresses: true，以便各 Pod 在启动阶段发现对端。Pod 重启后，恢复业务流量前须对每个 Pod 执行有界超时的签名 S3 写入与回读校验——单凭 ready 和 cluster 探针无法证明每个远端磁盘已完成重连，详见重启后的就绪窗口。
使用 Helm --reuse-values 时显式固定镜像标签。 独立 helm/silo Chart 7.0.4（#296）默认部署 SILO 与 mcli RELEASE.2026-11-09T00-00-00Z，但 helm upgrade --reuse-values 会保留此前存储的 image.tag。复用已存 values 升级时，必须显式传入 --set image.tag=RELEASE.2026-11-09T00-00-00Z（对于 Operator Tenant Chart 则为 --set tenant.image.tag=RELEASE.2026-11-09T00-00-00Z）。

使用 Kustomize 升级 Tenant

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

若 Tenant 最初通过 Operator Console 部署，升级前需先导出基础配置文件；若最初通过 Kustomize 部署，直接使用原部署的 kustomization 文件作为基础配置。

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

创建基础配置文件：
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 中移除上述字段：
  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 替换为对应文件名。

使用原始部署中的 kustomization 文件作为基础配置来升级 Tenant。如果已经没有这些文件，请按照 Operator Console-Deployed Tenant 标签页中的说明操作。

创建一个 upgrade-minio-tenant.yaml 文件，其内容类似如下：

apiVersion: minio.min.io/v2
kind: Tenant

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

spec:
  image: docker.io/pgsty/silo:RELEASE.2026-11-09T00-00-00Z
  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。

在与上述文件相同的目录中，使用 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 步骤。

验证现有 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

更新 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，正常情况下不应安装。
保留并审查 Tenant values

导出当前发布由用户提供的 values，然后确认该文件保留了所有拓扑、存储、TLS、凭据与调度设置：
```
helm get values CHART_NAME -n TENANT_NAMESPACE -o yaml > values.yaml
```
将 tenant.image.repository 设为 docker.io/pgsty/silo，将 tenant.image.tag 固定为 RELEASE.2026-11-09T00-00-00Z（或其他经测试的已发布 Silo 版本），并确保 tenant.env 包含 MINIO_UPDATE=off。不得让 Chart 升级恢复上游镜像默认值。
运行已固定的 helm upgrade

Chart 版本与 Silo 服务端镜像应分别固定，并传入经过审查的 values 文件：
```
helm upgrade -n TENANT_NAMESPACE \
  --version 7.1.1 \
  --values values.yaml \
  CHART_NAME minio-operator/tenant
```
对于不使用 MinIO Operator 的独立 helm/silo Chart 7.0.4 部署，Chart 7.0.4 默认将 image.tag 与 mcImage.tag 设为 RELEASE.2026-11-09T00-00-00Z（#296）。若执行 helm upgrade --reuse-values，请显式传入 --set image.tag=RELEASE.2026-11-09T00-00-00Z，避免 Helm 继续保留旧镜像标签。

命令成功执行后，REVISION 值会递增。
验证 Tenant 升级

检查所有 Service 和 Pod 是否在线，核对实际运行的镜像摘要，并在恢复业务流量前对每个 Pod 执行有界超时的签名 S3 写入与回读检查，详见重启后的就绪窗口。

加载评论需要启用 JavaScript。在 GitHub 上查看讨论。