1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-07 00:48:01 +01:00
Files
openshift-docs/modules/update-upgrading-cli.adoc
2023-02-07 22:41:16 +00:00

143 lines
4.7 KiB
Plaintext

// Module included in the following assemblies:
//
// * updating/updating-cluster-cli.adoc
// * updating/updating-cluster-rhel-compute.adoc
:_content-type: PROCEDURE
[id="update-upgrading-cli_{context}"]
= Updating a cluster by using the CLI
If updates are available, you can update your cluster by using the
OpenShift CLI (`oc`).
You can find information about available {product-title} advisories and updates
link:https://access.redhat.com/downloads/content/290[in the errata section]
of the Customer Portal.
.Prerequisites
* Install the OpenShift CLI (`oc`) that matches the version for your updated version.
* Log in to the cluster as user with `cluster-admin` privileges.
* Pause all `MachineHealthCheck` resources.
.Procedure
. View the available updates and note the version number of the update that
you want to apply:
+
[source,terminal]
----
$ oc adm upgrade
----
+
.Example output
[source,terminal]
----
Cluster version is 4.9.23
Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-4.9 (available channels: candidate-4.10, candidate-4.9, fast-4.10, fast-4.9, stable-4.10, stable-4.9, eus-4.10)
Recommended updates:
VERSION IMAGE
4.9.24 quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
4.9.25 quay.io/openshift-release-dev/ocp-release@sha256:2eafde815e543b92f70839972f585cc52aa7c37aa72d5f3c8bc886b0fd45707a
4.9.26 quay.io/openshift-release-dev/ocp-release@sha256:3ccd09dd08c303f27a543351f787d09b83979cd31cf0b4c6ff56cd68814ef6c8
4.9.27 quay.io/openshift-release-dev/ocp-release@sha256:1c7db78eec0cf05df2cead44f69c0e4b2c3234d5635c88a41e1b922c3bedae16
4.9.28 quay.io/openshift-release-dev/ocp-release@sha256:4084d94969b186e20189649b5affba7da59f7d1943e4e5bc7ef78b981eafb7a8
4.9.29 quay.io/openshift-release-dev/ocp-release@sha256:b04ca01d116f0134a102a57f86c67e5b1a3b5da1c4a580af91d521b8fa0aa6ec
4.9.31 quay.io/openshift-release-dev/ocp-release@sha256:2a28b8ebb53d67dd80594421c39e36d9896b1e65cb54af81fbb86ea9ac3bf2d7
4.9.32 quay.io/openshift-release-dev/ocp-release@sha256:ecdb6d0df547b857eaf0edb5574ddd64ca6d9aff1fa61fd1ac6fb641203bedfa
----
+
[NOTE]
====
For details and information on how to perform an `EUS-to-EUS` channel upgrade, please refer to the
_Preparing to perform an EUS-to-EUS upgrade_ page, listed in the Additional resources section.
====
. Based on your organization requirements, set the appropriate upgrade channel. For example, you can set your channel to `stable-4.12`, `fast-4.12`, or `eus-4.12`. For more information about channels, refer to _Understanding update channels and releases_ listed in the Additional resources section.
+
[source,terminal]
----
$ oc adm upgrade channel <channel>
----
+
For example, to set the channel to `stable-{product-version}`:
+
[source,terminal,subs="attributes+"]
----
$ oc adm upgrade channel stable-{product-version}
----
+
[IMPORTANT]
====
For production clusters, you must subscribe to a `stable-\*`, `eus-*`, or `fast-*` channel.
====
. Apply an update:
** To update to the latest version:
+
[source,terminal]
----
$ oc adm upgrade --to-latest=true <1>
----
** To update to a specific version:
+
[source,terminal]
----
$ oc adm upgrade --to=<version> <1>
----
<1> `<version>` is the update version that you obtained from the output of the
`oc adm upgrade` command.
. Review the status of the Cluster Version Operator:
+
[source,terminal]
----
$ oc adm upgrade
----
. After the update completes, you can confirm that the cluster version has
updated to the new version:
+
[source,terminal]
----
$ oc adm upgrade
----
+
.Example output
[source,terminal]
----
Cluster version is <version>
Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-4.10 (available channels: candidate-4.10, candidate-4.11, eus-4.10, fast-4.10, fast-4.11, stable-4.10)
No updates available. You may force an upgrade to a specific release image, but doing so might not be supported and might result in downtime or data loss.
----
+
. If you are upgrading your cluster to the next minor version, such as version X.y to X.(y+1), it is recommended to confirm that your nodes are upgraded before deploying workloads that rely on a new feature:
+
[source,terminal]
----
$ oc get nodes
----
+
.Example output
[source,terminal]
----
NAME STATUS ROLES AGE VERSION
ip-10-0-168-251.ec2.internal Ready master 82m v1.25.0
ip-10-0-170-223.ec2.internal Ready master 82m v1.25.0
ip-10-0-179-95.ec2.internal Ready worker 70m v1.25.0
ip-10-0-182-134.ec2.internal Ready worker 70m v1.25.0
ip-10-0-211-16.ec2.internal Ready master 82m v1.25.0
ip-10-0-250-100.ec2.internal Ready worker 69m v1.25.0
----