2.2. 升级 Quay Operator

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

通常，Red Hat Quay 仅支持从之前的(N-1)次版本进行升级。例如，不支持直接从 Red Hat Quay 3.0.5 升级到 3.5 的最新版本。用户必须按如下方式升级：

3.0.5 3.1.3
3.1.3 3.2.2
3.2.2 3.3.4
3.3.4 3.4.z
3.4.z 3.5.z

这需要确保正确完成任何必要的数据库迁移，并在升级过程中按正确顺序完成。

在某些情况下，Red Hat Quay 支持从之前(N-2、N-3)次版本直接进行单步骤升级。这简化了旧版本客户的升级过程。支持以下升级路径：

3.3.z 3.6.z
3.4.z 3.6.z
3.4.z 3.7.z
3.5.z 3.7.z
3.7.z 3.8.z
3.6.z 3.9.z
3.7.z 3.9.z
3.8.z 3.9.z

有关 Red Hat Quay 的独立部署的用户，请参阅独立升级指南。

2.2.1. 升级 Quay

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

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

2.2.2. 从 3.8 3.9 更新 Red Hat Quay

重要

如果您的 Red Hat Quay 部署从一个 y-stream 升级到下一个（例如从 3.8.10 3.8.11），则不得将升级频道从 stable-3.8 切换到 stable-3.9。在 y-stream 升级过程中更改升级频道将不允许 Red Hat Quay 升级到 3.9。这是一个已知问题，并将在以后的 Red Hat Quay 版本中解决。

更新 Red Hat Quay 3.8 3.9 时，Operator 会自动为 Clair 和 Red Hat Quay 从版本 10 升级到 13 的现有 PostgreSQL 数据库。

重要

这个升级不可逆。强烈建议您升级到 PostgreSQL 13。PostgreSQL 10 在 2022 年 11 月 10 日有其最终发行版本，不再被支持。如需更多信息，请参阅 PostgreSQL 版本策略。
默认情况下，Red Hat Quay 配置为从 PostgreSQL 10 中删除旧的持久性卷声明(PVC)。要禁用此设置和备份旧的 PVC，您必须在 quay-operator Subscription 对象中将 POSTGRES_UPGRADE_RETAIN_BACKUP 设置为 True。

先决条件

您已在 OpenShift Container Platform 上安装了 Red Hat Quay 3.8。
100 GB 可用，额外存储.
在升级过程中，会置备额外的持久性卷声明(PVC)来存储迁移的数据。这有助于防止对用户数据进行破坏性操作。升级过程为 Red Hat Quay 数据库升级和 Clair 数据库升级推出 50 GB 的 PVC。

步骤

可选。通过将 POSTGRES_UPGRADE_RETAIN_BACKUP 设置为 True your quay-operator Subscription 对象，从 PostgreSQL 10 备份旧的 PVC。例如：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: quay-operator
  namespace: quay-enterprise
spec:
  channel: stable-3.8
  name: quay-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: POSTGRES_UPGRADE_RETAIN_BACKUP
      value: "true"

在 OpenShift Container Platform Web 控制台中，进入到 Operators Installed Operators。
点 Red Hat Quay Operator。
进入 Subscription 选项卡。
在 Subscription details 下点 Update channel。
选择 stable-3.9 并保存更改。
在 Upgrade status 下检查新安装的进度。等待升级状态更改为 1，然后继续。
在 OpenShift Container Platform 集群中，进入到 Workloads Pods。现有 pod 应该被终止，或者在终止过程中终止。
等待以下 pod （负责升级现有数据的数据库和 alembic 迁移）以加速： clair-postgres-upgrade、quay-postgres-upgrade 和 quay-app-upgrade。
在 clair-postgres-upgrade、quay-postgres-upgrade 和 quay-app-upgrade pod 标记为 Completed 后，您的 Red Hat Quay 部署的剩余 pod 会启动。这大约需要十分钟。
验证 quay-database 和 clair-postgres 容器集现在是否使用 postgresql-13 镜像。
在 quay-app pod 标记为 Running 后，您可以访问 Red Hat Quay registry。

2.2.3. 直接从 3.3.z 或 3.4.z 升级到 3.6

下面的部分提供了在从 Red Hat Quay 3.3.z 或 3.4.z 升级到 3.6 时的重要信息。

2.2.3.1. 启用边缘路由升级

在以前的版本中，当运行启用了边缘路由的 Red Hat Quay 的 3.3.z 版本时，用户无法升级到 3.4.z 版本的 Red Hat Quay。这个问题已在 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.3.2. 使用自定义 SSL/TLS 证书/密钥对升级，而无需 Subject Alternative Names

从 Red Hat Quay 3.3.4 直接升级到 Red Hat Quay 3.6 时，客户使用自己的 SSL/TLS 证书/密钥对没有 Subject Alternative Names (SAN)。在升级到 Red Hat Quay 3.6 时，部署会被阻止，并显示 Red Hat Quay Operator pod 日志中的错误消息，表示 Red Hat Quay SSL/TLS 证书必须具有 SANs。

如果可能，您应该使用 SAN 中的正确主机名重新生成 SSL/TLS 证书。可能的临时解决方案包括在升级后在 quay-app、quay-upgrade 和 quay-config-editor pod 中定义环境变量，以启用 CommonName 匹配：

 GODEBUG=x509ignoreCN=0

GODEBUG=x509ignoreCN=0 标志允许在没有 SANs 时将 X.509 证书上的 CommonName 字段视为主机名。但不建议使用这个临时解决方案，因为它不会在重新部署中保留。

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

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

有关在断开连接的 OpenShift Container Platform 集群中设置 Clair v4 的说明，请参阅在 Red Hat Quay OpenShift 部署中设置 Clair。

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

当从 Red Hat Quay 3.3.z 升级到 3.6.z 时，一些用户可能会收到以下错误： Switch auth v3 requires tenant_id （字符串）在 os_options 中。作为临时解决方案，您可以手动更新 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.5. 更改 Red Hat Quay Operator 的更新频道

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

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

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

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

Subscription tab including upgrade Channel and Approval strategy

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

Installed Operators