$ oc get machinehealthcheck -n openshift-machine-api
您可以使用 OpenShift CLI (oc
) 对 OpenShift Container Platform 集群执行次要版本和补丁更新。
以具有 admin
权限的用户身份访问集群。请参阅 使用 RBAC 定义和应用权限。
如果更新失败并且必须将集群恢复到以前的状态,则需要最近的 etcd 备份。
如果需要由于 Pod 故障而恢复持久卷,则需要最近的 容器存储接口 (CSI) 卷快照。
您的 RHEL7 工作节点已替换为 RHEL8 或 RHCOS 工作节点。Red Hat 不支持对 RHEL 工作节点进行 RHEL7 到 RHEL8 的就地更新;必须使用干净的操作系统安装替换这些主机。
您已将之前通过 Operator Lifecycle Manager (OLM) 安装的所有 Operator 更新到与目标版本兼容的版本。更新 Operator 可确保在集群更新期间默认 OperatorHub 目录从当前次要版本切换到下一个次要版本时,它们具有有效的更新路径。有关如何检查兼容性以及如何在必要时更新已安装的 Operator 的更多信息,请参阅更新已安装的 Operator。
确保所有机器配置池 (MCP) 都正在运行且未暂停。更新过程中会跳过与已暂停 MCP 关联的节点。如果您正在执行金丝雀发布更新策略,则可以暂停 MCP。
如果您的集群使用手动维护的凭据,请更新新版本的云提供商资源。有关更多信息(包括如何确定这是否是集群的要求),请参阅准备更新使用手动维护凭据的集群。
确保解决所有Upgradeable=False
条件,以便集群允许更新到下一个次要版本。当您有一个或多个无法更新的集群 Operator 时,会在**集群设置**页面顶部显示警报。您仍然可以更新到当前使用的次要版本的下一个可用补丁更新。
如果您运行 Operator 或使用 Pod disruption budget 配置任何应用程序,则在更新过程中可能会遇到中断。如果在PodDisruptionBudget
中将minAvailable
设置为 1,则会排空节点以应用挂起的机器配置,这可能会阻止驱逐进程。如果重新引导多个节点,所有 Pod 都可能只在一个节点上运行,并且PodDisruptionBudget
字段可以阻止节点排空。
|
在更新过程中,集群中的节点可能会暂时不可用。对于工作节点,机器运行状况检查可能会将此类节点识别为不健康并重新引导它们。为了避免重新引导这些节点,请在更新集群之前暂停所有MachineHealthCheck
资源。
安装 OpenShift CLI (oc
)。
要列出要暂停的所有可用MachineHealthCheck
资源,请运行以下命令:
$ oc get machinehealthcheck -n openshift-machine-api
要暂停机器运行状况检查,请将cluster.x-k8s.io/paused=""
注释添加到MachineHealthCheck
资源。运行以下命令:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
带注释的MachineHealthCheck
资源类似于以下 YAML 文件:
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
name: example
namespace: openshift-machine-api
annotations:
cluster.x-k8s.io/paused: ""
spec:
selector:
matchLabels:
role: worker
unhealthyConditions:
- type: "Ready"
status: "Unknown"
timeout: "300s"
- type: "Ready"
status: "False"
timeout: "300s"
maxUnhealthy: "40%"
status:
currentHealthy: 5
expectedMachines: 5
更新集群后恢复机器运行状况检查。要恢复检查,请通过运行以下命令从
|
您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。
但是,请注意以下限制:
暂停MachineHealthCheck
资源的先决条件不需要,因为没有其他节点可以执行运行状况检查。
使用 etcd 备份恢复单节点 OpenShift Container Platform 集群不受官方支持。但是,最好执行 etcd 备份,以防更新失败。如果您的控制平面运行状况良好,则可以使用备份将集群恢复到以前的状态。
更新单节点 OpenShift Container Platform 集群需要停机时间,并且可能包括自动重启。停机时间取决于更新负载,如下面的场景所述:
如果更新负载包含需要重新引导的操作系统更新,则停机时间很长,会影响集群管理和用户工作负载。
如果更新包含不需要重新引导的机器配置更改,则停机时间较短,对集群管理和用户工作负载的影响减轻。在这种情况下,由于集群中没有其他节点可以将工作负载重新调度到,因此单节点 OpenShift Container Platform 会跳过节点排空步骤。
如果更新负载不包含操作系统更新或机器配置更改,则会发生短暂的 API 中断,并很快解决。
某些情况(例如更新的软件包中的错误)会导致单节点在重新引导后无法重新启动。在这种情况下,更新不会自动回滚。 |
有关哪些机器配置更改需要重新引导的信息,请参阅关于机器配置 Operator中的注释。
您可以使用 OpenShift CLI (oc
) 来查看和请求集群更新。
您可以在客户门户的勘误部分中找到有关可用的 OpenShift Container Platform 安全公告和更新的信息。
安装与更新版本匹配的 OpenShift CLI (oc
)。
以具有cluster-admin
权限的用户身份登录到集群。
暂停所有MachineHealthCheck
资源。
查看可用的更新并记下要应用的更新的版本号:
$ oc adm upgrade
Cluster version is 4.13.10
Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-4.13 (available channels: candidate-4.13, candidate-4.14, fast-4.13, stable-4.13)
Recommended updates:
VERSION IMAGE
4.13.14 quay.io/openshift-release-dev/ocp-release@sha256:406fcc160c097f61080412afcfa7fd65284ac8741ac7ad5b480e304aba73674b
4.13.13 quay.io/openshift-release-dev/ocp-release@sha256:d62495768e335c79a215ba56771ff5ae97e3cbb2bf49ed8fb3f6cefabcdc0f17
4.13.12 quay.io/openshift-release-dev/ocp-release@sha256:73946971c03b43a0dc6f7b0946b26a177c2f3c9d37105441315b4e3359373a55
4.13.11 quay.io/openshift-release-dev/ocp-release@sha256:e1c2377fdae1d063aaddc753b99acf25972b6997ab9a0b7e80cfef627b9ef3dd
|
根据您的组织要求,设置合适的更新渠道。例如,您可以将渠道设置为stable-4.13
或fast-4.13
。有关渠道的更多信息,请参阅“其他资源”部分中列出的了解更新渠道和版本。
$ oc adm upgrade channel <channel>
例如,要将渠道设置为stable-4.17
:
$ oc adm upgrade channel stable-4.17
对于生产集群,您必须订阅 |
当您准备好转到下一个次要版本时,请选择与该次要版本相对应的渠道。更新渠道声明得越早,集群就能越有效地向您的目标版本推荐更新路径。集群可能需要一些时间来评估所有可用的更新选项,并提供最佳的更新建议供您选择。更新建议会随着时间的推移而改变,因为它们基于当时可用的更新选项。 如果您看不到到目标次要版本的更新路径,请继续将集群更新到当前版本的最新补丁版本,直到下一个次要版本在路径中可用。 |
应用更新
要更新到最新版本:
$ oc adm upgrade --to-latest=true (1)
要更新到特定版本:
$ oc adm upgrade --to=<version> (1)
1 | <version> 是您从oc adm upgrade 命令的输出中获得的更新版本。 |
使用 |
查看集群版本 Operator 的状态
$ oc adm upgrade
更新完成后,您可以确认集群版本已更新到新版本。
$ oc adm upgrade
Cluster version is <version>
Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-<version> (available channels: candidate-<version>, eus-<version>, fast-<version>, stable-<version>)
No updates available. You may force an update to a specific release image, but doing so might not be supported and might result in downtime or data loss.
如果您正在将集群更新到下一个次要版本(例如,从 X.y 版本更新到 X.(y+1) 版本),建议您在部署依赖于新功能的工作负载之前,确认节点已更新。
$ oc get nodes
NAME STATUS ROLES AGE VERSION
ip-10-0-168-251.ec2.internal Ready master 82m v1.30.3
ip-10-0-170-223.ec2.internal Ready master 82m v1.30.3
ip-10-0-179-95.ec2.internal Ready worker 70m v1.30.3
ip-10-0-182-134.ec2.internal Ready worker 70m v1.30.3
ip-10-0-211-16.ec2.internal Ready master 82m v1.30.3
ip-10-0-250-100.ec2.internal Ready worker 69m v1.30.3
更新集群时,了解更新进度非常有用。虽然 oc adm upgrade
命令仅返回有关更新状态的有限信息,但此版本引入了 oc adm upgrade status
命令作为技术预览版功能。此命令将状态信息与 oc adm upgrade
命令解耦,并提供有关集群更新的具体信息,包括控制平面和工作节点更新的状态。
oc adm upgrade status
命令是只读命令,不会更改集群中的任何状态。
有关 Red Hat 技术预览版功能的支持范围的更多信息,请参阅 技术预览版功能支持范围。 |
oc adm upgrade status
命令可用于从 4.12 版本到最新支持版本的集群。
虽然您的集群不需要是启用技术预览版的集群,但您必须启用 |
通过运行以下命令将 OC_ENABLE_CMD_UPGRADE_STATUS
环境变量设置为 true
$ export OC_ENABLE_CMD_UPGRADE_STATUS=true
运行 oc adm upgrade status
命令
$ oc adm upgrade status
= Control Plane =
Assessment: Progressing
Target Version: 4.14.1 (from 4.14.0)
Completion: 97%
Duration: 54m
Operator Status: 32 Healthy, 1 Unavailable
Control Plane Nodes
NAME ASSESSMENT PHASE VERSION EST MESSAGE
ip-10-0-53-40.us-east-2.compute.internal Progressing Draining 4.14.0 +10m
ip-10-0-30-217.us-east-2.compute.internal Outdated Pending 4.14.0 ?
ip-10-0-92-180.us-east-2.compute.internal Outdated Pending 4.14.0 ?
= Worker Upgrade =
= Worker Pool =
Worker Pool: worker
Assessment: Progressing
Completion: 0%
Worker Status: 3 Total, 2 Available, 1 Progressing, 3 Outdated, 1 Draining, 0 Excluded, 0 Degraded
Worker Pool Nodes
NAME ASSESSMENT PHASE VERSION EST MESSAGE
ip-10-0-4-159.us-east-2.compute.internal Progressing Draining 4.14.0 +10m
ip-10-0-20-162.us-east-2.compute.internal Outdated Pending 4.14.0 ?
ip-10-0-99-40.us-east-2.compute.internal Outdated Pending 4.14.0 ?
= Worker Pool =
Worker Pool: infra
Assessment: Progressing
Completion: 0%
Worker Status: 1 Total, 0 Available, 1 Progressing, 1 Outdated, 1 Draining, 0 Excluded, 0 Degraded
Worker Pool Node
NAME ASSESSMENT PHASE VERSION EST MESSAGE
ip-10-0-4-159-infra.us-east-2.compute.internal Progressing Draining 4.14.0 +10m
= Update Health =
SINCE LEVEL IMPACT MESSAGE
14m4s Info None Update is proceeding well
有了这些信息,您可以根据情况做出如何继续更新的明智决定。
您可以使用 Web 控制台或 OpenShift CLI (oc
) 沿着推荐的条件更新路径进行更新。当不建议对您的集群进行条件更新时,您可以使用 OpenShift CLI (oc
) 4.10 或更高版本沿着条件更新路径进行更新。
要查看由于可能存在风险而不建议进行更新时的说明,请运行以下命令
$ oc adm upgrade --include-not-recommended
如果集群管理员评估了潜在的已知风险,并决定该风险对于当前集群是可以接受的,则管理员可以放弃安全防护,并通过运行以下命令继续更新
$ oc adm upgrade --allow-not-recommended --to <version> (1)
1 | <version> 是您从先前命令的输出中获得的更新版本,该版本受支持,但也存在已知问题或风险。 |
更改更新服务器是可选的。如果您已安装并配置了本地 OpenShift 更新服务 (OSUS),则必须将服务器的 URL 设置为 upstream
,以便在更新期间使用本地服务器。upstream
的默认值为 https://api.openshift.com/api/upgrades_info/v1/graph
。
更改集群版本中的 upstream
参数值
$ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --type=merge
<update-server-url>
变量指定更新服务器的 URL。
clusterversion.config.openshift.io/version patched