Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.2. 升级 Quay Operator

在 OpenShift Container Platform 中升级已安装的 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
  6. 3.6.z 3.9.z
  7. 3.7.z 3.9.z
  8. 3.8.z 3.9.z

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

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 的 PostgreSQL 数据库从版本 10 升级到版本 13。

重要
  • 这个升级是不可逆的。强烈建议您升级到 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。

流程

  1. 可选。通过将 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"
    Copy to Clipboard Toggle word wrap
  2. 在 OpenShift Container Platform Web 控制台中导航至 Operators Installed Operators。
  3. 点 Red Hat Quay Operator。
  4. 进入到 Subscription 选项卡。
  5. 在 Subscription details 下，点 Update channel。
  6. 选择 stable-3.9 并保存更改。
  7. 在 Upgrade status 下检查新安装的进度。在继续操作前，等待升级 状态变为 1。
  8. 在 OpenShift Container Platform 集群中，进入到 Workloads Pods。现有 pod 应该被终止，或正在终止。
  9. 等待以下 pod （负责升级数据库和现有数据的模式迁移）到启动： clair-postgres-upgrade、quay-postgres-upgrade、quay-postgres-upgrade 和 quay-app-upgrade。
  10. 在 clair-postgres-upgrade、quay-postgres-upgrade 和 quay-app-upgrade pod 标记为 Completed 后，您的 Red Hat Quay 部署剩余的 pod 会启动。这大约需要十分钟。
  11. 验证 quay-database 和 clair-postgres pod 现在使用 postgresql-13 镜像。
  12. 在 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 版本时，用户无法升级到 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:
...
    Copy to Clipboard Toggle word wrap

从 Red Hat Quay 3.3.4 直接升级到 Red Hat Quay 3.6 时，使用其自身 SSL/TLS 证书/密钥对时没有 Subject Alternative Names (SANs)的客户存在问题。在升级到 Red Hat Quay 3.6 的过程中，部署会被阻断，并显示 Red Hat Quay SSL/TLS 证书必须具有 SAN 的错误信息。

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

 GODEBUG=x509ignoreCN=0
Copy to Clipboard Toggle word wrap

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

要在 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: *****
Copy to Clipboard Toggle word wrap

2.2.5. 更改 Red Hat Quay Operator 的更新频道
复制链接

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

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

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat