In OKD 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster updates. By controlling the pace of updates, these upgrade channels allow you to choose an update strategy. Upgrade channels are tied to a minor version of OKD. For instance, OKD 4.10 upgrade channels recommend updates to 4.10 and updates within 4.10. They also recommend updates within 4.9 and from 4.9 to 4.10, to allow clusters on 4.9 to eventually update to 4.10. They do not recommend updates to 4.11 or later releases. This strategy ensures that administrators explicitly decide to update to the next minor version of OKD.
Upgrade channels control only release selection and do not impact the version of the cluster that you install; the
openshift-install binary file for a specific version of OKD always installs that version.
OKD 4 offers the following upgrade channel:
Cluster administrators can configure the upgrade channel from the web console.
candidate-4 channel contains candidate builds for a z-stream (4.z) and previous minor version releases. Release candidates contain all the features of the product but are not supported. Use release candidate versions to test feature acceptance and assist in qualifying the next version of OKD. A release candidate is any build that is available in the candidate channel, including ones that do not contain a pre-release version such as
-rc in their names. After a version is available in the candidate channel, it goes through more quality checks. If it meets the quality standard, it is promoted to the
stable-4 channels. Because of this strategy, if a specific release is available in both the
candidate-4 channel and in the
stable-4 channels, it is a Red Hat-supported version. The
candidate-4 channel can include release versions from which there are no recommended updates in any channel.
You can use the
candidate-4 channel to update from a previous minor version of OKD.
fast-4 channel is updated with new and previous minor versions of 4 as soon as Red Hat declares the given version as a general availability release. As such, these releases are fully supported, are production quality, and have performed well while available as a release candidate in the
candidate-4 channel from where they were promoted. Some time after a release appears in the
fast-4 channel, it is added to the
stable-4 channel. Releases never appear in the
stable-4 channel before they appear in the
You can use the
fast-4 channel to upgrade from a previous minor version of OKD.
Releases are added to the
stable-4 channel after passing all tests.
You can use the
stable-4 channel to upgrade from a previous minor version of OKD.
OKD maintains an upgrade recommendation service that understands the version of OKD you have installed as well as the path to take within the channel you choose to get you to the next release.
You can imagine seeing the following in the
The service recommends only upgrades that have been tested and have no serious issues. It will not suggest updating to a version of OKD that contains known vulnerabilities. For example, if your cluster is on 4.1 and OKD suggests 4.4, then it is safe for you to update from 4.1 to 4.4. Do not rely on consecutive patch numbers. In this example, 4.2 is not and never was available in the channel.
The presence of an update recommendation in the
stable-4 channel at any point is a declaration that the update is supported. While releases will never be removed from the channel, update recommendations that exhibit serious issues will be removed or made conditional from all channels. When an update recommendation is supported, it remains supported for the life of 4, even if the update recommendation is later dropped or made conditional.
If you manage the container images for your OKD clusters yourself, you must consult the Red Hat errata that is associated with product releases and note any comments that impact upgrades. During upgrade, the user interface might warn you about switching between these versions, so you must ensure that you selected an appropriate version before you bypass those warnings.
The OpenShift Update Service might declare conditionally recommended updates associated with known risks.
The Cluster Version Operator (CVO) continually evaluates known risks associated with updates from the current OKD release to later releases.
When no risks apply, the update is recommended. You can update from the Administrator perspective on the web console, as well as the OpenShift CLI (
When an update is not recommended because a risk might apply, you can view the update from the OpenShift CLI (
oc). If the cluster administrator evaluates the potential known risks and decides it is acceptable for the current cluster, the administrator can waive the safety guards and proceed to an update.
For more information, see Updating along a conditional upgrade path