2.2. 升级 Quay Operator

在 OpenShift 上升级已安装的 Operator 的标准方法包括在 升级已安装的 Operator 中。

通常，Red Hat Quay 支持从以前的(N-1)次版本进行升级。例如，不支持直接从 Red Hat Quay 3.0.5 升级到最新版本的 3.5。相反，用户需要如下升级：

  1. 3.0.5 → 3.1.3
  2. 3.1.3 → 3.2.2
  3. 3.2.2 → 3.3.4
  4. 3.3.4 → 3.4.z
  5. 3.4.z → 3.5.z

这需要确保在升级过程中正确且按正确顺序执行任何必要的数据库迁移。

在某些情况下，Red Hat Quay 支持从以前的（N-2、N-3）次版本直接进行单步升级。这个例外是只在次版本前的次版本中，对旧版本的用户进行升级流程。支持以下升级路径：

  1. 3.3.z → 3.6.z
  2. 3.4.z → 3.6.z
  3. 3.4.z → 3.7.z
  4. 3.5.z → 3.7.z
  5. 3.7.z → 3.8.z

有关希望升级到 3.8 的 Quay 独立部署 的用户，请参阅独立升级指南。

2.2.1. 升级 Quay

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

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

2.2.2. 有关直接从 3.3.z 或 3.4.z 升级到 3.6 的备注

2.2.2.1. 启用边缘路由升级

  • 在以前的版本中，当运行启用了边缘路由的 3.3.z 版本时，用户无法升级到 Red Hat Quay 的 3.4.z 版本。这个问题已通过 Red Hat Quay 3.6 的发行版本解决。

  • 当从 3.3.z 升级到 3.6 时，如果在 Red Hat Quay 3.3.z 部署中将 tls.termination 设置为 none，它将改为使用 TLS 边缘终止的 HTTPS，并使用默认集群通配符证书。例如： 

    apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: quay33
spec:
  quay:
    imagePullSecretName: redhat-pull-secret
    enableRepoMirroring: true
    image: quay.io/quay/quay:v3.3.4-2
    ...
    externalAccess:
      hostname: quayv33.apps.devcluster.openshift.com
      tls:
        termination: none
    database:
...

2.2.2.2. 使用自定义 TLS 证书/密钥对升级，无需主题备用名称

当直接从 Red Hat Quay 3.3.4 升级到 Red Hat Quay 3.6 时，用户可以使用自己的 TLS 证书/密钥对而无需 Subject Alternative Name(SAN)的用户有问题。在升级到 Red Hat Quay 3.6 时，部署会被阻止，来自 Quay Operator pod 日志的错误消息表示 Quay TLS 证书必须具有 SAN。

如果可能，您应该使用 SAN 中的正确主机名重新生成 TLS 证书。一个可能的解决方法涉及在 quay-app、quay-upgrade 和 quay-config-editor pod 中定义环境变量来启用 CommonName 匹配： 

 GODEBUG=x509ignoreCN=0

GODEBUG=x509ignoreCN=0 标志可在没有 SANs 时将 X.509 证书上的 CommonName 字段视为主机名的传统行为。但是，我们不推荐使用这个临时解决方案，因为它不会在重新部署之间保留。

2.2.2.3. 使用 Quay Operator 从 3.3.z 或 3.4.z 升级到 3.6 时配置 Clair v4

要在 OpenShift 上的新 Red Hat Quay 部署上设置 Clair v4，强烈建议使用 Quay Operator。默认情况下，Quay Operator 将安装和升级 Clair 部署，以及您的 Red Hat Quay 部署并自动配置 Clair。

有关在 OpenShift 上设置 Clair v4 的说明，请参阅在 Red Hat Quay OpenShift 部署 上设置 Clair。

2.2.3. 从 3.3.z 升级到 3.6 时 Swift 配置

当从 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: *****

2.2.4. 更改 Operator 的更新频道

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

2.2.5. 手动批准待处理的 Operator 升级

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

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

Subscription tab including upgrade Channel and Approval strategy

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

Installed Operators