要将 Quay 从一个次要版本升级到下一个次要版本，如 3.4 → 3.5，您需要更改 Quay Operator 的更新频道。

对于 z 流升级，例如 3.4.2 → 3.4.3，会在用户在安装过程中初始选择的主次频道中发布更新。执行 z 流升级的步骤取决于以 上所述的批准Strategy。如果批准策略被设置为 Automatic，Quay Operator 会自动升级到最新的 z 流。这会导致自动的、滚动式的到较新的 z 流的 Quay 更新，几乎没有或只有非常短的停机时间。否则，必须手动批准更新，然后才能开始安装。

当从 Red Hat Quay 3.3.z 升级到 3.6.z 时，一些用户可能会收到以下错误： Switch auth v3 需要 os_options 中的 tenant_id（字符串）。作为临时解决方案，您可以手动更新 DISTRIBUTED_STORAGE_CONFIG 以添加 os_options 和 tenant_id 参数：

  DISTRIBUTED_STORAGE_CONFIG:
    brscale:
    - SwiftStorage
    - auth_url: http://****/v3
      auth_version: "3"
      os_options:
        tenant_id: ****
        project_name: ocp-base
        user_domain_name: Default
      storage_path: /datastorage/registry
      swift_container: ocp-svc-quay-ha
      swift_password: *****
      swift_user: *****

已安装的 Operator 的订阅指定一个更新频道，用于跟踪和接收 Operator 的更新。要升级 Quay Operator 以开始跟踪并从更新频道接收更新，请更改已安装 Quay Operator 的 Subscription 选项卡中的更新频道。对于带有 自动批准策略 的订阅，升级会自动开始，并可在列出 Installed Operators 的页面上进行监控。

如果已安装的 Operator 的订阅被设置为 Manual，则当其当前更新频道中发布新更新时，在开始安装前必须手动批准更新。如果 Quay Operator 有待处理的升级，则此状态将显示在 Installed Operators 列表中。在 Quay Operator 的 Subscription 选项卡中，您可以预览安装计划，并查看列出可用于升级的资源。如果满意，点 Approve 并返回到列出 Installed Operators 的页面，以监控升级的进度。

下图显示了 UI 中的 Subscription 选项卡，包括 更新频道、批准策略、Upgrade 状态和 InstallPlan ：

Installed Operators 列表提供当前 Quay 安装的高级别概述：

现在，配额管理在 FEATURE_QUOTA_MANAGEMENT 属性下被支持，并默认关闭。要启用配额管理，请将 config.yaml 中的功能标记设置为 true ：

FEATURE_QUOTA_MANAGEMENT: true

现在，在 FEATURE_PROXY_CACHE 属性下支持使用 Red Hat Quay 代理远程机构。要启用代理缓存，将 confg.yaml 中的功能标记设置为 true ：

FEATURE_PROXY_CACHE: true

构建可以在虚拟平台上运行。还提供向后兼容以运行之前的构建配置。要启用虚拟构建，请将 config.yaml 中的功能标记设置为 true ：

FEATURE_BUILD_SUPPORT: true

Operator 部署现在支持使用 geo-replication 的 Red Hat Quay 部署。要启用 geo-replication，请将 config.yaml 中的功能标记设置为 true ：

FEATURE_STORAGE_REPLICATION: true

在 OpenShift 控制台中对监控 Quay 3.6 的支持要求在所有命名空间中安装 Operator。如果您之前在特定命名空间中安装了 Operator，请删除 Operator 本身，并在升级完成后为所有命名空间重新安装它。

现在，Red Hat Quay 3.6 中默认启用对 Helm 和一些 OCI 工件的支持。如果要显式启用该功能，例如，如果您是从没有默认启用的版本升级，则需要重新配置 Quay 部署，以使用以下属性启用 OCI 工件：

FEATURE_GENERAL_OCI_SUPPORT: true

如果在从 QuayEcosystem 自动升级到 QuayRegistry 时出现问题，请按照以下步骤恢复至使用 QuayEcosystem ：

如果迁移 QuayEcosystem 组件失败或不受支持，Quay Operator 会在日志中报告错误，并且 status.conditions。所有非受管组件都应成功迁移，因为 Quay 的 config.yaml 中还没有提供任何 Kubernetes 资源，且所有必要的值都已在 Quay 的 config.yaml 中提供。

数据库

不支持临时数据库（必须设置volumeSize 字段）。

Redis

不需要任何特殊操作。

外部访问

自动迁移只支持 passthrough Route 访问。其他方法需要手动迁移。

Clair

不需要任何特殊操作。

Object Storage

QuayEcosystem 没有受管对象存储组件，因此对象存储始终标记为非受管状态。不支持本地存储。

仓库镜像

不需要任何特殊操作。

当从 Red Hat Quay 3.3.z 升级到 3.6.z 时，一些用户可能会收到以下错误： Switch auth v3 需要 os_options 中的 tenant_id（字符串）。作为临时解决方案，您可以手动更新 DISTRIBUTED_STORAGE_CONFIG 以添加 os_options 和 tenant_id 参数：

  DISTRIBUTED_STORAGE_CONFIG:
    brscale:
    - SwiftStorage
    - auth_url: http://****/v3
      auth_version: "3"
      os_options:
        tenant_id: ****
        project_name: ocp-base
        user_domain_name: Default
      storage_path: /datastorage/registry
      swift_container: ocp-svc-quay-ha
      swift_password: *****
      swift_user: *****

如果您是从 Red Hat Quay 2.y.z 集群开始，请按照以下步骤操作。升级到最新的 Red Hat Quay 3.x 版本前，您必须首先将该集群迁移到 3.0.5，如这里所述。集群正在运行 3.0.5 后，您可以通过按顺序升级到每个次要版本来升级到最新的 3.x 版本。例如：

在开始 Red Hat Quay 2.y.z 升级到 3.0 之前，请注意以下几点：

为确保最佳结果，我们建议以下先决条件：

选择同步升级（在停机后完成升级）和背景升级（在 Red Hat Quay 仍在运行时完成升级）。这两个主要版本升级都需要在短时间内关闭 Red Hat Quay 集群。

无论您选择哪个升级类型，在 Red Hat Quay 集群停机期间，如果您使用 builder 和 Clair 镜像，您还需要升级到这些新镜像：

这些镜像都在 registry.redhat.io/quay 存储库中获得。

要运行同步升级，在整个集群期间为整个升级关闭，请执行以下操作：

要进行后台升级，您需要在两个 occasions 短时间内关闭集群。当第一次停机后，quay v3 容器会在 v2 兼容性模式下运行时，它会回填数据库。此后台进程可能需要几小时甚至数天才能完成。对于大型安装，建议进行后台升级，因为停机会超过几个小时。

对于这种类型的升级，您可以将 Red Hat Quay 置于兼容性模式，其中运行 Quay 3 容器，但在升级完成时在旧数据模型上运行。以下是您做什么：