Language:
Format:

更新集群

OpenShift Container Platform 4.2

更新 OpenShift Container Platform 4.2 集群

Red Hat OpenShift Documentation Team

法律通告

摘要

本文档提供了有关更新和升级 OpenShift Container Platform 4.2 集群的信息。在版本 4.2 中，更新集群的过程较简单，可以在不需要使集群离线的情况下进行。

第 1 章在次版本间更新集群

您可以在次版本（minor version）间更新或升级 OpenShift Container Platform 集群。

注意

由于使用 oc更改更新频道会比较困难，所以请使用 web 控制台来更改更新频道。建议您在 web 控制台中完成更新过程。在改到一个 4.2 频道后，按照使用 CLI 在一个次版本中更新集群中介绍的步骤进行操作。

先决条件

使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义并应用权限。
请保存一个最新的 etcd backup。如果升级失败，则需要把集群恢复到一个以前的状态。

1.1. 关于 OpenShift Container Platform 更新服务

OpenShift Container Platform 更新服务是一种托管服务，为 OpenShift Container Platform 和 Red Hat Enterprise Linux CoreOS (RHCOS) 提供无线更新 (over-the air update)。它提供了一个组件 Operator 图，其中包含各个顶点及连接它们的边。图中的边显示可以安全更新的版本，顶点是更新有效负载，用于指定托管集群组件的预期状态。

集群中的 Cluster Version Operator (CVO) 会检查 OpenShift Container Platform 更新服务，并根据当前组件版本和图中的信息决定有效的更新和更新路径。当您请求更新时，OpenShift Container Platform CVO 使用该更新的发行镜像来升级您的集群。发行工件 (artifact) 作为容器镜像托管在 Quay 中。

为了使 OpenShift Container Platform 更新服务仅提供兼容的更新，提供了一个版本验证管道来驱动自动化。每个发行工件都会被验证是否与支持的云平台和系统架构以及其他组件包兼容。在管道确认有适用的版本后，OpenShift Container Platform 更新服务会通知您可以进行更新。

重要

因为更新服务会显示所有有效的更新，所以不能强制更新到一个更新服务没有显示的版本。

对于连续更新模式，会运行两个控制器。一个控制器不断更新有效负载清单，将它们应用于集群，并输出受控 Operator 部署的状态（可用、正在进行升级或失败）。第二个控制器轮询 OpenShift Container Platform 更新服务以确定更新是否可用。

重要

不支持将集群还原到以前的版本或执行回滚。仅支持升级到较新版本。

其他资源

非受管 Operator 的支持策略

1.2. OpenShift Container Platform 升级频道和发行版本

在 OpenShift Container Platform 4.1 中，红帽引进了升级频道的概念，用于为集群升级推荐适当的版本。通过控制升级的速度，这些升级频道允许您选择升级策略。升级频道与 OpenShift Container Platform 的次要版本关联。例如，OpenShift Container Platform 4.2 升级频道永远不会包括到版本 4.3 的升级。这可确保管理员明确决定升级到下一个 OpenShift Container Platform 次要版本。升级频道仅控制版本选择，它不会影响您安装的集群版本; 特定版本的 OpenShift Container Platform 的 openshift-install 二进制文件始终会安装这个特定版本。

OpenShift Container Platform 4.2 提供了以下升级频道：

candidate-4.2
fast-4.2
stable-4.2

candidate-4.2 频道

candidate-4.2 频道包含 z-stream (4.2.z) 发行版本的候选构建。发行候选版本包含该产品的所有功能但不被正式支持。发行候选版本可以用来测试新版本的功能以决定下一个 OpenShift Container Platform 版本是否适用于您的系统。发行候选是指候选频道中的一个构建，包括那些名称中没有 -rc 的构建。当一个版本出现在候选频道中后，它仍然会进行更多的质量测试。如果达到质量标准，则会将其推广至 fast-4.2 或 stable-4.2 频道。因此，如果一个特定的版本同时存在于 candidate-4.2频道以及 fast-4.2 或 stable-4.2 频道中，则代表红帽会支持这个版本。candidate-4.2 频道可能会包括任何频道都不推荐更新的发行版本。

您可以使用 candidate-4.2 频道以前的 OpenShift Container Platform 次版本进行升级。

注意

发行候选版本与每日构建的，由 https://www.openshift.com/try 提供的版本不同。用户可以使用每日构建的版本试用新功能，但升级到每日构建的版本或从每日构建的版本升级不被支持。所有升级频道都没有包括每日构建的版本。

fast-4.2 频道

当红帽声明某个特定版本成为正式发行版本时，fast-4.2 频道被更新来包括这个新的 4.2 版本。这意味着，这些版本被完全支持，且具有符合生产环境的质量，当它们作为发行候选版本出现在 candidate-4.2 频道期间，被证明可以正常工作。当一个发行版本出现在 fast-4.2 频道中的一段时间后，会被添加到 stable-4.2 频道。如果版本没有出现在 fast-4.2 频道中，则这个版本一定不会出现在 stable-4.2 频道中。

您可以使用 fast-4.2 频道来从以前的 OpenShift Container Platform 次版本进行升级。

stable-4.2 频道

虽然当它们的勘误被发布后马上就会出现在 fast-4.2 频道中，但这些内容可能需要等待几个小时或一天的时间才会被添加到 stable-4.2 频道中。在此延迟期间，红帽 SRE 团队、红帽支持服务以及参与连接的客户程序的生产前和产品环境中收集有关此发行版本的稳定性数据。

您可以使用 stable-4.2 频道来从以前的 OpenShift Container Platform 次要版本升级。

升级版本路径

OpenShift Container Platform 维护一个升级建议服务，它了解已安装的 OpenShift Container Platform 版本以及您选择用来获取下一版本的频道中的路径。您可在 fast-4.2 频道中看到以下内容：

4.2.0
4.2.1
4.2.3
4.2.4

该服务只建议经过测试且不存在严重问题的升级。如果您的集群为 4.2.1，OpenShift Container Platform 建议为 4.2.4，那么可以安全地从 .4.2.1 升级到 .4.2.4。您不需要一定在连续的补丁号间进行升级。在这个示例中，该频道并没有（且重来没有）包括 4.2.2。更新服务不会建议把系统更新到一个包含具有已知漏洞的 OpenShift Container Platform 版本。

更新的稳定性取决于您的频道。在 candidate-4.2 频道中存在一个更新建议并不意味着这个更新会被支持。它代表，在更新中还没有发现任何严重问题，这可能是因为此更新还没有足够的使用情况来证明它的稳定性。如果在 fast-4.2 或 stable-4.2 频道中出现了一个更新建议，则代表这个更新被完全支持。虽然发行版本永远不会从一个频道中删除，但存在严重问题的更新建议会从所有频道中删除。在更新建议被删除后才初始的更新可能不被支持。

红帽最终会为 fast-4.2 或 stable-4.2 频道中支持的发行版本提供到最新的 4.2.z 版本的更新路径，但可能会因为创建并验证解决已知问题的更新路径而有一定的延迟。

fast 和 stable 频道的使用和策略

通过 fast-4.2 和 stable-4.2 频道，您可以选择在一个发行版本正式发行后马上接收到这个版本，或选择由红帽控制向用户推出更新的过程。如果在推出部署的过程或之后发现问题，到这个版本的升级会在fast-4.2 和 stable-4.2 频道中被禁止。一个新版本可能会出现，做为新的首选升级目标。

通过在 fast-4.2 频道中配置预生产环境的系统、在 stable-4.2 频道中配置生产环境的系统，并参与红帽连接的客户项目，用户可以改进更新的过程。红帽使用这个程序观察更新对您特定的硬件和软件配置的影响。将来的版本可能会改进或修改更新从 fast-4.2 频道进入 stable-4.2 频道的速度。

受限网络集群

如果您自己为 OpenShift Container Platform 集群管理容器镜像，您必须考虑与产品关联的红帽勘误中的升级信息。在升级过程中，用户界面可能会提醒您在这些版本间进行切换，因此您必须在跳过这些警告前确定选择了正确的版本。

在频道间切换

如果您从 stable-4.2 频道改到 fast-4.2 频道，您的集群仍然被支持。虽然您可以在任何时候切换到 candidate-4.2 频道，但该频道中的一些发行版本可能不被支持。如果您当前的发行本是正式发布版本，则可以从 candidate-4.2 频道切换到 fast-4.2 频道。从 fast-4.2 频道切换到 stable-4.4 频道一直被允许，但如果当前的发行版本最近被升级到 fast-4.2，则可能会有最多一天的延迟该发行版本才会出现在 stable-4.2 中。如果您改到的频道没有包括您当前的发行版本，则会出现一个警告信息且不会有建议的更新，但您可以随时安全地切换回您原来地频道。

1.3. 使用Web控制台更新集群

如果有可用更新，您可以从Web控制台更新集群。

您可以在客户门户网站的勘误部分找到有关可用的OpenShift Container Platform公告和更新的信息。

先决条件

使用具有 admin 权限的用户登陆到 web 控制台。

流程

在 web 控制台中点 Administration > Cluster Settings，查看 Overview 标签页中的内容。
对于生产环境中的集群，请确保将 CHANNEL 设置为您当前使用的次版本的正确频道，如 stable-4.2。
重要
对于生产环境中的集群，需要订阅到 stable-* 或 fast-* 频道。
- 如果 UPDATE STATUS 的值不是 Updates Available，则不能升级您的集群。
- DESIRED VERSION显示正在运行的集群版本，或正在更新到的集群版本。
点 Updates Available，选择最高可用版本并点 Update。UPDATE STATUS会变为Updating ，您可以在Cluster Operators页中查看Operator升级的进度。
更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。
- 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
- 如果没有可用的更新，将 CHANNEL 改为下一个次版本的 stable-* 或者 fast-* 频道，并更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新，直到您到达您想要的版本。

第 2 章通过 web 控制台将集群更新为一个新的次版本

您可以使用 web 控制台对 OpenShift Container Platform 集群进行更新或升级。

先决条件

使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义并应用权限。
请保存一个最新的 etcd backup。如果升级失败，则需要把集群恢复到一个以前的状态。

2.1. 关于 OpenShift Container Platform 更新服务

重要

因为更新服务会显示所有有效的更新，所以不能强制更新到一个更新服务没有显示的版本。

重要

不支持将集群还原到以前的版本或执行回滚。仅支持升级到较新版本。

其他资源

非受管 Operator 的支持策略

2.2. OpenShift Container Platform 升级频道和发行版本

OpenShift Container Platform 4.2 提供了以下升级频道：

candidate-4.2
fast-4.2
stable-4.2

candidate-4.2 频道

您可以使用 candidate-4.2 频道以前的 OpenShift Container Platform 次版本进行升级。

注意

fast-4.2 频道

您可以使用 fast-4.2 频道来从以前的 OpenShift Container Platform 次版本进行升级。

stable-4.2 频道

您可以使用 stable-4.2 频道来从以前的 OpenShift Container Platform 次要版本升级。

升级版本路径

4.2.0
4.2.1
4.2.3
4.2.4

fast 和 stable 频道的使用和策略

受限网络集群

在频道间切换

2.3. 使用Web控制台更新集群

如果有可用更新，您可以从Web控制台更新集群。

您可以在客户门户网站的勘误部分找到有关可用的OpenShift Container Platform公告和更新的信息。

先决条件

使用具有 admin 权限的用户登陆到 web 控制台。

流程

在 web 控制台中点 Administration > Cluster Settings，查看 Overview 标签页中的内容。
对于生产环境中的集群，请确保将 CHANNEL 设置为您要升级到的版本的正确频道，如 stable-4.2。
重要
对于生产环境中的集群，需要订阅到 stable-* 或 fast-* 频道。
- 如果 UPDATE STATUS 的值不是 Updates Available，则不能升级您的集群。
- DESIRED VERSION显示正在运行的集群版本，或正在更新到的集群版本。
点 Updates Available，选择要更新到的版本，最新可用版本并点 Update。UPDATE STATUS会变为Updating ，您可以在Cluster Operators页中查看Operator升级的进度。
更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。
- 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
- 如果没有可用的更新，将 CHANNEL 改为下一个次版本的 stable-* 或者 fast-* 频道，并更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新，直到您到达您想要的版本。

第 3 章使用 CLI 将集群更新为一个新的次版本

您可以使用 OpenShift CLI (oc) 将 OpenShift Container Platform 集群更新或升级到一个次版本。

先决条件

使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义并应用权限。
请保存一个最新的 etcd backup。如果升级失败，则需要把集群恢复到一个以前的状态。

3.1. 关于 OpenShift Container Platform 更新服务

重要

因为更新服务会显示所有有效的更新，所以不能强制更新到一个更新服务没有显示的版本。

重要

不支持将集群还原到以前的版本或执行回滚。仅支持升级到较新版本。

其他资源

非受管 Operator 的支持策略

3.2. OpenShift Container Platform 升级频道和发行版本

OpenShift Container Platform 4.2 提供了以下升级频道：

candidate-4.2
fast-4.2
stable-4.2

candidate-4.2 频道

您可以使用 candidate-4.2 频道以前的 OpenShift Container Platform 次版本进行升级。

注意

fast-4.2 频道

您可以使用 fast-4.2 频道来从以前的 OpenShift Container Platform 次版本进行升级。

stable-4.2 频道

您可以使用 stable-4.2 频道来从以前的 OpenShift Container Platform 次要版本升级。

升级版本路径

4.2.0
4.2.1
4.2.3
4.2.4

fast 和 stable 频道的使用和策略

受限网络集群

在频道间切换

3.3. 使用 CLI 更新集群

如果有可用更新，您可以使用OpenShift CLI (oc)更新集群。

您可以在客户门户网站的勘误部分找到有关可用的OpenShift Container Platform公告和更新的信息。

先决条件

安装与更新版本的版本相匹配的OpenShift命令行界面（CLI）版本（通常称为oc ）。
使用具有 cluster-admin 权限的用户登陆到集群。
安装jq软件包。

流程

确认集群可用

$ oc get clusterversion

NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.2.0     True        False         158m    Cluster version is 4.2.0

检查当前的更新频道信息，并确认您的频道已设置为stable-4.2 ：

$ oc get clusterversion -o json|jq ".items[0].spec"

{
  "channel": "stable-4.2",
  "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
  "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
}

重要

对于生产环境集群，您必须订阅一个 stable-* 频道。

查看可用更新，记录下要应用的更新的版本号：

$ oc adm upgrade

Cluster version is 4.1.0

Updates:

VERSION IMAGE
4.1.2   quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b

应用更新：
- 要更新到最新版本：
```
$ oc adm upgrade --to-latest=true 1
```
- 要更新到一个特定版本：
```
$ oc adm upgrade --to=<version> 1
```
  1 1
  <version>是从上一个命令输出中获取的更新版本。

查看 Cluster Version Operator 的状态：

$ oc get clusterversion -o json|jq ".items[0].spec"

{
  "channel": "stable-4.2",
  "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
  "desiredUpdate": {
    "force": false,
    "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
    "version": "4.2.1" 1
  },
  "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
}

1: 如果desiredUpdate中的version值与您指定的值匹配，则更新正在进行中。

查看集群版本状态历史记录以监控更新的状态。这可能需要一些时间才能完成对所有对象的更新。
```
$ oc get clusterversion -o json|jq ".items[0].status.history"

[
  {
    "completionTime": null,
    "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
    "startedTime": "2019-06-19T20:30:50Z",
    "state": "Partial",
    "verified": true,
    "version": "4.1.2"
  },
  {
    "completionTime": "2019-06-19T20:30:50Z",
    "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8307ac0f3ec4ac86c3f3b52846425205022da52c16f56ec31cbe428501001d6",
    "startedTime": "2019-06-19T17:38:10Z",
    "state": "Completed",
    "verified": false,
    "version": "4.1.0"
  }
]
```
历史记录包含了应用于集群的最新版本的列表。当CVO应用更新时，此值将会被相应更新。该列表按日期排序，最新的更新会在列表中第一个显示。如果历史信息中的更新状态为 Completed，则表示部署已完成；如果状态为 Partial，则表示更新失败或还未完成。
重要
如果升级失败，Operator 将停止操作并报告故障组件的状态。当前还不支持将集群还原到以前的版本。如果升级失败，请联系红帽支持。

更新完成后，可以通过以下方法确认集群已更新为新版本：

$ oc get clusterversion

NAME      VERSION     AVAILABLE   PROGRESSING   SINCE     STATUS
version   4.1.2       True        False         2m        Cluster version is 4.1.2

第 4 章更新包含使用 RHEL 的计算（compute）系统的集群

您可以更新或升级OpenShift Container Platform集群。如果您的集群包含Red Hat Enterprise Linux（RHEL）系统，则必须执行额外的步骤来更新这些系统。

先决条件

使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义并应用权限。
请保存一个最新的 etcd backup。如果升级失败，则需要把集群恢复到一个以前的状态。

4.1. 关于 OpenShift Container Platform 更新服务

重要

因为更新服务会显示所有有效的更新，所以不能强制更新到一个更新服务没有显示的版本。

重要

不支持将集群还原到以前的版本或执行回滚。仅支持升级到较新版本。

其他资源

非受管 Operator 的支持策略

4.2. OpenShift Container Platform 升级频道和发行版本

OpenShift Container Platform 4.2 提供了以下升级频道：

candidate-4.2
fast-4.2
stable-4.2

candidate-4.2 频道

您可以使用 candidate-4.2 频道以前的 OpenShift Container Platform 次版本进行升级。

注意

fast-4.2 频道

您可以使用 fast-4.2 频道来从以前的 OpenShift Container Platform 次版本进行升级。

stable-4.2 频道

您可以使用 stable-4.2 频道来从以前的 OpenShift Container Platform 次要版本升级。

升级版本路径

4.2.0
4.2.1
4.2.3
4.2.4

fast 和 stable 频道的使用和策略

受限网络集群

在频道间切换

4.3. 使用Web控制台更新集群

如果有可用更新，您可以从Web控制台更新集群。

您可以在客户门户网站的勘误部分找到有关可用的OpenShift Container Platform公告和更新的信息。

先决条件

使用具有 admin 权限的用户登陆到 web 控制台。

流程

在 web 控制台中点 Administration > Cluster Settings，查看 Overview 标签页中的内容。
对于生产环境中的集群，请确保将 CHANNEL 设置为您要升级到的版本的正确频道，如 stable-4.2。
重要
对于生产环境中的集群，需要订阅到 stable-* 或 fast-* 频道。
- 如果 UPDATE STATUS 的值不是 Updates Available，则不能升级您的集群。
- DESIRED VERSION显示正在运行的集群版本，或正在更新到的集群版本。
点 Updates Available，选择要更新到的版本，最新可用版本并点 Update。UPDATE STATUS会变为Updating ，您可以在Cluster Operators页中查看Operator升级的进度。
更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。
- 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
- 如果没有可用的更新，将 CHANNEL 改为下一个次版本的 stable-* 或者 fast-* 频道，并更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新，直到您到达您想要的版本。

4.4. （可选）添加 hook 以在RHEL系统上执行Ansible任务

在OpenShift Container Platform更新期间，您可以使用hook在RHEL计算系统上运行Ansible任务。

4.4.1. 在升级过程中使用 Ansible hook

更新OpenShift Container Platform时，可以使用hook在执行特定操作时在Red Hat Enterprise Linux（RHEL）节点上运行自定义的任务。您可以使用 hook 提供定义了在执行特定任务之前或之后要运行的任务的文件。在OpenShift Container Platform集群中更新RHEL计算节点时，可以使用 hook 来验证或修改自定义的基础架构。

因为当 hook 失败时，这个操作将会失败，所以您必须把 hook 设计为可以多次运行，并且获得相同的结果。

hook 有以下限制： - hook 没有已定义或版本化的界面。它们可以使用内部的openshift-ansible变量，但这些变量可能会在将来的OpenShift Container Platform版本被修改或删除。 - hook 本身没有错误处理机制，因此 hook 中的错误会暂停更新过程。如果出现错误，则需要解决相关的问题，然后再次进行升级。

4.4.2. 配置Ansible inventory文件以使用 hook

您可以在 hosts inventory 文件的all:vars 部分中定义 Red Hat Enterprise Linux（RHEL）compute 机器（也称为 worker 机器）更新时使用的 hook 。

先决条件

您可以访问用于添加RHEL compute 系统集群的计算机。您必须有访问定义RHEL系统的hosts Ansible 清单文件的权限。

流程

在设计了 hook 后，创建一个YAML文件，为其定义Ansible任务。此文件必须是一组任务，不能是一个 playbook，如以下示例所示：

---
# Trivial example forcing an operator to acknowledge the start of an upgrade
# file=/home/user/openshift-ansible/hooks/pre_compute.yml

- name: note the start of a compute machine update
  debug:
      msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"

- name: require the user agree to start an upgrade
  pause:
      prompt: "Press Enter to start the compute machine update"

修改 hosts Ansible inventory 文件来指定 hook 文件。hook 文件作为参数值在 [all:vars] 部分指定。如下所示：
清单文件中的 hook 定义示例
```
[all:vars]
openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml
```
为了避免歧义，请在其定义中使用 hook 文件的绝对路径而不要使用相对路径。

4.4.3. RHEL计算系统可用的 hook

在更新OpenShift Container Platform集群中的Red Hat Enterprise Linux（RHEL）compute 系统时，可以使用以下 hook。

Hook 名	描述
`openshift_node_pre_cordon_hook`	在每个节点被封锁（cordon）之前运行。此 hook 以串行方式针对每个节点运行。如果某个任务必须针对其他主机运行，则该任务必须使用`delegate_to`或`local_action` 。
`openshift_node_pre_upgrade_hook`	在每个节点被封锁后，且被更新前运行。此 hook 以串行方式针对每个节点运行。如果某个任务必须针对其他主机运行，则该任务必须使用`delegate_to`或`local_action` 。
`openshift_node_pre_uncordon_hook`	在每个节点被更新后，且被取消封锁（uncordon）前运行。此 hook 以串行方式针对每个节点运行。如果某个任务必须针对其他主机运行，则该任务必须使用`delegate_to`或`local_action` 。
`openshift_node_post_upgrade_hook`	每个节点未被取消封锁后运行。这是最后一个节点更新操作。此 hook 以串行方式针对每个节点运行。如果某个任务必须针对其他主机运行，则该任务必须使用`delegate_to`或`local_action` 。

4.5. 更新集群中的RHEL compute 系统

在对集群进行更新后，必须更新集群中的Red Hat Enterprise Linux（RHEL）compute 系统。

先决条件

已更新了集群
重要
由于RHEL系统需要集群生成的资产才能完成更新过程，因此必须在更新其中的RHEL compute 系统前更新集群。
您可以访问用于添加RHEL compute 系统集群的计算机。您必须有权访问定义了 RHEL 系统及 upgrade playbook 的hosts Ansible 清单文件。

流程

停止并禁用主机上的防火墙：
```
# systemctl disable --now firewalld.service
```
注意
请不要在以后启用防火墙。如果这样做，则无法访问 worker 上的 OpenShift Container Platform 日志。

启用 OpenShift Container Platform 4.2 所需的存储库：

在运行 Ansible playbook 的机器上，更新所需的存储库：

# subscription-manager repos --disable=rhel-7-server-ansible-2.7-rpms  \
                             --disable=rhel-7-server-ose-4.1-rpms \
                             --enable=rhel-7-server-ansible-2.8-rpms \
                             --enable=rhel-7-server-ose-4.2-rpms

在运行 Ansible playbook 的机器上，更新所需的软件包，包括 openshift-ansible：
```
# yum update openshift-ansible openshift-clients
```

在每个 RHEL 计算节点上，更新所需的软件仓库：

# subscription-manager repos --disable=rhel-7-server-ose-4.1-rpms \
                             --enable=rhel-7-server-ose-4.2-rpms

检查/<path>/inventory/hostsAnsible清单文件，确定所有 compute 或 worker 都列在[workers]部分中，如以下示例所示：
```
[all:vars]
ansible_user=root
#ansible_become=True

openshift_kubeconfig_path="~/.kube/config"

[workers]
mycluster-worker-0.example.com
mycluster-worker-1.example.com
mycluster-worker-2.example.com
mycluster-worker-3.example.com
```
如果[workers]部分中未列出所有RHEL compute 系统，则需要将它们移到该部分。
切换到openshift-ansible目录并运行升级 playbook：
```
$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1
```
1
对于<path> ，指定您创建的Ansible库存文件的路径。

法律通告

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Language and Page Formatting Options

更新集群

更新 OpenShift Container Platform 4.2 集群

第 1 章 在次版本间更新集群

1.1. 关于 OpenShift Container Platform 更新服务

1.2. OpenShift Container Platform 升级频道和发行版本

candidate-4.2 频道

fast-4.2 频道

stable-4.2 频道

升级版本路径

fast 和 stable 频道的使用和策略

受限网络集群

在频道间切换

1.3. 使用Web控制台更新集群

第 2 章 通过 web 控制台将集群更新为一个新的次版本

2.1. 关于 OpenShift Container Platform 更新服务

2.2. OpenShift Container Platform 升级频道和发行版本

candidate-4.2 频道

fast-4.2 频道

stable-4.2 频道

升级版本路径

fast 和 stable 频道的使用和策略

受限网络集群

在频道间切换

2.3. 使用Web控制台更新集群

第 3 章 使用 CLI 将集群更新为一个新的次版本

3.1. 关于 OpenShift Container Platform 更新服务

3.2. OpenShift Container Platform 升级频道和发行版本

candidate-4.2 频道

fast-4.2 频道

stable-4.2 频道

升级版本路径

fast 和 stable 频道的使用和策略

受限网络集群

在频道间切换

3.3. 使用 CLI 更新集群

第 4 章 更新包含使用 RHEL 的计算（compute）系统的集群

4.1. 关于 OpenShift Container Platform 更新服务

4.2. OpenShift Container Platform 升级频道和发行版本

candidate-4.2 频道

fast-4.2 频道

stable-4.2 频道

升级版本路径

fast 和 stable 频道的使用和策略

受限网络集群

在频道间切换

4.3. 使用Web控制台更新集群

4.4. （可选）添加 hook 以在RHEL系统上执行Ansible任务

4.4.1. 在升级过程中使用 Ansible hook

4.4.2. 配置Ansible inventory文件以使用 hook

4.4.3. RHEL计算系统可用的 hook

4.5. 更新集群中的RHEL compute 系统

法律通告

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links

第 1 章在次版本间更新集群

第 2 章通过 web 控制台将集群更新为一个新的次版本

第 3 章使用 CLI 将集群更新为一个新的次版本

第 4 章更新包含使用 RHEL 的计算（compute）系统的集群