Upgrading

Red Hat OpenShift Service on AWS 4

Understanding upgrading options for Red Hat OpenShift Service on AWS

Red Hat OpenShift Documentation Team

Abstract

This document provides information about upgrading Red Hat OpenShift Service on AWS (ROSA) clusters.

Chapter 1. Upgrading {hcp-title} clusters

You can upgrade Red Hat OpenShift Service on AWS (ROSA) with hosted control planes (HCP) clusters by individually upgrading the hosted control plane and the machine pools with the ROSA command line interface (CLI), rosa.

Use one of the following methods to upgrade your HCP clusters:

  • Upgrade only your hosted control plane. This does not impact your worker nodes.
  • Upgrade only your machine pool. This initiates a rolling reboot of a specific machine pool and temporarily impacts the worker nodes on the specific machine pool. It does not impact all your worker nodes if you have multiple machine pools.
  • Upgrade multiple machine pools simultaneously. This initiates a rolling reboot of worker nodes in the updated machine pools. This allows for updating multiple nodes simultaneously within a cluster.
  • Upgrade your hosted control plane first and then your machine pool.

    Note

    If you want to upgrade both your hosted control plane and your machine pool to the same version, you must upgrade the hosted control plane first.

To plan an upgrade, review the ROSA with HCP update life cycle documentation. The life cycle page includes release definitions, support and upgrade requirements, installation policy information, and life cycle dates.

Note

Hosted control plane upgrade duration varies based on your workload configuration, and machine pool upgrade duration varies based on the number of worker nodes.

1.1. Upgrading with the ROSA CLI

You can manually upgrade a ROSA with HCP cluster by using the ROSA CLI. This method schedules the cluster for an immediate upgrade if a more recent version is available.

Note

Your control plane only supports machine pools within two minor Y-stream versions. For example, a ROSA with HCP cluster with a control plane using version 4.15.z supports machine pools with version 4.13.z and 4.14.z, but the control plane does not support machine pools using version 4.12.z.

Prerequisites

  • You have installed and configured the latest version of the ROSA CLI.

Procedure

  1. Verify the current version of your cluster by running the following command:

    $ rosa describe cluster --cluster=<cluster_name_or_id> 1
    1
    Replace <cluster_name_or_id> with the cluster name or the cluster ID.
  2. List the versions that you can upgrade your control plane and machine pools to by running the following commands:

    1. For the control plane versions, run the following command:

      $ rosa list upgrade --cluster=<cluster_name|cluster_id>

      The command returns a list of available updates, including the recommended version.

      Example output

      VERSION  NOTES
      4.14.8   recommended
      4.14.7
      4.14.6

    2. For the machine pool versions, run the following command:

      $ rosa list upgrade --cluster <cluster-name> --machinepool <machinepool_name>

      The command returns a list of available updates, including the recommended version.

      Example output

      VERSION  NOTES
      4.14.5   recommended
      4.14.4
      4.14.3
      4.14.2
      4.14.1

      Note

      The latest available update for machine pools is limited to the current current version of the control plane. Ensure your control plane is up to date first.

  3. Upgrade your cluster with one of the following options:

    • Upgrade the cluster’s hosted control plane by running the following command:

      $ rosa upgrade cluster -c <cluster_name> --control-plane [--schedule-date=XX --schedule-time=XX] [--version <version_number>]

      Your hosted control plane is now scheduled for an upgrade.

    • Upgrade a specific machine pool on your cluster by running the following command:

      $ rosa upgrade machinepool -c <cluster_name> <your_machine_pool_id> [--schedule-date=XX --schedule-time=XX] [--version <version_number>]

      Your machine pool is now scheduled for an upgrade.

Troubleshooting

Chapter 2. Upgrading ROSA Classic clusters

2.1. Life cycle policies and planning

To plan an upgrade, review the Red Hat OpenShift Service on AWS update life cycle. The life cycle page includes release definitions, support and upgrade requirements, installation policy information and life cycle dates.

Upgrades are manually initiated or automatically scheduled. Red Hat Site Reliability Engineers (SREs) monitor upgrade progress and remedy any issues encountered.

2.2. Upgrading a ROSA Classic cluster

There are two methods to upgrade Classic Red Hat OpenShift Service on AWS (ROSA) clusters:

  • Individual upgrades through the ROSA CLI (rosa)
  • Individual upgrades through the OpenShift Cluster Manager console
Note

When you follow a scheduled upgrade policy, a delay of an hour or more before the upgrade process begins might occur, even if the upgrade is configured to begin immediately. Additionally, the duration of the upgrade might vary based on your workload configuration.

2.2.1. Upgrading with the ROSA CLI

You can upgrade a Red Hat OpenShift Service on AWS (ROSA) cluster manually by using the ROSA CLI (rosa).

This method schedules the cluster for an immediate upgrade, if a more recent version is available.

Prerequisites

  • You have installed and configured the latest ROSA CLI on your installation host.

Procedure

  1. To verify the current version of your cluster, enter the following command:

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    Replace <cluster_name|cluster_id> with the cluster name or the ID of the cluster.
  2. To verify that an upgrade is available, enter the following command:

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>

    The command returns a list of versions to which the cluster can be upgraded, including a recommended version.

  3. To upgrade a cluster to the latest available version, enter the following command:

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>

    The cluster is scheduled for an immediate upgrade. This action can take an hour or longer, depending on your workload configuration, such as pod disruption budgets.

    You will receive an email when the upgrade is complete. You can also check the status by running the rosa describe cluster command again from the ROSA CLI or view the status in OpenShift Cluster Manager console.

Troubleshooting

2.2.2. Scheduling individual upgrades through the OpenShift Cluster Manager console

You can schedule upgrades for a Red Hat OpenShift Service on AWS cluster manually one time by using OpenShift Cluster Manager console.

Procedure

  1. Log in to OpenShift Cluster Manager.
  2. Select a cluster to upgrade.
  3. Click the Settings tab.
  4. In the Update strategy pane, select Individual Updates.
  5. Select the version you want to upgrade your cluster to. Recommended cluster upgrades appear in the UI.
  6. If you select an update version that requires approval, provide an administrator’s acknowledgment and click Approve and continue.
  7. In the Node draining pane, select a grace period interval from the list. The grace period enables the nodes to gracefully drain before forcing the pod eviction. The default is 1 hour.

    Note

    You cannot change the node drain grace period after you start the upgrade process.

  8. In the Update strategy pane, click Save to apply your update strategy.
  9. In the Update status pane, review the Update available information and click Update.

    Note

    The Update button is enabled only when an upgrade is available.

  10. In the Select version dialog, choose a target upgrade version and click Next.
  11. In the Schedule update dialog, schedule your cluster upgrade.

    • To upgrade within an hour, select Update now and click Next.
    • To upgrade at a later time, select Schedule a different time and set a time and date for your upgrade. Click Next to proceed to the confirmation dialog.
  12. After reviewing the version and schedule summary, select Confirm update.

    The cluster is scheduled for an upgrade to the target version. This action can take an hour or longer, depending on the selected upgrade schedule and your workload configuration, such as pod disruption budgets.

    The status is displayed in the Update status pane.

Troubleshooting

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.