Chapter 2. Understanding cluster version condition types The Cluster Version Operator (CVO) monitors cluster Operators and other components, and is responsible for collecting the status of both the cluster version and its Operators. This status includes the condition type, which informs you of the health and current state of the OpenShift Container Platform cluster. In addition to Available , Progressing , and Upgradeable , there are condition types that affect cluster versions and Operators. Failing: The cluster version condition type Failing indicates that a cluster cannot reach its desired state, is unhealthy, and requires an administrator to intervene. Invalid: The cluster version condition type Invalid indicates that the cluster version has an error that prevents the server from taking action. The CVO only reconciles the current state as long as this condition is set. RetrievedUpdates: The cluster version condition type RetrievedUpdates indicates whether or not available updates have been retrieved from the upstream update server. The condition is Unknown before retrieval, False if the updates either recently failed or could not be retrieved, or True if the availableUpdates field is both recent and accurate. ReleaseAccepted: The cluster version condition type ReleaseAccepted with a True status indicates that the requested release payload was successfully loaded without failure during image verification and precondition checking. 2.1. Preparing to perform an EUS-to-EUS update 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, if you want to update between two Extended Update Support (EUS) versions, you can do so by incurring only a single reboot of non-control plane hosts. For more information, see the following: Updating EUS-to-EUS 2.2. Updating a cluster using the web console Updating a cluster within a minor version using the web console : You can update an OpenShift Container Platform cluster by using the web console. The following steps update a cluster within a minor version. You can use the same instructions for updating a cluster between minor versions. Performing a canary rollout update Pausing a MachineHealthCheck resource About updating OpenShift Container Platform on a single-node cluster Updating a cluster by using the web console Changing the update server by using the web console 2.3. Updating a cluster within a minor version using the command-line interface (CLI) Updating a cluster within a minor version using the CLI : You can update an OpenShift Container Platform cluster within a minor version by using the OpenShift CLI ( oc ). The following steps update a cluster within a minor version. You can use the same instructions for updating a cluster between minor versions. Pausing a MachineHealthCheck resource About updating OpenShift Container Platform on a single-node cluster Updating a cluster by using the CLI Changing the update server by using the CLI 2.4. Performing a canary rollout update Performing a canary rollout update : By controlling the rollout of an update to the worker nodes, you can ensure that mission-critical applications stay available during the whole update, even if the update process causes your applications to fail. Depending on your organizational needs, you might want to update a small subset of worker nodes, evaluate cluster and workload health over a period of time, and then update the remaining nodes. This is referred to as a canary update. Alternatively, you might also want to fit worker node updates, which often requires a host reboot, into smaller defined maintenance windows when it is not possible to take a large maintenance window to update the entire cluster at one time. You can perform the following procedures: Creating machine configuration pools to perform a canary rollout update Pausing the machine configuration pools Performing the cluster update Unpausing the machine configuration pools Moving a node to the original machine configuration pool 2.5. Updating a cluster that includes RHEL compute machines Updating a cluster that includes RHEL compute machines : You can update an OpenShift Container Platform cluster. If your cluster contains Red Hat Enterprise Linux (RHEL) machines, you must perform additional steps to update those machines. You can perform the following procedures: Updating a cluster by using the web console Optional: Adding hooks to perform Ansible tasks on RHEL machines Updating RHEL compute machines in your cluster 2.6. Updating a cluster in a disconnected environment About cluster updates in a disconnected environment : If your mirror host cannot access both the internet and the cluster, you can mirror the images to a file system that is disconnected from that environment. You can then bring that host or removable media across that gap. If the local container registry and the cluster are connected to the mirror host of a registry, you can directly push the release images to the local registry. Preparing your mirror host Configuring credentials that allow images to be mirrored Mirroring the OpenShift Container Platform image repository Updating the disconnected cluster Configuring image registry repository mirroring Widening the scope of the mirror image catalog to reduce the frequency of cluster node reboots Installing the OpenShift Update Service Operator Creating an OpenShift Update Service application Deleting an OpenShift Update Service application Uninstalling the OpenShift Update Service Operator 2.7. Updating hardware on nodes running in vSphere Updating hardware on vSphere : You must ensure that your nodes running in vSphere are running on the hardware version supported by OpenShift Container Platform. Currently, hardware version 13 or later is supported for vSphere virtual machines in a cluster. For more information, see the following: Updating virtual hardware on vSphere Scheduling an update for virtual hardware on vSphere Important Using hardware version 13 for your cluster nodes running on vSphere is now deprecated. This version is still fully supported, but support will be removed in a future version of OpenShift Container Platform. Hardware version 15 is now the default for vSphere virtual machines in OpenShift Container Platform.

Commands: