mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
69 lines
5.4 KiB
Plaintext
69 lines
5.4 KiB
Plaintext
:_content-type: ASSEMBLY
|
|
[id="updating-cluster-cli"]
|
|
= Updating a cluster using the CLI
|
|
include::_attributes/common-attributes.adoc[]
|
|
:context: updating-cluster-cli
|
|
|
|
toc::[]
|
|
|
|
////
|
|
All OpenShift advisories link directly to this assembly. If you are doing work that changes the URL, DON'T!
|
|
But if you really need to, please contact the release notes team so they can change the advisory templates. These templates are not part of the openshift-docs repo.
|
|
////
|
|
|
|
You can update, or upgrade, an {product-title} cluster within a minor version by using the OpenShift CLI (`oc`).
|
|
|
|
== Prerequisites
|
|
|
|
* Have access to the cluster as a user with `admin` privileges.
|
|
See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
|
|
* Have a recent xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your upgrade fails and you must xref:../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
|
|
* Support for {op-system-base}7 workers is removed in {product-title} {product-version}. You must replace {op-system-base}7 workers with {op-system-base}8 or {op-system} workers before upgrading to {product-title} {product-version}. Red Hat does not support in-place {op-system-base}7 to {op-system-base}8 upgrades for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
|
|
* Ensure all Operators previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel. Updating the Operators ensures they have a valid upgrade path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster upgrade. See xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Upgrading installed Operators] for more information.
|
|
* Ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
|
|
* If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see xref:../updating/updating-cluster-cli.adoc#manually-maintained-credentials-upgrade_updating-cluster-cli[Upgrading clusters with manually maintained credentials].
|
|
* If your cluster uses manually maintained credentials with the AWS Secure Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being upgraded to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].
|
|
* Ensure that you address all `Upgradeable=False` conditions so the cluster allows an upgrade to the next minor version. You can run the `oc adm upgrade` command for an output of all `Upgradeable=False` conditions and the condition reasoning to help you prepare for a minor version upgrade.
|
|
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Using the `unsupportedConfigOverrides` section to modify the configuration of an Operator is unsupported and might block cluster upgrades. You must remove this setting before you can upgrade your cluster.
|
|
====
|
|
|
|
[IMPORTANT]
|
|
====
|
|
If you are running cluster monitoring with an attached PVC for Prometheus, you might experience OOM kills during cluster upgrade. When persistent storage is in use for Prometheus, Prometheus memory usage doubles during cluster upgrade and for several hours after upgrade is complete. To avoid the OOM kill issue, allow worker nodes with double the size of memory that was available prior to the upgrade. For example, if you are running monitoring on the minimum recommended nodes, which is 2 cores with 8 GB of RAM, increase memory to 16 GB. For more information, see link:https://bugzilla.redhat.com/show_bug.cgi?id=1925061[BZ#1925061].
|
|
====
|
|
|
|
[role="_additional-resources"]
|
|
.Additional resources
|
|
|
|
* xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators]
|
|
|
|
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
|
|
|
.Additional resources
|
|
* xref:../installing/installing_aws/manually-creating-iam.adoc[Manually creating IAM for AWS]
|
|
* xref:../installing/installing_azure/manually-creating-iam-azure.adoc[Manually creating IAM for Azure]
|
|
* xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc[Manually creating IAM for GCP]
|
|
|
|
include::modules/machine-health-checks-pausing.adoc[leveloffset=+1]
|
|
|
|
include::modules/updating-sno.adoc[leveloffset=+1]
|
|
|
|
[role="_additional-resources"]
|
|
.Additional resources
|
|
|
|
* For information on which machine configuration changes require a reboot, see the note in xref:../architecture/control-plane.html#understanding-machine-config-operator_control-plane[Understanding the Machine Config Operator].
|
|
|
|
include::modules/update-upgrading-cli.adoc[leveloffset=+1]
|
|
include::modules/update-conditional-updates.adoc[leveloffset=+1]
|
|
|
|
[role="_additional-resources"]
|
|
.Additional resources
|
|
|
|
* xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels_understanding-upgrade-channels-releases[Upgrade channels and release paths]
|
|
|
|
include::modules/update-changing-update-server-cli.adoc[leveloffset=+1]
|