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 流升级的步骤取决于以上所述的 approvalStrategy。如果批准策略被设置为 Automatic,Quay Operator 会自动升级到最新的 z 流。这会导致自动的、滚动式的到较新的 z 流的 Quay 更新,几乎没有或只有非常短的停机时间。否则,必须在开始安装前手动批准更新。

2.2.2.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:
    ...

从 Red Hat Quay 3.3.4 直接升级到 Red Hat Quay 3.6 时,使用其自身 TLS 证书/密钥对但没有 Subject Alternative Names (SANs) 的客户会存在一个问题。在升级到 Red Hat Quay 3.6 时,部署会被阻断,来自 Quay Operator pod 日志的错误消息表示 Quay TLS 证书必须具有 SAN。

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

 GODEBUG=x509ignoreCN=0

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

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

有关在 OpenShift 中设置 Clair v4 的说明,请参阅在 Red Hat Quay OpenShift 部署中设置 Up 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_optionstenant_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 选项卡中的更新频道。对于带有 Automatic 批准策略的订阅,升级会自动开始,并在列出 Installed Operators 的页面中监控。

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

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

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

Subscription tab including upgrade Channel and Approval strategy

Installed Operators 列表提供当前 Quay 安装的高级摘要:

Installed Operators

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2026 Red Hat
返回顶部