mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-06 15:46:57 +01:00
67 lines
3.8 KiB
Plaintext
67 lines
3.8 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * architecture/architecture-installation.adoc
|
|
// * architecture/control-plane.adoc
|
|
// * updating/updating-cluster-between-minor.adoc
|
|
// * updating/updating-cluster-cli.adoc
|
|
// * updating/updating-cluster-rhel-compute.adoc
|
|
// * updating/updating-cluster.adoc
|
|
// * updating/updating-disconnected-cluster.adoc
|
|
|
|
[id="update-service-overview_{context}"]
|
|
= About the {product-title} update service
|
|
|
|
The {product-title} update service is the hosted service that provides over-the-air
|
|
updates to both {product-title} and {op-system-first}. It provides a graph,
|
|
or diagram that contain _vertices_ and the _edges_ that connect them, of
|
|
component Operators. The edges in the graph show which versions you can safely
|
|
update to, and 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
|
|
{product-title} 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 {product-title} CVO uses the release image for that update to
|
|
upgrade 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 {product-title} update service to provide only compatible updates,
|
|
a release verification pipeline exists to drive 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 {product-title} update service notifies you
|
|
that it is available.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Because the update service displays all valid updates, you must not force an update to a version that the update service does not display.
|
|
====
|
|
|
|
////
|
|
The interaction between the registry and the {product-title} 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.
|
|
////
|
|
|
|
During continuous update mode, two controllers run. One continuously updates
|
|
the payload manifests, applies them to the cluster, and outputs the status of
|
|
the controlled rollout of the Operators, whether they are available, upgrading,
|
|
or failed. The second controller polls the {product-title} update service to
|
|
determine if updates are available.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Reverting your cluster to a previous version, or a rollback, is not supported.
|
|
Only upgrading to a newer version is supported.
|
|
====
|
|
|
|
During the upgrade process, the Machine Config Operator (MCO) applies the new configuration to your cluster machines. It cordons the number of nodes that is specified by the `maxUnavailable` field on the machine configuration pool and marks them as unavailable. By default, this value is set to `1`. It 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 on these machines because you must update the OpenShift API on them first. Because the specification for the new version is 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 nodes that are unavailable is set to ensure that normal cluster operations are likely to continue with that number of machines out of service.
|