ROSA 4.8 clusters require user action before scheduling a minor version upgrade

Solution Verified - Updated -

Environment

  • Red Hat OpenShift Service on AWS (ROSA)
    • 4.8
    • AWS security token service (STS)

Issue

  • Red Hat OpenShift Service on AWS (ROSA) cluster upgrading from 4.8 to 4.9 need cluster owner action to ensure stability of the cluster through and after the upgrade operation.
  • To ensure that cluster owners understand the changes occurring as as part of upgrading the underlying Kubernetes to v1.22, there are acknowledgements necessary to ensure cluster owners have taken necessary precautions.
  • To ensure AWS policies have been updated before enabling ROSA STS 4.8 cluster upgrades to 4.9, AWS role policy updates are part of the upgrade workflow outlined in the Resolution below.

Resolution

Note: For other releases, please refer to OSD/ROSA cluster requires user action before install or upgrade.

Note: For ROSA IAM (non-STS) clusters, the STS role/policy related steps in this guide do not apply; those clusters will not have a step in the CLI workflow about ensuring policies are updated.

Prerequisites

Before starting with the upgrade to OpenShift 4.9 (which uses Kubernetes 1.22), as a significant number of deprecated APIs are removed in that version, it's necessary to review KCS 6329921: Preparing to upgrade to OpenShift Container Platform 4.9 to understand the changes and to verify if those changes could affect the custom applications in the cluster.

Prepare to Upgrade ROSA STS

To prepare for upgrading ROSA STS from from 4.8 to 4.9, the following tasks need to be done:

  1. Upgrade to latest/current ROSA CLI (1.1.11 or newer).

    As part of the upgrade task, the ROSA CLI can update STS policies for you with 'auto' mode, or allow you to inspect the changes before applying them, with 'manual' mode.

  2. Understand upgrading ROSA clusters with STS using ROSA CLI or the Red Hat Cloud Console.

  3. Prepare for an upgrade by updating your ROSA STS roles/policies to latest. List your account-roles and notice they are grouped by the prefix in their naming scheme. Using the prefix that is relevant to the roles for your cluster (assuming you're logged in) you can upgrade each group as shown here:

    $ rosa list account-roles
ROLE NAME                           ROLE TYPE      ROLE ARN                                                           OPENSHIFT VERSION
customprefix-ControlPlane-Role      Control plane  arn:aws:iam::00sample0000:role/customprefix-ControlPlane-Role      4.9
customprefix-Installer-Role         Installer      arn:aws:iam::00sample0000:role/customprefix-Installer-Role         4.9
customprefix-Support-Role           Support        arn:aws:iam::00sample0000:role/customprefix-Support-Role           4.9
customprefix-Worker-Role            Worker         arn:aws:iam::00sample0000:role/customprefix-Worker-Role            4.9
ManagedOpenShift-ControlPlane-Role  Control plane  arn:aws:iam::00sample0000:role/ManagedOpenShift-ControlPlane-Role  4.8
ManagedOpenShift-Installer-Role     Installer      arn:aws:iam::00sample0000:role/ManagedOpenShift-Installer-Role     4.8
ManagedOpenShift-Support-Role       Support        arn:aws:iam::00sample0000:role/ManagedOpenShift-Support-Role       4.8
ManagedOpenShift-Worker-Role        Worker         arn:aws:iam::00sample0000:role/ManagedOpenShift-Worker-Role        4.8

$ rosa upgrade account-roles --prefix ManagedOpenShift
#<this task proceeds depending on the state of your selected account-roles>

$ rosa list account-roles |grep ManagedOpenShift
ManagedOpenShift-ControlPlane-Role  Control plane  arn:aws:iam::00sample0000:role/ManagedOpenShift-ControlPlane-Role  4.9
ManagedOpenShift-Installer-Role     Installer      arn:aws:iam::00sample0000:role/ManagedOpenShift-Installer-Role     4.9
ManagedOpenShift-Support-Role       Support        arn:aws:iam::00sample0000:role/ManagedOpenShift-Support-Role       4.9
ManagedOpenShift-Worker-Role        Worker         arn:aws:iam::00sample0000:role/ManagedOpenShift-Worker-Role        4.9

    And now your ROSA STS account roles are prepared for the 4.9 release.
    With your account-roles at 'OpenShift Version' 4.9, you may now proceed to schedule an upgrade in the OCM UI or ROSA CLI (Assuming all noted prerequisites are addressed).

Optional:

If you wish to continue at the CLI to initiate your upgrade, as a cluster owner, proceed with the following step.
The upgrade cluster function checks for your acknowledgement of preparedness for Kubernetes 1.22 API deprecation details. After these checks are done, you are offered to schedule your upgrade to the 4.9 version for the cluster.
If you have more than one cluster, you may need to list them to determine the cluster you wish to upgrade. You may wish to list your clusters for the cluster ID and then run the upgrade command on the 4.8 cluster (the rosa upgrade cluster command will allow you to schedule an upgrade interactively):

$ rosa list clusters
$ rosa upgrade cluster -c <cluster id>

Root Cause

ROSA clusters upgrading from 4.8 to 4.9 need cluster owner action to ensure stability of the cluster through and after the upgrade operation.

For additional information about Kubernetes deprecated APIs, refer to:

For ROSA STS Clusters, AWS STS role policies required for ROSA 4.9 must be up to date when coming from older versions.

Diagnostic Steps

Check the version of ROSA CLI:

$ rosa version
1.1.11

Check if the cluster is version 4.8:

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.8.xx    True        False         8d      Cluster version is 4.8.xx

or

rosa describe cluster -c <cluster id> |grep Version
OpenShift Version:          4.8.32

Check your cluster version from the cluster settings or cluster overview at https://console.redhat.com/openshift.

To review details of role and policies necessary for ROSA STS, you may review all policies by generating them locally with:

$ rosa create account-roles --mode manual

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments