The OpenShift Update Service (OSUS) provides updates to OpenShift Container Platform, including Red Hat Enterprise Linux CoreOS (RHCOS). It provides a graph, or diagram, that contains the vertices of component Operators and the edges that connect them. The edges in the graph show which versions you can safely update to. The vertices are update payloads that specify the intended state of the managed cluster components.
The Cluster Version Operator (CVO) in your cluster checks with the OpenShift Update Service to see the valid updates and update paths based on current component versions and information in the graph. When you request an update, the CVO uses the release image for that update to update your cluster. The release artifacts are hosted in Quay as container images.
To allow the OpenShift Update Service to provide only compatible updates, a release verification pipeline drives automation. Each release artifact is verified for compatibility with supported cloud platforms and system architectures, as well as other component packages. After the pipeline confirms the suitability of a release, the OpenShift Update Service notifies you that it is available.
The OpenShift Update Service displays all recommended updates for your current cluster. If an upgrade path is not recommended by the OpenShift Update Service, it might be because of a known issue with the update or the target release.
Two controllers run during continuous update mode. The first controller continuously updates the payload manifests, applies the manifests to the cluster, and outputs the controlled rollout status of the Operators to indicate whether they are available, upgrading, or failed. The second controller polls the OpenShift Update Service to determine if updates are available.
Only upgrading to a newer version is supported. Reverting or rolling back your cluster to a previous version is not supported. If your update fails, contact Red Hat support.
During the update process, the Machine Config Operator (MCO) applies the new configuration to your cluster machines. The MCO cordons the number of nodes as specified by the
maxUnavailable field on the machine configuration pool and marks them as unavailable. By default, this value is set to
1. The MCO then applies the new configuration and reboots the machine.
If you use Red Hat Enterprise Linux (RHEL) machines as workers, the MCO does not update the kubelet because you must update the OpenShift API on the machines first.
With the specification for the new version applied to the old kubelet, the RHEL machine cannot return to the
Ready state. You cannot complete the update until the machines are available. However, the maximum number of unavailable nodes is set to ensure that normal cluster operations can continue with that number of machines out of service.
The OpenShift Update Service is composed of an Operator and one or more application instances.
During the update process, nodes in the cluster might become temporarily unavailable. The
MachineHealthCheck might identify such nodes as unhealthy and reboot them. To avoid rebooting such nodes, remove any
MachineHealthCheck resource that you have deployed before updating the cluster.
However, a MachineHealthCheck resource that is deployed by default (such as
machine-api-termination-handler) cannot be removed and will be recreated.
For clusters with internet accessibility, Red Hat provides update recommendations through an OpenShift Container Platform update service as a hosted service located behind public APIs. However, clusters in a disconnected environment have no way to access public APIs for update information.
To provide a similar update experience in a disconnected environment, you can install and configure the OpenShift Update Service locally so that it is available within a disconnected environment.
The following sections describe how to provide updates for your disconnected cluster and its underlying operating system.