mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
52 lines
4.9 KiB
Plaintext
52 lines
4.9 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * architecture/architecture-installation.adoc
|
|
// * updating/understanding_updates/intro-to-updates.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="update-service-about_{context}"]
|
|
= About the OpenShift Update Service
|
|
|
|
The OpenShift Update Service (OSUS) provides update recommendations to {product-title}, including {op-system-first}. 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 corresponding release image to update your cluster. The release artifacts are hosted in Quay as container images.
|
|
////
|
|
By accepting automatic updates, you can automatically
|
|
keep your cluster up to date with the most recent compatible components.
|
|
////
|
|
|
|
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 (OSUS) supports a single-stream release model, where only one release version is active and supported at any given time. When a new release is deployed, it fully replaces the previous release.
|
|
|
|
The updated release provides support for upgrades from all {product-title} versions starting after 4.8 up to the new release version.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
The OpenShift Update Service displays all recommended updates for your current cluster. If an update path is not recommended by the OpenShift Update Service, it might be because of a known issue related to the update path, such as incompatibility or availability.
|
|
====
|
|
|
|
////
|
|
The interaction between the registry and the OpenShift Update Service is different during bootstrap and continuous update modes. When you bootstrap the initial infrastructure, the Cluster Version Operator finds the fully qualified image name for the shortname of the images that it needs to apply to the server during installation. It looks at the imagestream that it needs to apply and renders it to disk. It calls bootkube and waits for a temporary minimal control plane to come up and load the Cluster Version Operator.
|
|
////
|
|
|
|
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.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Only updating 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 specified by the `maxUnavailable` field on the machine configuration pool and marks them unavailable. By default, this value is set to `1`. The MCO updates the affected nodes alphabetically by zone, based on the `topology.kubernetes.io/zone` label. If a zone has more than one node, the oldest nodes are updated first. For nodes that do not use zones, such as in bare metal deployments, the nodes are updated by age, with the oldest nodes updated first. The MCO updates the number of nodes as specified by the `maxUnavailable` field on the machine configuration pool at a time. The MCO then applies the new configuration and reboots the machine.
|
|
|
|
[WARNING]
|
|
====
|
|
The default setting for `maxUnavailable` is `1` for all the machine config pools in {product-title}. It is recommended to not change this value and update one control plane node at a time. Do not change this value to `3` for the control plane pool.
|
|
====
|
|
|
|
If you use {op-system-base-full} 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 {op-system-base} 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.
|