$ oc adm upgrade --include-not-recommended
以下部分详细描述了 OpenShift Container Platform (OCP) 更新过程的各个主要方面。有关更新工作原理的概述,请参阅OpenShift 更新简介。
集群版本操作符 (CVO) 是协调和促进 OpenShift Container Platform 更新过程的主要组件。在安装和标准集群操作期间,CVO 不断将托管集群操作符的清单与集群内资源进行比较,并协调差异以确保这些资源的实际状态与其期望状态匹配。
集群版本操作符 (CVO) 监控的资源之一是ClusterVersion
资源。
管理员和 OpenShift 组件可以通过ClusterVersion
对象与 CVO 进行通信或交互。期望的 CVO 状态通过ClusterVersion
对象声明,而当前的 CVO 状态则反映在对象的 status 中。
请勿直接修改 |
CVO 不断将集群与ClusterVersion
资源的spec
属性中声明的目标状态进行协调。当期望的发行版与实际发行版不同时,该协调将更新集群。
ClusterVersion
资源还包含有关可用于集群的更新的信息。这包括可用的更新,但不建议由于适用于集群的已知风险而使用这些更新。这些更新称为条件更新。要了解 CVO 如何在ClusterVersion
资源中维护有关可用更新的信息,请参阅“更新可用性评估”部分。
您可以使用以下命令检查所有可用更新
$ oc adm upgrade --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
资源的availableUpdates
或conditionalUpdates
字段中。
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-operator 的 PrometheusRoleBinding 资源清单文件,将在运行级别 90 应用 |
3 | 所有必需镜像的 SHA 摘要版本引用列表 |
以下步骤详细描述了 OpenShift Container Platform (OCP) 更新流程
目标版本存储在 ClusterVersion
资源的 spec.desiredUpdate.version
字段中,可以通过 Web 控制台或 CLI 进行管理。
集群版本操作符 (CVO) 检测到 ClusterVersion
资源中的 desiredUpdate
与当前集群版本不同。CVO 使用来自 OpenShift 更新服务的图形数据,将所需的集群版本解析为发行版镜像的拉取规范。
CVO 验证发行版镜像的完整性和真实性。Red Hat 使用镜像 SHA 摘要作为唯一且不可变的发行版镜像标识符,在预定义位置发布关于已发布发行版镜像的加密签名声明。CVO 使用内置公钥列表来验证与已检查的发行版镜像匹配的声明的存在性和签名。
CVO 在 openshift-cluster-version
命名空间中创建一个名为 version-$version-$hash
的作业。此作业使用执行发行版镜像的容器,因此集群通过容器运行时下载镜像。然后,该作业将清单文件和元数据从发行版镜像提取到 CVO 可访问的共享卷中。
CVO 验证提取的清单文件和元数据。
CVO 检查一些前提条件,以确保在集群中未检测到任何问题条件。某些条件可能会阻止更新继续进行。这些条件是由 CVO 本身确定,或由检测到操作符认为对更新有问题的集群某些细节的各个集群操作符报告。
CVO 将接受的发行版记录在 status.desired
中,并创建一个关于新更新的 status.history
条目。
CVO 开始协调发行版镜像中的清单文件。集群操作符在称为运行级别的单独阶段进行更新,CVO 确保在一个运行级别中的所有操作符完成更新后才能继续到下一个级别。
CVO 本身的清单文件在流程早期应用。当应用 CVO 部署时,当前 CVO pod 将停止,并启动使用新版本的 CVO pod。新的 CVO 将继续协调剩余的清单文件。
更新将持续进行,直到整个控制平面更新到新版本。各个集群操作符可能会在其集群域上执行更新任务,并且在执行这些任务时,它们会通过 Progressing=True
条件报告其状态。
机器配置操作符 (MCO) 清单文件在流程结束时应用。更新后的 MCO 然后开始更新每个节点的系统配置和操作系统。
在控制平面更新完成后,通常在所有节点更新之前,集群报告已更新。更新后,CVO 保持所有集群资源与发行版镜像中交付的状态匹配。
发行版镜像中提供的一些清单文件必须按照一定的顺序应用,因为它们之间存在依赖关系。例如,必须在创建匹配的自定义资源之前创建 CustomResourceDefinition
资源。此外,各个集群操作符的更新还存在逻辑顺序,以最大限度地减少集群中断。集群版本操作符 (CVO) 通过运行级别的概念实现此逻辑顺序。
这些依赖关系编码在发行版镜像中清单文件的名称中。
0000_<runlevel>_<component>_<manifest-name>.yaml
例如
0000_03_config-operator_01_proxy.crd.yaml
CVO 在内部为清单文件构建依赖关系图,其中 CVO 遵守以下规则:
在更新期间,较低运行级别的清单文件先于较高运行级别的清单文件应用。
在一个运行级别内,不同组件的清单文件可以并行应用。
在一个运行级别内,单个组件的清单文件按字典顺序应用。
然后,CVO 按照生成的依赖关系图应用清单文件。
对于某些资源类型,CVO 在应用其清单文件后会监控该资源,并且只有在该资源达到稳定状态后才认为它已成功更新。达到此状态可能需要一些时间。这对于 |
在 CVO 继续到下一个运行级别之前,它会等待该运行级别中的所有集群操作符满足以下条件:
集群操作符具有 Available=True
条件。
集群操作符具有 Degraded=False
条件。
集群操作符声明它们已在其 ClusterOperator 资源中达到所需版本。
某些操作可能需要大量时间才能完成。CVO 等待操作完成,以确保后续运行级别可以安全地继续进行。最初协调新发行版的清单文件预计总共需要 60 到 120 分钟;有关影响更新持续时间的因素的更多信息,请参见**了解 OpenShift Container Platform 更新持续时间**。
在前面的示例图中,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 中所有机器配置池的 |
当机器配置更新过程开始时,MCO 检查池中当前不可用节点的数量。如果不可用节点少于 .spec.maxUnavailable
的值,则 MCO 将在池中可用的节点上启动以下操作序列:
隔离并驱逐节点
隔离节点后,无法将工作负载调度到该节点。 |
更新节点的系统配置和操作系统 (OS)
重新启动节点
取消隔离节点
正在进行此过程的节点在取消隔离并可以再次将工作负载调度到其之前都不可用。MCO 开始更新节点,直到不可用节点的数量等于 .spec.maxUnavailable
的值。
当节点完成更新并变为可用时,机器配置池中不可用节点的数量再次少于 .spec.maxUnavailable
。如果还有需要更新的节点,则 MCO 将启动对节点的更新过程,直到再次达到 .spec.maxUnavailable
限制。此过程将重复进行,直到每个控制平面节点和计算节点都已更新。
以下示例工作流程描述了此过程如何在具有 5 个节点的机器配置池中发生,其中.spec.maxUnavailable
为 3,并且所有节点最初都可用。
MCO cordon 了节点 1、2 和 3,并开始将其 draining。
节点 2 完成 draining,重新启动并再次可用。MCO cordon 了节点 4 并开始将其 draining。
节点 1 完成 draining,重新启动并再次可用。MCO cordon 了节点 5 并开始将其 draining。
节点 3 完成 draining,重新启动并再次可用。
节点 5 完成 draining,重新启动并再次可用。
节点 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