mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
48 lines
3.2 KiB
Plaintext
48 lines
3.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * updating/understanding_updates/how-updates-work.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="update-process-workflow_{context}"]
|
|
= Update process workflow
|
|
|
|
The following steps represent a detailed workflow of the {product-title} (OCP) update process:
|
|
|
|
. The target version is stored in the `spec.desiredUpdate.version` field of the `ClusterVersion` resource, which may be managed through the web console or the CLI.
|
|
|
|
. The Cluster Version Operator (CVO) detects that the `desiredUpdate` in the `ClusterVersion` resource differs from the current cluster version.
|
|
Using graph data from the OpenShift Update Service, the CVO resolves the desired cluster version to a pull spec for the release image.
|
|
|
|
. The CVO validates the integrity and authenticity of the release image.
|
|
Red Hat publishes cryptographically-signed statements about published release images at predefined locations by using image SHA digests as unique and immutable release image identifiers.
|
|
The CVO utilizes a list of built-in public keys to validate the presence and signatures of the statement matching the checked release image.
|
|
|
|
. The CVO creates a job named `version-$version-$hash` in the `openshift-cluster-version` namespace.
|
|
This job uses containers that are executing the release image, so the cluster downloads the image through the container runtime.
|
|
The job then extracts the manifests and metadata from the release image to a shared volume that is accessible to the CVO.
|
|
|
|
. The CVO validates the extracted manifests and metadata.
|
|
|
|
. The CVO checks some preconditions to ensure that no problematic condition is detected in the cluster.
|
|
Certain conditions can prevent updates from proceeding.
|
|
These conditions are either determined by the CVO itself, or reported by individual cluster Operators that detect some details about the cluster that the Operator considers problematic for the update.
|
|
|
|
. The CVO records the accepted release in `status.desired` and creates a `status.history` entry about the new update.
|
|
|
|
. The CVO begins reconciling the manifests from the release image.
|
|
Cluster Operators are updated in separate stages called Runlevels, and the CVO ensures that all Operators in a Runlevel finish updating before it proceeds to the next level.
|
|
|
|
. Manifests for the CVO itself are applied early in the process.
|
|
When the CVO deployment is applied, the current CVO pod stops, and a CVO pod that uses the new version starts.
|
|
The new CVO proceeds to reconcile the remaining manifests.
|
|
|
|
. The update proceeds until the entire control plane is updated to the new version.
|
|
Individual cluster Operators might perform update tasks on their domain of the cluster, and while they do so, they report their state through the `Progressing=True` condition.
|
|
|
|
. The Machine Config Operator (MCO) manifests are applied towards the end of the process.
|
|
The updated MCO then begins updating the system configuration and operating system of every node.
|
|
Each node might be drained, updated, and rebooted before it starts to accept workloads again.
|
|
|
|
The cluster reports as updated after the control plane update is finished, usually before all nodes are updated.
|
|
After the update, the CVO maintains all cluster resources to match the state delivered in the release image.
|