mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
159 lines
5.3 KiB
Plaintext
159 lines
5.3 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * updating/updating_a_cluster/updating-cluster-cli.adoc
|
|
// * updating/updating_a_cluster/updating-cluster-rhel-compute.adoc
|
|
|
|
:_mod-docs-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]
|
|
----
|
|
$ oc adm upgrade
|
|
Cluster version is 4.13.10
|
|
|
|
Upstream is unset, so the cluster will use an appropriate default.
|
|
Channel: stable-4.13 (available channels: candidate-4.13, candidate-4.14, fast-4.13, stable-4.13)
|
|
|
|
Recommended updates:
|
|
|
|
VERSION IMAGE
|
|
4.13.14 quay.io/openshift-release-dev/ocp-release@sha256:406fcc160c097f61080412afcfa7fd65284ac8741ac7ad5b480e304aba73674b
|
|
4.13.13 quay.io/openshift-release-dev/ocp-release@sha256:d62495768e335c79a215ba56771ff5ae97e3cbb2bf49ed8fb3f6cefabcdc0f17
|
|
4.13.12 quay.io/openshift-release-dev/ocp-release@sha256:73946971c03b43a0dc6f7b0946b26a177c2f3c9d37105441315b4e3359373a55
|
|
4.13.11 quay.io/openshift-release-dev/ocp-release@sha256:e1c2377fdae1d063aaddc753b99acf25972b6997ab9a0b7e80cfef627b9ef3dd
|
|
----
|
|
+
|
|
[NOTE]
|
|
====
|
|
For details and information on how to perform an `EUS-to-EUS` channel update, 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 update channel. For example, you can set your channel to `stable-4.13` or `fast-4.13`. For more information about channels, refer to _Understanding update channels and releases_ listed in the Additional resources section.
|
|
//this example will need to be updated per eus release to reflect options available
|
|
|
|
+
|
|
[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.
|
|
====
|
|
+
|
|
[NOTE]
|
|
====
|
|
When you are ready to move to the next minor version, choose the channel that corresponds to that minor version.
|
|
The sooner the update channel is declared, the more effectively the cluster can recommend update paths to your target version.
|
|
The cluster might take some time to evaluate all the possible updates that are available and offer the best update recommendations to choose from.
|
|
Update recommendations can change over time, as they are based on what update options are available at the time.
|
|
|
|
If you cannot see an update path to your target minor version, keep updating your cluster to the latest patch release for your current version until the next minor version is available in the path.
|
|
====
|
|
|
|
. 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-<version> (available channels: candidate-<version>, eus-<version>, fast-<version>, stable-<version>)
|
|
|
|
No updates available. You may force an update to a specific release image, but doing so might not be supported and might result in downtime or data loss.
|
|
----
|
|
+
|
|
[NOTE]
|
|
====
|
|
If the `oc get clusterversion` command displays the following error while the `PROGRESSING` status is `True`, you can ignore the error.
|
|
[source,terminal]
|
|
----
|
|
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
|
|
version <version> True True 24m Unable to apply <version>: an unknown error has occurred: MultipleErrors
|
|
----
|
|
====
|
|
. If you are updating 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 updated 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.27.3
|
|
ip-10-0-170-223.ec2.internal Ready master 82m v1.27.3
|
|
ip-10-0-179-95.ec2.internal Ready worker 70m v1.27.3
|
|
ip-10-0-182-134.ec2.internal Ready worker 70m v1.27.3
|
|
ip-10-0-211-16.ec2.internal Ready master 82m v1.27.3
|
|
ip-10-0-250-100.ec2.internal Ready worker 69m v1.27.3
|
|
----
|