Menu Close
Settings Close

Language and Page Formatting Options

アップグレード

Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS のアップグレードオプションについて

概要

本書では、Red Hat OpenShift Service on AWS (ROSA) クラスターのアップグレードを説明します。

第1章 ROSA を 4.9 にアップグレードする準備

Red Hat OpenShift Service on AWS クラスターを OpenShift 4.9 にアップグレードするには、最新バージョンの Kubernetes で多数の API が削除されているため、API を評価して移行する必要があります。

Red Hat OpenShift Service on AWS クラスターをアップグレードする前に、必要なツールを適切なバージョンに更新する必要があります。

1.1. OpenShift 4.9 にアップグレードするための要件

バージョン 4.8 から 4.9 に AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターをアップグレードする前に、以下の要件を満たす必要があります。

前提条件

  • 最新の AWS CLI がインストールホストにインストールされている。
  • インストールホストに 1.1.10 以降の ROSA CLI がインストールされている。
  • 必要に応じて、バージョン 4.9 以降の OpenShift CLI (oc) をワークステーションにインストールしました。
  • AWS アカウント全体のロールおよびポリシーを更新するのに必要なパーミッションがある。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • Operator ポリシーをバージョン 4.9 に含め、AWS Identity and Access Management (IAM) アカウント全体のロールおよびポリシーを更新します。

1.1.1. OpenShift 4.9 へのアップグレード時に管理者が理解しておく内容

Red Hat OpenShift Service on AWS 4.9 は Kubernetes 1.22 を使用します。これにより、非推奨となった v1beta1 API が大幅に削除されました。

Red Hat OpenShift Service on AWS 4.8.14 では、クラスターを Red Hat OpenShift Service on AWS 4.8 から 4.9 にアップグレードする前に、管理者が手動で承認する必要があるという要件が導入されました。削除された API が、クラスター上で実行されている、またはクラスターと対話しているワークロード、ツール、またはその他のコンポーネントによって引き続き使用される Red Hat OpenShift Service on AWS 4.9 にアップグレードした後の問題を防ぐ上で役立ちます。管理者は、削除する予定の使用中の API のクラスターを評価し、影響を受けるコンポーネントを移行して適切な新規 API バージョンを使用する必要があります。これが完了すると、管理者による確認が可能です。

すべての Red Hat OpenShift Service on AWS 4.8 クラスターでは、Red Hat OpenShift Service on AWS 4.9 にアップグレードする前に、管理者は以下の点を確認しておく必要があります。

1.1.2. Kubernetes API の削除

Red Hat OpenShift Service on AWS 4.9 は Kubernetes 1.22 を使用します。これにより、以下の非推奨となった v1beta1 API が削除されました。v1 API バージョンを使用するようにマニフェストおよび API クライアントを移行する必要があります。削除された API の移行についての詳細は、Kubernetes documentation を参照してください。

表1.1 v1beta1 API が Kubernetes 1.22 から削除

リソースAPI主な変更

APIService

apiregistration.k8s.io/v1beta1

いいえ

CertificateSigningRequest

certificates.k8s.io/v1beta1

はい

ClusterRole

rbac.authorization.k8s.io/v1beta1

いいえ

clusterRoleBinding

rbac.authorization.k8s.io/v1beta1

いいえ

CSIDriver

storage.k8s.io/v1beta1

いいえ

CSINode

storage.k8s.io/v1beta1

いいえ

CustomResourceDefinition

apiextensions.k8s.io/v1beta1

はい

Ingress

extensions/v1beta1

はい

Ingress

networking.k8s.io/v1beta1

はい

IngressClass

networking.k8s.io/v1beta1

いいえ

Lease

coordination.k8s.io/v1beta1

いいえ

LocalSubjectAccessReview

authorization.k8s.io/v1beta1

はい

MutatingWebhookConfiguration

admissionregistration.k8s.io/v1beta1

はい

PriorityClass

scheduling.k8s.io/v1beta1

いいえ

Role

rbac.authorization.k8s.io/v1beta1

いいえ

RoleBinding

rbac.authorization.k8s.io/v1beta1

いいえ

SelfSubjectAccessReview

authorization.k8s.io/v1beta1

はい

StorageClass

storage.k8s.io/v1beta1

いいえ

SubjectAccessReview

authorization.k8s.io/v1beta1

はい

TokenReview

authentication.k8s.io/v1beta1

いいえ

ValidatingWebhookConfiguration

admissionregistration.k8s.io/v1beta1

はい

VolumeAttachment

storage.k8s.io/v1beta1

いいえ

1.2. 削除された API に関するクラスターの評価

削除される API が使用されている場所を管理者が特定するのに役立つ方法は複数あります。ただし、Red Hat OpenShift Service on AWS は、すべてのインスタンス、特にアイドル状態のワークロードまたは使用されている外部ツールを識別できるわけではありません。すべてのワークロードと削除された API のインスタンスに対する他の統合を適切に評価することは管理者の責任です。

1.2.1. 削除された API の使用を特定するためのアラートの確認

APIRemovedInNextReleaseInUse アラートは、クラスターで使用される API が削除されたことを示しています。このアラートのいずれかがクラスターで実行している場合は、アラートを確認し、マニフェストおよび API クライアントを移行して新規 API バージョンを使用することによりアラートを消去します。APIRequestCount API を使用して、使用中の API と、削除された API を使用しているワークロードに関する詳細情報を取得できます。

1.2.2. APIRequestCount を使用した削除された API の使用の特定

APIRequestCount API を使用して API 要求を追跡し、それらのいずれかが削除された API のいずれかを使用しているかどうかを確認することができます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできるようにする必要があります。

手順

  • 以下のコマンドを実行して、出力の REMOVEDINRELEASE 列を確認して、現在使用中の削除済みの API を特定します。

    $ oc get apirequestcounts

    出力例

    NAME                                        REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
    cloudcredentials.v1.operator.openshift.io                      32                      111
    ingresses.v1.networking.k8s.io                                 28                      110
    ingresses.v1beta1.extensions                1.22               16                      66
    ingresses.v1beta1.networking.k8s.io         1.22               0                       1
    installplans.v1alpha1.operators.coreos.com                     93                      167
    ...

    注記

    結果に表示される以下のエントリーは無視しても問題はありません。

    • system:serviceaccount:kube-system:generic-garbage-collector は削除するリソースを検索するため、結果に表示されます。
    • system:kube-controller-manager は、クォータの実施中にそのリソースをカウントするため、結果に表示されます。

    -o jsonpath を使用して結果をフィルターすることもできます。

    $ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'

    出力例

    1.22    certificatesigningrequests.v1beta1.certificates.k8s.io
    1.22    ingresses.v1beta1.extensions
    1.22    ingresses.v1beta1.networking.k8s.io

1.2.3. APIRequestCount を使用した、削除された API を使用しているワークロードを特定する

指定の API バージョンの APIRequestCount リソースを確認して、API を使用しているワークロードを特定することができます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできるようにする必要があります。

手順

  • 以下のコマンドを実行して、username および userAgent を確認して、API を使用しているワークロードを特定できるようにします。

    $ oc get apirequestcounts <resource>.<version>.<group> -o yaml

    以下に例を示します。

    $ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o yaml

    -o jsonpath を使用して、APIRequestCount リソースから username の値を抽出することもできます。

    $ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o jsonpath='{range ..username}{$}{"\n"}{end}' | sort | uniq

    出力例

    user1
    user2
    app:serviceaccount:delta

1.3. 削除された API インスタンスのインスタンスの移行

削除された Kubernetes API を移行する方法は、Kubernetes ドキュメントの Deprecated API Migration Guide を参照してください。

第2章 STS を使用した ROSA クラスターのアップグレード

2.1. ライフサイクルポリシーおよびプランニング

アップグレードを計画するには、Red Hat OpenShift Service on AWS の更新ライフサイクル を確認します。ライフサイクルページには、リリースの定義、サポートおよびアップグレードの要件、インストールポリシー情報、およびライフサイクルの日付が含まれます。

アップグレードは手動で開始されるか、自動的にスケジュールされます。Red Hat Site Reliability Engineers (SRE) はアップグレードの進捗を監視し、発生した問題に対応します。

2.2. STS を使用する ROSA クラスターのアップグレード

AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターをアップグレードする方法は 2 つあります。

  • rosa CLI を使用した個別のアップグレード
  • OpenShift Cluster Manager コンソールを使用した個別のアップグレード
注記

AWS Security Token Service (STS) を使用しない ROSA クラスターをアップグレードする手順は、ROSA クラスターのアップグレード を参照してください。

2.2.1. rosa CLI を使用したアップグレード

rosa CLI を使用して AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターを手動でアップグレードできます。

この方法では、より新しいバージョンが利用可能になると、クラスターの即時アップグレードがスケジュールされます。

前提条件

  • インストールホストに、最新の ROSA CLI をインストールして設定している。
  • クラスターを 4.7 から 4.8 にアップグレードする場合は、AWS Identity and Access Management (IAM) アカウント全体のロールおよびポリシーをバージョン 4.8 にアップグレードしている。また、CloudCredential カスタムリソースの cloudcredential.openshift.io/upgradeable-to アノテーションも更新している。

手順

  1. クラスターの現行バージョンを確認するには、以下のコマンドを入力します。

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    <cluster_name|cluster_id> はクラスター名またはクラスターの ID に置き換えます。
  2. アップグレードが利用可能であることを確認するには、以下のコマンドを入力します。

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

    このコマンドは、推奨されるバージョンを含め、クラスターをアップグレードすることのできるバージョンの一覧を返します。

  3. クラスターを利用可能な最新バージョンにアップグレードするには、以下のコマンドを入力します。

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

    クラスターの即時アップグレードがスケジュールされます。このアクションには、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。

    アップグレードが完了するとメールが送信されます。rosa CLI から rosa describe cluster を再度実行してステータスを確認するか、または OpenShift Cluster Manager コンソールでステータスを表示できます。

2.2.2. OpenShift Cluster Manager コンソールを介した個別のアップグレードのスケジュール

OpenShift Cluster Manager コンソールを使用して、AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターを手動で 1 回アップグレードできます。

前提条件

  • クラスターを 4.7 から 4.8 にアップグレードする場合は、AWS Identity and Access Management (IAM) アカウント全体のロールおよびポリシーをバージョン 4.8 にアップグレードしている。また、CloudCredential カスタムリソースの cloudcredential.openshift.io/upgradeable-to アノテーションも更新している。詳細は、4.7 から 4.8 へのアップグレードの準備 を参照してください。

手順

  1. OpenShift Cluster Manager Hybrid Cloud Console にログインします。
  2. アップグレードするクラスターを選択します。
  3. Settings タブをクリックします。
  4. Update strategy ペインで、Individual Updates を選択します。
  5. クラスターをアップグレードするバージョンを選択します。推奨されるクラスターのアップグレードが UI に表示されます。
  6. 承認が必要な更新バージョンを選択した場合は、管理者の確認を提供し、Approve and continue をクリックします。

    管理者の確認については、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。

  7. Node draining ペインで、一覧から猶予期間の間隔を選択します。猶予期間により、ノードは Pod のエビクションを強制する前に正常にドレイン (解放) できます。デフォルトは 1 時間 です。
  8. Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。
  9. Update status ペインで、Update available 情報を確認し、Update をクリックします。

    注記

    Update ボタンは、アップグレードが利用可能な場合に限り有効になります。

  10. Select version ダイアログで、ターゲットアップグレードバージョンを選択し、Next をクリックします。
  11. Schedule update ダイアログで、クラスターのアップグレードをスケジュールします。

    • 1 時間以内にアップグレードするには、Update now を選択し、Next をクリックします。
    • 後でアップグレードするには、Schedule a different time を選択し、アップグレードの日時を設定します。Next をクリックして確認ダイアログに進みます。
  12. バージョンを確認し、概要をスケジュールしたら、Confirm update を選択します。

    クラスターは、ターゲットバージョンにアップグレードするようにスケジュールされます。このアクションには、選択したアップグレードのスケジュールや、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。

    ステータスが Update status ペインに表示されます。

第3章 ROSA クラスターのアップグレード

3.1. ライフサイクルポリシーおよびプランニング

アップグレードを計画するには、Red Hat OpenShift Service on AWS の更新ライフサイクル を確認します。ライフサイクルページには、リリースの定義、サポートおよびアップグレードの要件、インストールポリシー情報、およびライフサイクルの日付が含まれます。

アップグレードは手動で開始されるか、自動的にスケジュールされます。Red Hat Site Reliability Engineers (SRE) はアップグレードの進捗を監視し、発生した問題に対応します。

3.2. ROSA クラスターのアップグレード

Red Hat OpenShift Service on AWS (ROSA) クラスターをアップグレードする方法は、3 つあります。

注記

AWS Security Token Service (STS) を使用する ROSA クラスターをアップグレードする手順は、STS を使用した ROSA クラスターのアップグレード を参照してください。

3.2.1. rosa CLI を使用したアップグレード

rosa CLI を使用して Red Hat OpenShift Service on AWS クラスターを手動でアップグレードできます。

この方法では、より新しいバージョンが利用可能になると、クラスターの即時アップグレードがスケジュールされます。

前提条件

  • インストールホストに、最新の ROSA CLI をインストールして設定している。

手順

  1. クラスターの現行バージョンを確認するには、以下のコマンドを入力します。

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    <cluster_name|cluster_id> はクラスター名またはクラスターの ID に置き換えます。
  2. アップグレードが利用可能であることを確認するには、以下のコマンドを入力します。

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

    このコマンドは、推奨されるバージョンを含め、クラスターをアップグレードすることのできるバージョンの一覧を返します。

  3. クラスターを利用可能な最新バージョンにアップグレードするには、以下のコマンドを入力します。

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

    クラスターの即時アップグレードがスケジュールされます。このアクションには、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。

    アップグレードが完了するとメールが送信されます。rosa CLI から rosa describe cluster を再度実行してステータスを確認するか、または OpenShift Cluster Manager コンソールでステータスを表示できます。

3.2.2. OpenShift Cluster Manager コンソールを介した個別のアップグレードのスケジュール

OpenShift Cluster Manager コンソールを使用して、Red Hat OpenShift Service on AWS クラスターのアップグレードを手動で 1 回スケジュールできます。

手順

  1. OpenShift Cluster Manager Hybrid Cloud Console にログインします。
  2. アップグレードするクラスターを選択します。
  3. Settings タブをクリックします。
  4. Update strategy ペインで、Individual Updates を選択します。
  5. クラスターをアップグレードするバージョンを選択します。推奨されるクラスターのアップグレードが UI に表示されます。
  6. 承認が必要な更新バージョンを選択した場合は、管理者の確認を提供し、Approve and continue をクリックします。

    管理者の確認については、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。

  7. Node draining ペインで、一覧から猶予期間の間隔を選択します。猶予期間により、ノードは Pod のエビクションを強制する前に正常にドレイン (解放) できます。デフォルトは 1 時間 です。
  8. Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。
  9. Update status ペインで、Update available 情報を確認し、Update をクリックします。

    注記

    Update ボタンは、アップグレードが利用可能な場合に限り有効になります。

  10. Select version ダイアログで、ターゲットアップグレードバージョンを選択し、Next をクリックします。
  11. Schedule update ダイアログで、クラスターのアップグレードをスケジュールします。

    • 1 時間以内にアップグレードするには、Update now を選択し、Next をクリックします。
    • 後でアップグレードするには、Schedule a different time を選択し、アップグレードの日時を設定します。Next をクリックして確認ダイアログに進みます。
  12. バージョンを確認し、概要をスケジュールしたら、Confirm update を選択します。

    クラスターは、ターゲットバージョンにアップグレードするようにスケジュールされます。このアクションには、選択したアップグレードのスケジュールや、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。

    ステータスが Update status ペインに表示されます。

3.2.3. クラスターの定期的なアップグレードのスケジュール

OpenShift Cluster Manager コンソールを使用して、Red Hat OpenShift Service on AWS の z-stream パッチバージョンの定期的な自動アップグレードをスケジュールできます。

手順

  1. OpenShift Cluster Manager Hybrid Cloud Console にログインします。
  2. アップグレードするクラスターを選択します。
  3. Settings タブをクリックします。
  4. Update strategy ペインで、Recurring updates を選択します。
  5. 更新が利用可能な場合は、アップグレードを希望する曜日および開始時刻を選択します。
  6. 管理者の確認を提供し、Approve and continue をクリックします。OpenShift Cluster Manager は、管理者の確認を受け取らずに、マイナーバージョンのスケジュールされた y-stream 更新を開始しません。

    管理者の確認については、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。

  7. Node draining ペインで、一覧から猶予期間の間隔を選択します。猶予期間により、ノードは Pod のエビクションを強制する前に正常にドレイン (解放) できます。デフォルトは 1 時間 です。
  8. Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。

    アップグレードが利用可能になると、希望する曜日および開始時間に、アップグレードがクラスターに自動的に適用されます。