Preparing to perform an EUS-to-EUS update
- EUS-to-EUS update

Preparing to perform an EUS-to-EUS update

Due to fundamental Kubernetes design, all OKD updates between minor versions must be serialized. You must update from OKD 4.8 to 4.9 and then to 4.10. You cannot update from OKD 4.8 to 4.10 directly. However, beginning with the update from OKD 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-master 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 stable channels.
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-master 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 OKD 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 OKD 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 OKD 4.9. Do not expect all features and bugs fixed in OKD 4.9 to be made available until you complete the update to OKD 4.10 and enable all MachineConfigPools to update.

EUS-to-EUS update

The following procedure pauses all non-master MachineConfigPools and performs updates from OKD 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 OKD 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 OKD 4.8 to 4.9.
Verify that your cluster is running OKD version 4.8.14 or later. If your cluster is running a version earlier than OKD 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.
Update OpenShift CLI oc to the target version before each update.

Procedure

Upgrade any OLM Operators to versions that are compatible with both versions you are updating to.

Verify that all machine config pools display a status of UPDATED and that no machine config pool displays a status of UPDATING. To view the status of all machine config pools, 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

Change to the eus-4.10 channel. Run the following command:

$ oc adm upgrade channel eus-4.10

The oc adm upgrade channel command is only present in 4.9 or later.

If you receive an error message indicating that eus-4.10 is not one of the available channels, this indicates that Red Hat is still rolling out 4.8 to 4.10 EUS upgrades. This rollout process generally takes 45-90 days starting at the GA date.

Pause the machine config pools that you want to skip reboots on. Run the following commands:

You cannot pause the master pool.
```
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'
```

Update to version 4.9. Run the following command:

$ oc adm upgrade --to-latest

Example output

Updating to latest version 4.9.18

Ensure that the 4.9 updates completed by reviewing 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 by using the Administrator perspective on the web console.
Update to version 4.10. Run the following command:
```
$ oc adm upgrade --to-latest
```

Ensure that the 4.10 update completed by retrieving 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 machine config pools. Run the following command:

$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'

If pools are not unpaused, the cluster is not permitted to update to any future minor versions, and maintenance tasks such as certificate rotation are inhibited. This puts the cluster at risk for future degradation.

Verify that your previously paused pools updated and that your cluster completed the update to version 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