Chapter 4. Preparing to perform an EUS-to-EUS update
Due to fundamental Kubernetes design, all OpenShift Container Platform updates between minor versions must be serialized. You must update from OpenShift Container Platform 4.8 to 4.9 and then to 4.10. You cannot update from OpenShift Container Platform 4.8 to 4.10 directly. However, beginning with the update from OpenShift Container Platform 4.8 to 4.9 to 4.10, administrators who wish to update between two Extended Update Support (EUS) versions can do so incurring only a single reboot of non-control plane hosts.
There are a number of caveats to consider when attempting an EUS-to-EUS update.
-
EUS-to-EUS updates are only offered after updates between all versions involved have been made available in
stablechannels. - If you encounter issues during or after upgrading to the odd-numbered minor version but before upgrading to the next even-numbered version, then remediation of those issues may require that non-control plane hosts complete the update to the odd-numbered version before moving forward.
- You can complete the update process during multiple maintenance windows by pausing at intermediate steps. However, plan to complete the entire update within 60 days. This is critical to ensure that normal cluster automation processes are completed including those associated with certificate rotation.
- You must be running at least OpenShift Container Platform 4.8.14 before starting the EUS-to-EUS update procedure. If you do not meet this minimum requirement, update to a later 4.8.z before attempting the EUS-to-EUS update.
- Support for RHEL7 workers was removed in OpenShift Container Platform 4.10 and replaced with RHEL8 workers, therefore EUS-to-EUS updates are not available for clusters with RHEL7 workers.
- Node components are not updated to OpenShift Container Platform 4.9. Do not expect all features and bugs fixed in OpenShift Container Platform 4.9 to be made available until you complete the update to OpenShift Container Platform 4.10 and enable all MachineConfigPools to update.
-
All the clusters might update using EUS channels for a conventional update without pools paused, but only clusters with non control-plane
MachineConfigPoolsobjects can do EUS-to-EUS update with pools paused.
4.1. EUS-to-EUS update
The following procedure pauses all non-master MachineConfigPools and performs updates from OpenShift Container Platform 4.8 to 4.9 to 4.10, then unpauses the previously paused MachineConfigPools. Following this procedure reduces the total update duration and the number of times worker nodes are restarted.
Prerequisites
- Review the release notes for OpenShift Container Platform 4.9 and 4.10
- Review the release notes and product lifecycles for any layered products and OLM Operators. Some may require updates either before or during an EUS-to-EUS update.
- Ensure that you are familiar with version-specific prerequisites, such as administrator acknowledgement that is required prior to updating from OpenShift Container Platform 4.8 to 4.9.
- Verify that your cluster is running OpenShift Container Platform version 4.8.14 or later. If your cluster is running a version earlier than OpenShift Container Platform 4.8.14, you must update to a later 4.8.z version before updating to 4.9. The update to 4.8.14 or later is necessary to fulfill the minimum version requirements that must be performed without pausing MachineConfigPools.
- Verify that MachineConfigPools is unpaused.
Procedure
- Upgrade any OLM Operators to versions that are compatible with both versions you are updating to.
Verify that all MachineConfigPools display a status of
UPDATEDand no MachineConfigPools display a status ofUPDATING. View the status of all MachineConfigPools, run the following command:$ oc get mcp
Example output
Output is trimmed for clarity:
NAME CONFIG UPDATED UPDATING master rendered-master-ecbb9582781c1091e1c9f19d50cf836c True False worker rendered-worker-00a3f0c68ae94e747193156b491553d5 True False
Pause the MachineConfigPools you wish to skip reboots on, run the following commands:
NoteYou cannot pause the master pool.
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'Change to the
eus-4.10channel, run the following command:$ oc adm upgrade channel eus-4.10
Update to 4.9, run the following command:
$ oc adm upgrade --to-latest
Example output
Updating to latest version 4.9.18
Ensure the 4.9 updates are completed successfully retrieve the cluster version, run the following command:
$ oc get clusterversion
Example output
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.9.18 True False 6m29s Cluster version is 4.9.18
- If necessary, upgrade OLM Operators using the Administrator perspective on the web console.
Update to 4.10, run the following command:
$ oc adm upgrade --to-latest
Ensure the 4.10 update is completed successfully retrieve the cluster version, run the following command:
$ oc get clusterversion
Example output
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.10.1 True False 6m29s Cluster version is 4.10.1
Unpause all previously paused MachineConfigPools, run the following command:
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'NoteIf pools are not unpaused, the cluster is not permitted to update to any future minors and maintenance tasks such as certificate rotation are inhibited. This puts the cluster at risk for future degradation.
Verify that your previously paused pools have updated and your cluster completed the update to 4.10, run the following command:
$ oc get mcp
Example output
Output is trimmed for clarity:
NAME CONFIG UPDATED UPDATING master rendered-master-52da4d2760807cb2b96a3402179a9a4c True False worker rendered-worker-4756f60eccae96fb9dcb4c392c69d497 True False
