×

以下部分详细描述了 OpenShift Container Platform (OCP) 更新过程的各个主要方面。有关更新工作原理的概述,请参阅OpenShift 更新简介

集群版本操作符 (Cluster Version Operator)

集群版本操作符 (CVO) 是协调和促进 OpenShift Container Platform 更新过程的主要组件。在安装和标准集群操作期间,CVO 不断将托管集群操作符的清单与集群内资源进行比较,并协调差异以确保这些资源的实际状态与其期望状态匹配。

ClusterVersion 对象

集群版本操作符 (CVO) 监控的资源之一是ClusterVersion资源。

管理员和 OpenShift 组件可以通过ClusterVersion对象与 CVO 进行通信或交互。期望的 CVO 状态通过ClusterVersion对象声明,而当前的 CVO 状态则反映在对象的 status 中。

请勿直接修改ClusterVersion对象。请改用oc CLI 或 Web 控制台等接口来声明更新目标。

CVO 不断将集群与ClusterVersion资源的spec属性中声明的目标状态进行协调。当期望的发行版与实际发行版不同时,该协调将更新集群。

更新可用性数据

ClusterVersion资源还包含有关可用于集群的更新的信息。这包括可用的更新,但不建议由于适用于集群的已知风险而使用这些更新。这些更新称为条件更新。要了解 CVO 如何在ClusterVersion资源中维护有关可用更新的信息,请参阅“更新可用性评估”部分。

  • 您可以使用以下命令检查所有可用更新

    $ oc adm upgrade --include-not-recommended

    附加的--include-not-recommended参数包含具有适用于集群的已知问题的可用更新。

    示例输出
    Cluster version is 4.13.40
    
    Upstream is unset, so the cluster will use an appropriate default.
    Channel: stable-4.14 (available channels: candidate-4.13, candidate-4.14, eus-4.14, fast-4.13, fast-4.14, stable-4.13, stable-4.14)
    
    Recommended updates:
    
      VERSION     IMAGE
      4.14.27     quay.io/openshift-release-dev/ocp-release@sha256:4d30b359aa6600a89ed49ce6a9a5fdab54092bcb821a25480fdfbc47e66af9ec
      4.14.26     quay.io/openshift-release-dev/ocp-release@sha256:4fe7d4ccf4d967a309f83118f1a380a656a733d7fcee1dbaf4d51752a6372890
      4.14.25     quay.io/openshift-release-dev/ocp-release@sha256:a0ef946ef8ae75aef726af1d9bbaad278559ad8cab2c1ed1088928a0087990b6
      4.14.24     quay.io/openshift-release-dev/ocp-release@sha256:0a34eac4b834e67f1bca94493c237e307be2c0eae7b8956d4d8ef1c0c462c7b0
      4.14.23     quay.io/openshift-release-dev/ocp-release@sha256:f8465817382128ec7c0bc676174bad0fb43204c353e49c146ddd83a5b3d58d92
      4.13.42     quay.io/openshift-release-dev/ocp-release@sha256:dcf5c3ad7384f8bee3c275da8f886b0bc9aea7611d166d695d0cf0fff40a0b55
      4.13.41     quay.io/openshift-release-dev/ocp-release@sha256:dbb8aa0cf53dc5ac663514e259ad2768d8c82fd1fe7181a4cfb484e3ffdbd3ba
    
    Updates with known issues:
    
      Version: 4.14.22
      Image: quay.io/openshift-release-dev/ocp-release@sha256:7093fa606debe63820671cc92a1384e14d0b70058d4b4719d666571e1fc62190
      Reason: MultipleReasons
      Message: Exposure to AzureRegistryImageMigrationUserProvisioned is unknown due to an evaluation failure: client-side throttling: only 18.061µs has elapsed since the last match call completed for this cluster condition backend; this cached cluster condition request has been queued for later execution
      In Azure clusters with the user-provisioned registry storage, the in-cluster image registry component may struggle to complete the cluster update. https://issues.redhat.com/browse/IR-468
    
      Incoming HTTP requests to services exposed by Routes may fail while routers reload their configuration, especially when made with Apache HTTPClient versions before 5.0. The problem is more likely to occur in clusters with higher number of Routes and corresponding endpoints. https://issues.redhat.com/browse/NE-1689
    
      Version: 4.14.21
      Image: quay.io/openshift-release-dev/ocp-release@sha256:6e3fba19a1453e61f8846c6b0ad3abf41436a3550092cbfd364ad4ce194582b7
      Reason: MultipleReasons
      Message: Exposure to AzureRegistryImageMigrationUserProvisioned is unknown due to an evaluation failure: client-side throttling: only 33.991µs has elapsed since the last match call completed for this cluster condition backend; this cached cluster condition request has been queued for later execution
      In Azure clusters with the user-provisioned registry storage, the in-cluster image registry component may struggle to complete the cluster update. https://issues.redhat.com/browse/IR-468
    
      Incoming HTTP requests to services exposed by Routes may fail while routers reload their configuration, especially when made with Apache HTTPClient versions before 5.0. The problem is more likely to occur in clusters with higher number of Routes and corresponding endpoints. https://issues.redhat.com/browse/NE-1689

    oc adm upgrade命令查询ClusterVersion资源以获取有关可用更新的信息,并以人类可读的格式呈现。

  • 直接检查 CVO 创建的基础可用性数据的一种方法是使用以下命令查询ClusterVersion资源

    $ oc get clusterversion version -o json | jq '.status.availableUpdates'
    示例输出
    [
      {
        "channels": [
          "candidate-4.11",
          "candidate-4.12",
          "fast-4.11",
          "fast-4.12"
        ],
        "image": "quay.io/openshift-release-dev/ocp-release@sha256:400267c7f4e61c6bfa0a59571467e8bd85c9188e442cbd820cc8263809be3775",
        "url": "https://access.redhat.com/errata/RHBA-2023:3213",
        "version": "4.11.41"
      },
      ...
    ]
  • 可以使用类似的命令来检查条件更新

    $ oc get clusterversion version -o json | jq '.status.conditionalUpdates'
    示例输出
    [
      {
        "conditions": [
          {
            "lastTransitionTime": "2023-05-30T16:28:59Z",
            "message": "The 4.11.36 release only resolves an installation issue https://issues.redhat.com//browse/OCPBUGS-11663 , which does not affect already running clusters. 4.11.36 does not include fixes delivered in recent 4.11.z releases and therefore upgrading from these versions would cause fixed bugs to reappear. Red Hat does not recommend upgrading clusters to 4.11.36 version for this reason. https://access.redhat.com/solutions/7007136",
            "reason": "PatchesOlderRelease",
            "status": "False",
            "type": "Recommended"
          }
        ],
        "release": {
          "channels": [...],
          "image": "quay.io/openshift-release-dev/ocp-release@sha256:8c04176b771a62abd801fcda3e952633566c8b5ff177b93592e8e8d2d1f8471d",
          "url": "https://access.redhat.com/errata/RHBA-2023:1733",
          "version": "4.11.36"
        },
        "risks": [...]
      },
      ...
    ]

更新可用性评估

集群版本操作符 (CVO) 定期查询 OpenShift 更新服务 (OSUS) 以获取有关更新可能性的最新数据。此数据基于集群的订阅频道。然后,CVO 将有关更新建议的信息保存到其ClusterVersion资源的availableUpdatesconditionalUpdates字段中。

CVO 定期检查条件更新的更新风险。这些风险通过 OSUS 提供的数据传达,该数据包含每个版本的有关可能影响更新到该版本的集群的已知问题的信息。大多数风险仅限于具有特定特征的集群,例如特定大小的集群或在特定云平台上部署的集群。

CVO 不断将集群特征与每个条件更新的条件风险信息进行评估。如果 CVO 发现集群与条件相符,则 CVO 将此信息存储在其ClusterVersion资源的conditionalUpdates字段中。如果 CVO 发现集群与更新的风险不匹配,或者更新没有关联的风险,则它将目标版本存储在其ClusterVersion资源的availableUpdates字段中。

用户界面(Web 控制台或 OpenShift CLI (oc))将此信息以分段标题的形式呈现给管理员。与更新路径相关的每个已知问题都包含指向有关风险的更多资源的链接,以便管理员可以就更新做出明智的决定。

发行版镜像

发行版镜像是特定 OpenShift Container Platform (OCP) 版本的交付机制。它包含发行版元数据、与发行版版本匹配的集群版本操作符 (CVO) 二进制文件、部署各个 OpenShift 集群操作符所需的每个清单,以及构成此 OpenShift 版本的所有容器镜像的 SHA 散列版本引用列表。

您可以通过运行以下命令来检查特定发行版镜像的内容

$ oc adm release extract <release image>
示例输出
$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.12.6-x86_64
Extracted release payload from digest sha256:800d1e39d145664975a3bb7cbc6e674fbf78e3c45b5dde9ff2c5a11a8690c87b created at 2023-03-01T12:46:29Z

$ ls
0000_03_authorization-openshift_01_rolebindingrestriction.crd.yaml
0000_03_config-operator_01_proxy.crd.yaml
0000_03_marketplace-operator_01_operatorhub.crd.yaml
0000_03_marketplace-operator_02_operatorhub.cr.yaml
0000_03_quota-openshift_01_clusterresourcequota.crd.yaml (1)
...
0000_90_service-ca-operator_02_prometheusrolebinding.yaml (2)
0000_90_service-ca-operator_03_servicemonitor.yaml
0000_99_machine-api-operator_00_tombstones.yaml
image-references (3)
release-metadata
1 ClusterResourceQuota CRD 清单文件,将在运行级别 03 应用
2 service-ca-operatorPrometheusRoleBinding 资源清单文件,将在运行级别 90 应用
3 所有必需镜像的 SHA 摘要版本引用列表

更新流程

以下步骤详细描述了 OpenShift Container Platform (OCP) 更新流程

  1. 目标版本存储在 ClusterVersion 资源的 spec.desiredUpdate.version 字段中,可以通过 Web 控制台或 CLI 进行管理。

  2. 集群版本操作符 (CVO) 检测到 ClusterVersion 资源中的 desiredUpdate 与当前集群版本不同。CVO 使用来自 OpenShift 更新服务的图形数据,将所需的集群版本解析为发行版镜像的拉取规范。

  3. CVO 验证发行版镜像的完整性和真实性。Red Hat 使用镜像 SHA 摘要作为唯一且不可变的发行版镜像标识符,在预定义位置发布关于已发布发行版镜像的加密签名声明。CVO 使用内置公钥列表来验证与已检查的发行版镜像匹配的声明的存在性和签名。

  4. CVO 在 openshift-cluster-version 命名空间中创建一个名为 version-$version-$hash 的作业。此作业使用执行发行版镜像的容器,因此集群通过容器运行时下载镜像。然后,该作业将清单文件和元数据从发行版镜像提取到 CVO 可访问的共享卷中。

  5. CVO 验证提取的清单文件和元数据。

  6. CVO 检查一些前提条件,以确保在集群中未检测到任何问题条件。某些条件可能会阻止更新继续进行。这些条件是由 CVO 本身确定,或由检测到操作符认为对更新有问题的集群某些细节的各个集群操作符报告。

  7. CVO 将接受的发行版记录在 status.desired 中,并创建一个关于新更新的 status.history 条目。

  8. CVO 开始协调发行版镜像中的清单文件。集群操作符在称为运行级别的单独阶段进行更新,CVO 确保在一个运行级别中的所有操作符完成更新后才能继续到下一个级别。

  9. CVO 本身的清单文件在流程早期应用。当应用 CVO 部署时,当前 CVO pod 将停止,并启动使用新版本的 CVO pod。新的 CVO 将继续协调剩余的清单文件。

  10. 更新将持续进行,直到整个控制平面更新到新版本。各个集群操作符可能会在其集群域上执行更新任务,并且在执行这些任务时,它们会通过 Progressing=True 条件报告其状态。

  11. 机器配置操作符 (MCO) 清单文件在流程结束时应用。更新后的 MCO 然后开始更新每个节点的系统配置和操作系统。

在控制平面更新完成后,通常在所有节点更新之前,集群报告已更新。更新后,CVO 保持所有集群资源与发行版镜像中交付的状态匹配。

了解更新期间清单文件的应用方式

发行版镜像中提供的一些清单文件必须按照一定的顺序应用,因为它们之间存在依赖关系。例如,必须在创建匹配的自定义资源之前创建 CustomResourceDefinition 资源。此外,各个集群操作符的更新还存在逻辑顺序,以最大限度地减少集群中断。集群版本操作符 (CVO) 通过运行级别的概念实现此逻辑顺序。

这些依赖关系编码在发行版镜像中清单文件的名称中。

0000_<runlevel>_<component>_<manifest-name>.yaml

例如

0000_03_config-operator_01_proxy.crd.yaml

CVO 在内部为清单文件构建依赖关系图,其中 CVO 遵守以下规则:

  • 在更新期间,较低运行级别的清单文件先于较高运行级别的清单文件应用。

  • 在一个运行级别内,不同组件的清单文件可以并行应用。

  • 在一个运行级别内,单个组件的清单文件按字典顺序应用。

然后,CVO 按照生成的依赖关系图应用清单文件。

对于某些资源类型,CVO 在应用其清单文件后会监控该资源,并且只有在该资源达到稳定状态后才认为它已成功更新。达到此状态可能需要一些时间。这对于 ClusterOperator 资源尤其如此,而 CVO 则等待集群操作符自行更新,然后更新其 ClusterOperator 状态。

在 CVO 继续到下一个运行级别之前,它会等待该运行级别中的所有集群操作符满足以下条件:

  • 集群操作符具有 Available=True 条件。

  • 集群操作符具有 Degraded=False 条件。

  • 集群操作符声明它们已在其 ClusterOperator 资源中达到所需版本。

某些操作可能需要大量时间才能完成。CVO 等待操作完成,以确保后续运行级别可以安全地继续进行。最初协调新发行版的清单文件预计总共需要 60 到 120 分钟;有关影响更新持续时间的因素的更多信息,请参见**了解 OpenShift Container Platform 更新持续时间**。

A diagram displaying the sequence of Runlevels and the manifests of components within each level

在前面的示例图中,CVO 正在等待运行级别 20 中的所有工作完成。CVO 已将所有清单文件应用于运行级别中的操作符,但 kube-apiserver-operator ClusterOperator 在其新版本部署后执行某些操作。kube-apiserver-operator ClusterOperator 通过 Progressing=True 条件以及在其 status.versions 中未声明新版本已协调来声明此进度。CVO 将等待 ClusterOperator 报告可接受的状态,然后它将开始协调运行级别 25 的清单文件。

了解机器配置操作符如何更新节点

机器配置操作符 (MCO) 将新的机器配置应用于每个控制平面节点和计算节点。在机器配置更新期间,控制平面节点和计算节点被组织到它们自己的机器配置池中,其中机器池并行更新。.spec.maxUnavailable 参数(默认值为 1)决定机器配置池中可以同时进行更新过程的节点数量。

OpenShift Container Platform 中所有机器配置池的 maxUnavailable 默认设置为 1。建议不要更改此值,并一次更新一个控制平面节点。不要将控制平面池的此值更改为 3

当机器配置更新过程开始时,MCO 检查池中当前不可用节点的数量。如果不可用节点少于 .spec.maxUnavailable 的值,则 MCO 将在池中可用的节点上启动以下操作序列:

  1. 隔离并驱逐节点

    隔离节点后,无法将工作负载调度到该节点。

  2. 更新节点的系统配置和操作系统 (OS)

  3. 重新启动节点

  4. 取消隔离节点

正在进行此过程的节点在取消隔离并可以再次将工作负载调度到其之前都不可用。MCO 开始更新节点,直到不可用节点的数量等于 .spec.maxUnavailable 的值。

当节点完成更新并变为可用时,机器配置池中不可用节点的数量再次少于 .spec.maxUnavailable。如果还有需要更新的节点,则 MCO 将启动对节点的更新过程,直到再次达到 .spec.maxUnavailable 限制。此过程将重复进行,直到每个控制平面节点和计算节点都已更新。

以下示例工作流程描述了此过程如何在具有 5 个节点的机器配置池中发生,其中.spec.maxUnavailable 为 3,并且所有节点最初都可用。

  1. MCO cordon 了节点 1、2 和 3,并开始将其 draining。

  2. 节点 2 完成 draining,重新启动并再次可用。MCO cordon 了节点 4 并开始将其 draining。

  3. 节点 1 完成 draining,重新启动并再次可用。MCO cordon 了节点 5 并开始将其 draining。

  4. 节点 3 完成 draining,重新启动并再次可用。

  5. 节点 5 完成 draining,重新启动并再次可用。

  6. 节点 4 完成 draining,重新启动并再次可用。

由于每个节点的更新过程与其他节点无关,因此上述示例中某些节点的更新完成顺序与其被 MCO cordon 的顺序不同。

您可以运行以下命令检查机器配置更新的状态

$ oc get mcp
示例输出
NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
worker       rendered-worker-1d871ac76e1951d32b2fe92369879826       False     True       False      2              1                   1                     0                      22h
其他资源