アップグレード


Red Hat OpenShift Service on AWS 4

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

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) クラスターのアップグレードを説明します。

第1章 ROSA with HCP クラスターのアップグレード

1.1. ROSA with HCP クラスターのアップグレードオプション

OpenShift では、アップグレードとは、更新されたソフトウェアを使用して新しいコンポーネントをプロビジョニングし、それを使用して古いソフトウェアを含む既存のコンポーネントを置き換えることを意味します。

クラスターのどの部分をアップグレードするかを制御することで、ワークロードへのアップグレードの影響を制御できます。次に例を示します。

Hosted Control Plane のみをアップグレードする
これにより、Hosted Control Plane のアップグレードが開始します。ワーカーノードには影響しません。
マシンプール内のノードをアップグレードする
これにより、指定されたマシンプール内のノードのローリング置換が開始し、そのマシンプールのワーカーノードに一時的に影響が及びます。複数のマシンプールを同時にアップグレードすることもできます。
重要

マシンプールのアップグレードと同時に Hosted Control Plane をアップグレードすることはできません。

重要

クラスター内のノード間の互換性を維持するために、マシンプール内のノードは Hosted Control Plane よりも新しいバージョンを使用できません。つまり、マシンプールを同じバージョンにアップグレードする前に、必ず Hosted Control Plane を特定のバージョンにアップグレードする必要があります。

各マシンプールの --max-surge 値と --max-unavailable 値を編集することで、マシンプールのアップグレードに必要な時間と、アップグレードがワークロードに与える影響をさらに制御できます。これらのオプションは、マシンプールで同時にアップグレードできるノードの数、およびアップグレードによって余分なノードがプロビジョニングされるか、既存のノードの一部が使用不可になるか、またはその両方を制御するものです。次に例を示します。

  • 高いワークロードの可用性を優先するには--max-surge に高い値を設定し、--max-unavailable0 に設定することで、既存のノードを使用不可にする代わりに余分なノードをプロビジョニングできます。
  • インフラストラクチャーコストの削減を優先するには--max-unavailable に高い値を設定し、--max-surge0 に設定することで、既存のノードの一部を利用不可にし、余分なノードのプロビジョニングを回避することができます。
  • 複数のノードを同時にアップグレードしてアップグレード速度を優先するには--max-surge--max-unavailable の両方に適度な値を設定して、余分なノードをプロビジョニングし、一部の既存ノードを使用不可にすることができます。

これらのパラメーターとその使用方法の詳細は、ROSA CLI リファレンスrosa edit machinepool を参照してください。

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

アップグレードを計画するには、Red Hat OpenShift Service on AWS の更新ライフサイクル を確認します。

ライフサイクルページには、リリースの定義、サポートおよびアップグレードの要件、インストールポリシー情報、およびライフサイクルの日付が含まれます。

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

注記

コントロールプレーンが現在マルチアーキテクチャーに対応していない場合、アップグレードプロセスでは、クラスターをマルチアーキテクチャーイメージに移行してからバージョンアップグレードを適用します。マルチアーキテクチャークラスターは、x86 ベースと Arm ベースの両方のワークロードを実行できます。2024 年 7 月 25 日以降に作成されたクラスターは、デフォルトでマルチアーキテクチャー対応になっています。

1.3. ROSA CLI を使用した Hosted Control Plane のアップグレード

ROSA CLI を使用して、ROSA with HCP クラスターの Hosted Control Plane を手動でアップグレードできます。このメソッドは、より新しいバージョンが利用可能になった場合に、すぐに、または指定された将来の時間にコントロールプレーンのアップグレードをスケジュールします。

注記

コントロールプレーンは、2 つの y-stream マイナーバージョン内のマシンプールのみをサポートします。たとえば、バージョン 4.15.z を使用するコントロールプレーンを備えた ROSA with HCP クラスターは、バージョン 4.13.z および 4.14.z のマシンプールをサポートしますが、バージョン 4.12.z を使用するマシンプールをサポートしません。

前提条件

  • ROSA CLI の最新バージョンがインストール、設定されている。
  • Hosted Control Plane のアップグレードと同時にマシンプールのアップグレードは実行しておらず、実行する予定もない。

手順

  1. 次のコマンドを実行して、クラスターの現在のバージョンを確認します。

    $ rosa describe cluster --cluster=<cluster_name_or_id> 1
    1
    <cluster_name_or_id> は、クラスター名またはクラスター ID に置き換えます。
  2. 次のコマンドを実行して、コントロールプレーンをアップグレードできるバージョンをリスト表示します。

    $ rosa list upgrade --cluster=<cluster_name_or_id>

    このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。

    出力例

    VERSION  NOTES
    4.14.8   recommended
    4.14.7
    4.14.6

  3. 次のコマンドを実行して、クラスターの Hosted Control Plane をアップグレードします。

    $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
    • 指定したバージョンへの即時アップグレードをスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --version <version_number>

      Hosted Control Plane は即時アップグレードされる予定です。

    • 指定したバージョンへのアップグレードを将来の日付でスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version=<version_number>

      Hosted Control Plane は、協定世界時 (UTC) で指定された時間にアップグレードされる予定です。

トラブルシューティング

  • スケジュールされたアップグレードが開始されない場合があります。詳細は、Upgrade maintenance canceled を参照してください。

1.4. ROSA CLI を使用したマシンプールのアップグレード

ROSA CLI を使用して、ROSA with HCP クラスター内の 1 つ以上のマシンプールを手動でアップグレードできます。このメソッドは、より新しいバージョンがすぐに、または指定された将来の時間に利用可能になった場合に、指定されたマシンプールのアップグレードをスケジュールします。

注記

コントロールプレーンは、2 つの y-stream マイナーバージョン内のマシンプールのみをサポートします。たとえば、バージョン 4.15.z を使用するコントロールプレーンを備えた ROSA with HCP クラスターは、バージョン 4.13.z および 4.14.z のマシンプールをサポートしますが、バージョン 4.12.z を使用するマシンプールをサポートしません。

前提条件

  • ROSA CLI の最新バージョンがインストール、設定されている。
  • クラスター上で Hosted Control Plane のアップグレードが進行中ではなく、マシンプールのアップグレードと同時に実行する予定もない。
注記

ノードドレインタイムアウト、max-unavailable、max-surge などのマシンプール設定は、アップグレードのタイミングと成功に影響を及ぼす可能性があります。

手順

  1. 次のコマンドを実行して、クラスターの現在のバージョンを確認します。

    $ rosa describe cluster --cluster=<cluster_name_or_id> 1
    1
    <cluster_name_or_id> は、クラスター名またはクラスター ID に置き換えます。

    出力例

    OpenShift Version:     4.14.0

  2. 次のコマンドを実行して、マシンプールをアップグレードできるバージョンをリスト表示します。

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

    このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。

    出力例

    VERSION  NOTES
    4.14.5   recommended
    4.14.4
    4.14.3

    重要

    マシンプールをコントロールプレーンよりも高いバージョンにアップグレードしないでください。より高いバージョンに移行する場合は、まずコントロールプレーンをそのバージョンにアップグレードします。

  3. 次のコマンドを実行して、アップグレードするマシンプールのアップグレード動作を確認します。

    $ rosa describe machinepool --cluster=<cluster_name_or_id> <machinepool_name>

    出力例

    Replicas: 5
    Node drain grace period:   30 minutes
    
    Management upgrade:
    - Type: Replace
    - Max surge: 20%
    - Max unavailable: 20%

    この例では、これらの設定により、マシンプールはアップグレード中に 1 つの余分なノード (replicas の 20% の max-surge) をプロビジョニングし、最大 1 つのノードを使用不可 (replicas の 20% の max-unavailable) にすることができます。したがって、このマシンプールは、レプリカ数を超えて 1 つの新しいノードをプロビジョニングし、1 つのノードを使用不可にして置き換えることで、一度に 2 つのノードをアップグレードできます。Pod 中断予算を持つワークロードを保護するために必要な場合、ノードのアップグレードは最大 30 分 (node-drain-grace-period は 30 分) 遅延されることがあります。

  4. 次のコマンドを実行してマシンプールをアップグレードします。

    $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>

    アップグレードするマシンプールごとにこのコマンドを実行すると、複数のマシンプールを同時にアップグレードできます。

    • マシンプールの即時アップグレードをスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --version <version_number>

      マシンプールは即時アップグレードするようにスケジュールされており、指定されたマシンプール内のすべてのノードのローリング置換が開始します。

    • アップグレードを将来の時刻に開始するようにスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version <version_number>

      マシンプールは、協定世界時 (UTC) で指定された日時にアップグレードを開始するようにスケジュールされています。これにより、指定された時刻から、指定されたマシンプール内のすべてのノードのローリング置換が開始します。

1.5. ROSA CLI を使用したクラスター全体のアップグレード

クラスター全体をアップグレードするには、Hosted Control Plane とマシンプール内のノードの両方をアップグレードする必要があります。ただし、これらのコンポーネントを同時にアップグレードすることはできません。順番にアップグレードする必要があります。これは任意の順序で実行できます。ただし、クラスター内のノード間の互換性を維持するために、マシンプール内のノードは Hosted Control Plane よりも新しいバージョンを使用できません。したがって、Hosted Control Plane とマシンプール内のノードの両方を同じ OpenShift バージョンにアップグレードする必要がある場合は、最初に Hosted Control Plane をアップグレードし、次にマシンプールをアップグレードする必要があります。

前提条件
  • ROSA CLI の最新バージョンがインストール、設定されている。
  • このアップグレードと同時に他のアップグレードは実行しておらず、実行する予定もありません。

1.5.1. Hosted Control Plane のアップグレード

クラスター全体をアップグレードする必要がある場合は、まず Hosted Control Plane をアップグレードします。

前提条件

  • ROSA CLI の最新バージョンがインストール、設定されている。
  • Hosted Control Plane のアップグレードと同時にマシンプールのアップグレードは実行しておらず、実行する予定もない。

手順

  1. 次のコマンドを実行して、クラスターの現在のバージョンを確認します。

    $ rosa describe cluster --cluster=<cluster_name_or_id> 1
    1
    <cluster_name_or_id> は、クラスター名またはクラスター ID に置き換えます。
  2. 次のコマンドを実行して、コントロールプレーンをアップグレードできるバージョンをリスト表示します。

    $ rosa list upgrade --cluster=<cluster_name_or_id>

    このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。

    出力例

    VERSION  NOTES
    4.14.8   recommended
    4.14.7
    4.14.6

  3. 次のコマンドを実行して、クラスターの Hosted Control Plane をアップグレードします。

    $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
    • 指定したバージョンへの即時アップグレードをスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --version <version_number>

      Hosted Control Plane は即時アップグレードされる予定です。

    • 指定したバージョンへのアップグレードを将来の日付でスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version=<version_number>

      Hosted Control Plane は、協定世界時 (UTC) で指定された時間にアップグレードされる予定です。

1.5.2. マシンプールのアップグレード

Hosted Control Plane のアップグレードが完了したら、1 つ以上のマシンプールをアップグレードできます。

注記

ノードドレインタイムアウト、max-unavailable、max-surge などのマシンプール設定は、アップグレードのタイミングと成功に影響を及ぼす可能性があります。

手順

  1. 次のコマンドを実行して、クラスターの現在のバージョンを確認します。

    $ rosa describe cluster --cluster=<cluster_name_or_id> 1
    1
    <cluster_name_or_id> は、クラスター名またはクラスター ID に置き換えます。

    出力例

    OpenShift Version:     4.14.8

  2. 次のコマンドを実行して、マシンプールをアップグレードできるバージョンをリスト表示します。

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

    このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。

    出力例

    VERSION  NOTES
    4.14.5   recommended
    4.14.4
    4.14.3

    重要

    マシンプールをコントロールプレーンよりも高いバージョンにアップグレードしないでください。より高いバージョンに移行する場合は、まずコントロールプレーンをそのバージョンにアップグレードします。

  3. 次のコマンドを実行して、アップグレードするマシンプールのアップグレード動作を確認します。

    $ rosa describe machinepool --cluster=<cluster_name_or_id> <machinepool_name>

    出力例

    Replicas: 5
    Node drain grace period:   30 minutes
    
    Management upgrade:
    - Type: Replace
    - Max surge: 20%
    - Max unavailable: 20%

    この例では、これらの設定により、マシンプールはアップグレード中に 1 つの余分なノード (replicas の 20% の max-surge) をプロビジョニングし、最大 1 つのノードを使用不可 (replicas の 20% の max-unavailable) にすることができます。したがって、このマシンプールは、レプリカ数を超えて 1 つの新しいノードをプロビジョニングし、1 つのノードを使用不可にして置き換えることで、一度に 2 つのノードをアップグレードできます。Pod 中断予算を持つワークロードを保護するために必要な場合、ノードのアップグレードは最大 30 分 (node-drain-grace-period は 30 分) 遅延されることがあります。

  4. 次のコマンドを実行してマシンプールをアップグレードします。

    $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>

    アップグレードするマシンプールごとにこのコマンドを実行すると、複数のマシンプールを同時にアップグレードできます。

    • マシンプールの即時アップグレードをスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --version <version_number>

      マシンプールは即時アップグレードするようにスケジュールされており、指定されたマシンプール内のすべてのノードのローリング置換が開始します。

    • アップグレードを将来の時刻に開始するようにスケジュールするには、次のコマンドを実行します。

      $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version <version_number>

      マシンプールは、協定世界時 (UTC) で指定された日時にアップグレードを開始するようにスケジュールされています。これにより、指定された時刻から、指定されたマシンプール内のすべてのノードのローリング置換が開始します。

1.6. ROSA CLI を使用したアップグレード

ROSA CLI を使用して、ROSA with HCP クラスターを手動でアップグレードできます。この方法では、より新しいバージョンが利用可能な場合にクラスターを即時アップグレードするようにスケジュールします。

注記

コントロールプレーンは、2 つの y-stream マイナーバージョン内のマシンプールのみをサポートします。たとえば、バージョン 4.15.z を使用するコントロールプレーンを備えた ROSA with HCP クラスターは、バージョン 4.13.z および 4.14.z のマシンプールをサポートしますが、バージョン 4.12.z を使用するマシンプールをサポートしません。

前提条件

  • ROSA CLI の最新バージョンがインストール、設定されている。

手順

  1. 次のコマンドを実行して、クラスターの現在のバージョンを確認します。

    $ rosa describe cluster --cluster=<cluster_name_or_id> 1
    1
    <cluster_name_or_id> は、クラスター名またはクラスター ID に置き換えます。
  2. 次のコマンドを実行して、コントロールプレーンとマシンプールをアップグレードできるバージョンを一覧表示します。

    1. コントロールプレーンのバージョンの場合は、次のコマンドを実行します。

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

      このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。

      出力例

      VERSION  NOTES
      4.14.8   recommended
      4.14.7
      4.14.6

    2. マシンプールのバージョンについては、次のコマンドを実行します。

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

      このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。

      出力例

      VERSION  NOTES
      4.14.5   recommended
      4.14.4
      4.14.3

      注記

      マシンプールで利用可能な最新の更新は、コントロールプレーンの現在のバージョンに限定されます。まずコントロールプレーンが最新であることを確認してください。

  3. 以下のオプションのいずれかでクラスターをアップグレードします。

    • 次のコマンドを実行して、クラスターの Hosted Control Plane をアップグレードします。

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

      Hosted Control Plane のアップグレードがスケジュールされました。

    • 次のコマンドを実行して、クラスター上の特定のマシンプールをアップグレードします。

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

      これで、マシンプールのアップグレードがスケジュールされました。

1.7. OpenShift Cluster Manager コンソールを使用したアップグレード

OpenShift Cluster Manager コンソールを使用して、ROSA クラスターのアップグレードを手動で 1 回だけ、または定期的にスケジュールすることができます。

手順

  1. OpenShift Cluster Manager にログインします。
  2. アップグレードするクラスターを選択します。
  3. Settings タブをクリックします。
  4. Update strategy ペインで、必要な更新の種類を選択します。

    • 個別の更新の場合は、アップグレードをすぐに (1 時間以内に開始) または将来の時刻に要求できます。
    • 定期的な更新の場合は、利用可能な最新の x.y.Z (z-stream) バージョンへのアップグレードを自動的に開始する定期的な日時を選択します。

      重要

      定期的な更新は z-stream 更新にのみ適用されます。マイナーバージョンまたは y-stream の更新は手動で行う必要があります。新しい y-stream 更新が利用可能になると、通知が届きます。

  5. Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。
  6. Update status ペインで、Update available 情報を確認し、Update をクリックします。

    注記

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

  7. Update cluster ダイアログが開きます。推奨されるクラスターのアップグレードが Select version ペインに表示されます。クラスターのアップグレード先のバージョンを選択し、Next をクリックします。
  8. オプション: AWS Security Token Service (STS) を使用する ROSA クラスターの場合、選択したターゲットバージョンに応じて、アカウントレベルおよびクラスター固有の Operator ロールを更新する必要がある場合があります。

    1. ROSA CLI で、rosa list account-roles コマンドを実行して、アカウントロールをリスト表示し、アップグレード用に選択したターゲットマイナーバージョンとの互換性がロールにあることを確認します。ロールに互換性がない場合は、rosa upgrade account-roles コマンドを実行して、アカウントロールを最新の OpenShift バージョンにアップグレードします。
    2. ROSA CLI で、rosa list operator-roles コマンドを実行して、クラスターに関連付けられている Operator ロールをリスト表示し、アップグレード用に選択したターゲットマイナーバージョンとの互換性がロールにあることを確認します。互換性がない場合は、rosa upgrade operators-roles コマンドを実行して、クラスターの Operator ロールを最新の OpenShift バージョンにアップグレードします。
    3. 承認が必要な更新バージョンを選択した場合は、指定のフィールドに Acknowledge と入力して管理者の承認を提供し、Next をクリックします。
  9. Schedule update ダイアログで、クラスターのアップグレードをスケジュールします。

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

クラスターは、ターゲットバージョンにアップグレードするようにスケジュールされます。この操作には、選択したアップグレードスケジュールや、Pod Disruption Budget などのワークロード設定に応じて、最大 1 時間かかる場合があります。

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

トラブルシューティング

  • スケジュールされたアップグレードがトリガーされない場合があります。詳細は Upgrade maintenance cancelled を参照してください。

1.8. OpenShift Cluster Manager コンソールを使用したアップグレードの削除

OpenShift Cluster Manager コンソールを使用して、スケジュール済みのアップグレードを削除できます。

手順

  1. OpenShift Cluster Manager にログインします。
  2. アップグレードがスケジュールされているクラスターを選択します。
  3. Settings タブをクリックします。
  4. Update status ペインで、Cancel this update をクリックします。
  5. Cancel update ダイアログで更新の詳細を確認し、Cancel this update をクリックします。

スケジュール済みのアップグレードがキャンセルされたことを確認するメール通知が届きます。

第2章 ROSA (クラシックアーキテクチャー) クラスターのアップグレード

ROSA (クラシックアーキテクチャー) クラスターをアップグレードするには、次のいずれかの方法を使用します。

  • ROSA CLI (rosa) を使用した手動アップグレード - 1 回限りの即時アップグレードを開始するか、将来の日付または時刻に 1 回限りのアップグレードをスケジュールします。
  • OpenShift Cluster Manager UI を使用した手動アップブレード - 1 回限りの即時アップグレードを開始するか、将来の日付または時刻に 1 回限りのアップグレードをスケジュールします。または、新しい z バージョンが利用可能になるたびに、自動的に繰り返しアップグレードを実行するためのアップグレード時間をスケジュールします。

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

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

更新チャネルを使用して、クラスターをどの Red Hat OpenShift Container Platform マイナーバージョンに更新するかを決定できます。Red Hat OpenShift Service on AWS は、stable チャネル経由の更新のみをサポートしています。OpenShift の更新チャネルとリリースの詳細は、Understanding update channels and releases を参照してください。

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

ROSA (クラシックアーキテクチャー) クラスターは、ROSA CLI (rosa) または OpenShift Cluster Manager コンソールを使用してアップグレードする必要があります。

注記

実際のクラスターのアップグレードは、アップグレードスケジュールの時刻から 1 時間以内に開始します。さらに、ワークロードの設定によって、アップグレードの所要時間が変わる場合があります。

AWS Security Token Services (STS) を使用する ROSA (クラシックアーキテクチャー) クラスターをアップグレードするときに、ROSA CLI は、選択したクラスターのアカウントと Operator ロールポリシーがアップグレードのターゲットバージョンと互換性があることを確認します。ポリシーに互換性がある場合、CLI はクラスターを自動的にアップグレードします。選択したアップグレードバージョンとの互換性がポリシーにない場合、CLI は IAM ポリシーを自動的にアップグレードしてからクラスターをアップグレードします。アップグレードをスケジュールするときには、必要に応じて、アップグレードに関連する変更をレビューしたことを確認するために、管理者としての承認を行います。

2.2.1. ROSA (クラシックアーキテクチャー) クラスターのアップグレードの仕組み

アップグレードは手動で開始するか (1 回限り)、自動的にスケジュールされます (定期的)。Red Hat の Site Reliability Engineers (SRE) が、アップグレードの進行状況を監視して、修正措置の実施または発生した問題の解決を行うようプロアクティブに通知します。

Cluster Version Operator (CVO) は、OpenShift Container Platform の更新プロセスを調整および促進する主要コンポーネントです。

Managed Upgrade Operator (MUO) は、ROSA (クラシックアーキテクチャー) クラスターのアップグレードのスケジュール設定、監視、および通知を処理します。MUO は、管理対象クラスターのアップグレードの前後に動作条件が満たされていることを確認し、自動インプレースクラスターアップグレードをオーケストレーションします。

2.2.1.1. クラスターのアップグレードのスケジュール時刻

クラスターのアップグレードをスケジュールするには、スケジュール時刻を設定します。これは、クラスターのアップグレードの準備を開始し、アップグレード前のヘルスチェックと追加コンピュート容量の作成を行う時刻です。実際のクラスターのアップグレードは、スケジュールされた時刻から 1 時間以内に開始します。クラスターのアップグレードが開始すると、メール通知が届きます。

Pre-Health Check (PHC) は、スケジュールされた更新が期待どおりに進行するように、追加の保護を提供します。PHC は次の 2 つの場合に実行されます。

  • アップグレードが現在の時刻から 2 時間以上後にスケジュールされている場合、PHC が実行されます。障害が発生した場合、ユーザーに通知されます。この PHC は、アップグレードの 新規 フェーズ中に行われます。
  • アップグレードが即時または 2 時間以内に行われる場合、PHC はアップグレードの開始直前に実行されます。この PHC は、アップグレードの アップグレード フェーズ中に行われます。そのため、PHC はアップグレードフェーズ中に少なくとも 1 回は必ず実行されます。ただし、アップグレードが現在の時刻から 2 時間以上後にスケジュールされている場合は、事前に追加で実行することもできます。

ROSA CLI (rosa) で rosa describe upgrade --cluster=<cluster name|cluster_id> コマンドを実行すると、クラスターのアップグレードのステータスを確認できます。

2.2.1.2. ROSA (クラシックアーキテクチャー) アップグレードの概要

ROSA (クラシックアーキテクチャー) クラスターの更新中に実行される大まかな手順は次のとおりです。

  1. アップグレードを事前にスケジュールすると、PreHealthCheck がトリガーされ、アップグレードの開始前に対処できる障害がユーザーに通知されます。
  2. クラスターのアップグレードが開始される前に、MUO によってクラスターのヘルスチェックが実行されます。修正措置を必要とする問題が MUO によって特定された場合は、通知が届きます。MUO が実行するクラスターのヘルスチェックの例を次に示します。

    • ノードの更新をブロックまたは遅延させる可能性のある Pod Disruption Budgets (PDB) を特定します。
    • クラスター Operator が利用可能で正常であることを確認します。
    • クラスターの重要なアラートが発生していないことを確認します。
  3. 更新中にドレインされた Pod のスケジュールを可能にするために、クラスター内に一時的なコンピュートノードが作成されます。

    注記

    一時的なコンピュートノードの作成は必ずしも行われるとは限りません。たとえば、worker マシンプールがない場合、一時的なコンピュートノードは作成されません。これは、クラスター管理者が既存の worker マシンプールを削除し、異なる名前またはインスタンスタイプで別の worker マシンプールを作成した場合に発生する可能性があります。

  4. クラスターのバージョンがターゲットバージョンに設定されます。

    注記

    場合によっては、クラスターの更新が要求されてから完了するまでの間に、アップグレードパスが利用できなくなることがあります。このような場合、アップグレードは自動的にキャンセルされ、通知が送信されます。アップグレードを要求するには、別のターゲットバージョンを選択する必要があります。

  5. アップグレード中に、コントロールプレーンのコンポーネントが新しいバージョンに更新されます。
  6. 次に、個々のクラスター Operator が、クラスターの各領域の更新タスクを実行します。
  7. 最後に、MCO が、すべてのノードのシステム設定とオペレーティングシステムを更新します。このステップでは、ノード上で実行されているワークロードが正常にドレインされた後、各ノードが再起動されます。

    1. 各ノードの更新中に、PDB を遵守しながらワークロードがドレインされます。停止を許容しない PDB を持つワークロードがあると、基本的にノードのドレインがブロックされ、クラスターの更新にかかる時間が増加します。
    2. クラスター内の全ノードの更新中、クラスター更新は、ワークロードを安全にドレインできるように、ノードドレイン猶予期間 で指定された時間まで待機します。ノードドレイン猶予期間が経過すると、クラスターのアップグレードを続行できるように、ノードが強制的にドレインされます。ノードドレイン猶予期間は、アップグレードを開始する前にのみ設定できます。クラスターのアップグレードの開始後に変更することはできません。
    3. MCO は、クラスターノード更新時に、その経過時間に基づき、最も古いものから順に、マシン設定プールごとに 1 つずつノードを選択します。

2.2.2. ROSA CLI を使用したアップグレード

ROSA CLI (rosa) を使用して、Red Hat OpenShift Service on AWS (ROSA) クラスターを 1 時間以内にすぐにアップグレードできます。将来の時刻にアップグレードすることもできます。

前提条件

  • インストールホストに、最新の ROSA CLI をインストールして設定している。
  • Red Hat OpenShift Service on AWS クラスターが Ready 状態である。

手順

  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>

    このコマンドは、推奨されるバージョンを含め、クラスターをアップグレードすることのできるバージョンのリストを返します。この推奨は、条件付き更新のリスクに基づいています。既知の各リスクは、すべてのクラスターに当てはまる場合と、特定の条件に一致するクラスターにのみ当てはまる場合があります。OpenShift リリースノートを参照して、適切なアップグレード先のバージョンを評価、検証、決定してください。

  3. 1 時間以内にクラスターを指定のバージョンにすぐにアップグレードするには、次のコマンドを入力します。

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id> --version <version-id>
    注記

    AWS Security Token Service (STS) クラスターをアップグレードする場合、このコマンドによって、インタラクティブな IAM ロール/ポリシーのアップグレードモードプロセスが開始します。このプロセスでは、選択したクラスターのアカウントと Operator のロールポリシーがアップグレードのターゲットバージョンと互換性があることを確認します。選択したアップグレードバージョンとの互換性がポリシーにない場合、CLI は自動モードでポリシーを自動的にアップグレードします。

    クラスターは、Scheduled Time に示されるとおり、直ちにアップグレードされるようにスケジュールされます。アップグレードはスケジュール時刻から 1 時間以内に開始します。

  4. または、将来の UTC 時刻にクラスターをアップグレードするには、次のコマンドを入力します。

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>   \
              --version <version-id>   \
              --schedule-date yyyy-mm-dd \
              --schedule-time HH:mm
  5. クラスターのアップグレード中にドレインされるすべてのノードの猶予期間をカスタマイズするには、次のコマンドを入力します。

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>   \
              --version <version-id>   \
              --node-drain-grace-period 15 minutes
  6. 次のコマンドを入力すると、アップグレードのステータスが表示されます。このコマンドでは、ステータス (scheduled または started) とスケジュール時刻の両方が表示されます。

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

    出力例

    VERSION  NOTES
    4.15.14  recommended - scheduled for 2024-06-02 15:00 UTC
    4.15.13

クラスターのアップグレードのスケジュール、開始、完了を確認するメール通知が届きます。

トラブルシューティング

  • スケジュールされたアップグレードがトリガーされない場合があります。詳細は Upgrade maintenance cancelled を参照してください。

2.2.3. ROSA CLI を使用した ROSA クラスターのアップグレードの削除

ROSA CLI (rosa) または OpenShift Cluster Manager コンソールを使用して、スケジュール済みのアップグレードを削除できます。この手順では ROSA CLI を使用します。

手順

  1. 次のコマンドを使用して、クラスターの更新が開始していないことを確認します。

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

    出力例

    VERSION  NOTES
    4.15.14  recommended - scheduled for 2024-06-02 15:00 UTC
    4.15.13

  2. 次のコマンドを実行して、スケジュール済みの更新を削除します。

    $ rosa delete upgrade --cluster=<cluster_name|cluster_id>
  3. 確認プロンプトで Yes と入力して削除を確定します。

    出力例

    I: Successfully canceled scheduled upgrade on cluster 'my-cluster'

スケジュール済みのアップグレードがキャンセルされたことを確認するメール通知が届きます。

2.2.4. OpenShift Cluster Manager コンソールを使用したアップグレード

OpenShift Cluster Manager コンソールを使用して、ROSA クラスターのアップグレードを手動で 1 回だけ、または定期的にスケジュールすることができます。

手順

  1. OpenShift Cluster Manager にログインします。
  2. アップグレードするクラスターを選択します。
  3. Settings タブをクリックします。
  4. Update strategy ペインで、必要な更新の種類を選択します。

    • 個別の更新の場合は、アップグレードをすぐに (1 時間以内に開始) または将来の時刻に要求できます。
    • 定期的な更新の場合は、利用可能な最新の x.y.Z (z-stream) バージョンへのアップグレードを自動的に開始する定期的な日時を選択します。

      重要

      定期的な更新は z-stream 更新にのみ適用されます。マイナーバージョンまたは y-stream の更新は手動で行う必要があります。新しい y-stream 更新が利用可能になると、通知が届きます。

  5. オプション: Node draining ペインで、リストから猶予期間の間隔を選択します。猶予期間により、ノードは Pod のエビクションを強制する前に正常にドレイン (解放) できます。デフォルトは 1 時間 です。

    重要

    アップグレードプロセスを開始した後は、ノードドレインの猶予期間を変更できません。

  6. Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。
  7. Update status ペインで、Update available 情報を確認し、Update をクリックします。

    注記

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

  8. Update cluster ダイアログが開きます。推奨されるクラスターのアップグレードが Select version ペインに表示されます。クラスターのアップグレード先のバージョンを選択し、Next をクリックします。
  9. オプション: AWS Security Token Service (STS) を使用する ROSA クラスターの場合、選択したターゲットバージョンに応じて、アカウントレベルおよびクラスター固有の Operator ロールを更新する必要がある場合があります。

    1. ROSA CLI で、rosa list account-roles コマンドを実行して、アカウントロールをリスト表示し、アップグレード用に選択したターゲットマイナーバージョンとの互換性がロールにあることを確認します。ロールに互換性がない場合は、rosa upgrade account-roles コマンドを実行して、アカウントロールを最新の OpenShift バージョンにアップグレードします。
    2. ROSA CLI で、rosa list operator-roles コマンドを実行して、クラスターに関連付けられている Operator ロールをリスト表示し、アップグレード用に選択したターゲットマイナーバージョンとの互換性がロールにあることを確認します。互換性がない場合は、rosa upgrade operators-roles コマンドを実行して、クラスターの Operator ロールを最新の OpenShift バージョンにアップグレードします。
    3. 承認が必要な更新バージョンを選択した場合は、指定のフィールドに Acknowledge と入力して管理者の承認を提供し、Next をクリックします。
  10. Schedule update ダイアログで、クラスターのアップグレードをスケジュールします。

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

クラスターは、ターゲットバージョンにアップグレードするようにスケジュールされます。この操作には、選択したアップグレードスケジュールや、Pod Disruption Budget などのワークロード設定に応じて、最大 1 時間かかる場合があります。

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

トラブルシューティング

  • スケジュールされたアップグレードがトリガーされない場合があります。詳細は Upgrade maintenance cancelled を参照してください。

2.2.5. OpenShift Cluster Manager コンソールを使用したアップグレードの削除

OpenShift Cluster Manager コンソールを使用して、スケジュール済みのアップグレードを削除できます。

手順

  1. OpenShift Cluster Manager にログインします。
  2. アップグレードがスケジュールされているクラスターを選択します。
  3. Settings タブをクリックします。
  4. Update status ペインで、Cancel this update をクリックします。
  5. Cancel update ダイアログで更新の詳細を確認し、Cancel this update をクリックします。

スケジュール済みのアップグレードがキャンセルされたことを確認するメール通知が届きます。

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.