3.3. コントロールプレーンのみの更新を実行する
Kubernetes の基本的な設計により、マイナーバージョン間の OpenShift Container Platform の更新は、すべて順番に行う必要があります。OpenShift Container Platform <4.y> から <4.y+1> に更新してから、<4.y+2> に更新する必要があります。OpenShift Container Platform <4.y> から <4.y+2> に直接更新することはできません。ただし、2 つの偶数番号のマイナーバージョン間で更新したい管理者は、コントロールプレーン以外のホストを 1 回再起動するだけで更新できます。
この更新は、以前は EUS から EUS へ の更新と呼ばれていましたが、現在は コントロールプレーンのみ の更新と呼ばれています。この更新は、OpenShift Container Platform の 偶数番号のマイナーバージョン 間でのみ実行可能です。
コントロールプレーンのみの更新を試行する際には、考慮すべき注意事項がいくつかあります。
-
コントロールプレーンのみの更新は、関係するすべてのバージョン間の更新が
stable
チャネルで利用可能になった後にのみ提供されます。 - 奇数のマイナーバージョンへの更新中またはアップグレード後 (ただし、次の偶数のバージョンに更新する前) に問題が発生した場合、これらの問題を修正するには、コントロールプレーン以外のホストが先に進む前に奇数のバージョンへの更新を完了する必要がある場合があります。
- ワーカーまたはカスタムプールノードを更新して、メンテナンスにかかる時間に対応することにより、部分的な更新を行うことができます。
- 中間ステップで一時停止することにより、複数のメンテナンスウィンドウ中に更新プロセスを完了することができます。ただし、更新全体を 60 日以内に完了するように計画してください。これは、通常のクラスター自動化プロセスを確実に完了させるために重要です。
- マシン設定プールの一時停止が解除され、更新が完了するまで、OpenShift Container Platform の <4.y+1> および <4.y+2> の一部の機能およびバグ修正は利用できません。
-
すべてのクラスターは、プールを一時停止せずに、従来の更新用の EUS チャネルを使用して更新できます。一方、プールを一時停止した状態でコントロールプレーンのみの更新を実行できるのは、コントロールプレーン以外の
MachineConfigPools
オブジェクトを持つクラスターのみです。
3.3.1. コントロールプレーンのみの更新を実行する
以下の手順では、マスター以外のすべてのマシン設定プールを一時停止し、OpenShift Container Platform <4.y> から <4.y+1>、さらに <4.y+2> への更新を実行してから、以前に一時停止したマシン設定プールの一時停止を解除します。この手順に従うと、合計更新期間とワーカーノードが再起動される回数が減ります。
前提条件
- OpenShift Container Platform <4.y+1> および <4.y+2> のリリースノートを確認してください。
- 階層化された製品および Operator Lifecycle Manager (OLM) Operator のリリースノートおよび製品ライフサイクルを確認する。コントロールプレーンのみの更新前または更新中に、更新が必要になる場合があります。
- OpenShift Container Platform <4.y+1> から <4.y+2> に更新する前に必要な、非推奨の API の削除など、バージョン固有の前提条件をよく理解していることを確認してください。
クラスターが in-tree vSphere ボリュームを使用している場合は、vSphere をバージョン 7.0u3L+ または 8.0u2+ に更新します。
重要OpenShift Container Platform の更新を開始する前に vSphere を 7.0u3L+ または 8.0u2+ に更新しない場合、更新後にクラスターで既知の問題が発生する可能性があります。詳細は、Known Issues with OpenShift 4.12 to 4.13 or 4.13 to 4.14 vSphere CSI Storage Migration を参照してください。
3.3.1.1. Web コンソールを使用してコントロールプレーンのみの更新を実行する
前提条件
- マシン設定プールの一時停止が解除されている。
-
admin
権限を持つユーザーとして Web コンソールにアクセスできる。
手順
- Web コンソールの管理者パースペクティブを使用して、任意の Operator Lifecycle Manager (OLM) Operator を、目的の更新バージョンと互換性のあるバージョンに更新します。このアクションを実行する方法は、「関連情報」セクションの「インストール済み Operator の更新」を参照してください。
すべてのマシン設定プールが
Up to date
のステータスを表示し、マシン設定プールがUPDATING
のステータスを表示していないことを確認します。すべてのマシン設定プールのステータスを表示するには、Compute
MachineConfigPools をクリックし、Update status 列の内容を確認します。 注記マシン設定プールのステータスが
Updating
の場合は、このステータスがUp to date
に変わるまでお待ちください。このプロセスには数分かかる場合があります。チャネルを
eus-<4.y+2>
に設定します。チャネルを設定するには、Administration
Cluster Settings Channel をクリックします。現在のハイパーリンクチャネルをクリックすると、チャネルを編集できます。 - マスタープール以外のすべてのワーカーマシンプールを一時停止します。このアクションは、Compute ページの MachineConfigPools タブで実行できます。一時停止するマシン設定プールの横にある縦リーダーを選択し、Pause updates をクリックします。
- バージョン <4.y+1> に更新し、Save ステップまで完了します。これらのアクションを実行する方法は、「関連情報」セクションの「Web コンソールを使用したクラスターの更新」を参照してください。
- クラスターの 最後に完了したバージョン を表示して、<4.y+1> の更新が完了していることを確認します。この情報は、Cluster Settings ページの Details タブにあります。
- 必要に応じて、Web コンソールの管理者パースペクティブを使用して OLM オペレーターをアップグレードします。これらのアクションを実行する方法は、「関連情報」セクションの「インストール済み Operator の更新」を参照してください。
- バージョン <4.y+2> に更新し、Save ステップまで完了します。これらのアクションを実行する方法は、「関連情報」セクションの「Web コンソールを使用したクラスターの更新」を参照してください。
- クラスターの 最後に完了したバージョン を表示して、<4.y+2> の更新が完了していることを確認します。この情報は、Cluster Settings ページの Details タブにあります。
以前一時停止したすべてのマシン設定プールの一時停止を解除します。このアクションは、Compute ページの MachineConfigPools タブで実行できます。一時停止を解除するマシン設定プールの横にある縦リーダーを選択し、Unpause updates をクリックします。
重要プールが一時停止になった場合、クラスターは将来のマイナーバージョンへのアップグレードが許可されず、一部のメンテナンスタスクが禁止されます。これにより、クラスターは将来の劣化のリスクにさらされます。
以前に一時停止したプールが更新され、クラスターがバージョン <4.y+2> への更新を完了したことを確認します。
Compute ページの MachineConfigPools タブで、Update status の値が Up to date になっていることを確認して、プールが更新されたことを確認できます。
重要Red Hat Enterprise Linux (RHEL) コンピュートマシンを含むクラスターを更新すると、更新プロセス中はそれらのマシンが一時的に使用できなくなります。クラスターの更新の終了において各 RHEL マシンがのステートが
NotReady
になる際に、アップグレード Playbook を各 RHEL マシンに対して実行する必要があります。詳細は、関連情報セクションの「RHEL コンピュートマシンを含むクラスターの更新」を参照してください。クラスターの Last completed version を表示することで、クラスターが更新を完了したことを確認できます。この情報は、Cluster Settings ページの Details タブにあります。
3.3.1.2. CLI を使用してコントロールプレーンのみの更新を実行する
前提条件
- マシン設定プールの一時停止が解除されている。
-
各更新の前に OpenShift CLI (
oc
) をターゲットバージョンに更新する。
この前提条件をスキップすることは推奨されていません。更新前に OpenShift CLI (oc
) がターゲットバージョンに更新されていない場合、予期しない問題が発生する可能性があります。
手順
- Web コンソールの管理者パースペクティブを使用して、任意の Operator Lifecycle Manager (OLM) Operator を、目的の更新バージョンと互換性のあるバージョンに更新します。このアクションを実行する方法は、「関連情報」セクションの「インストール済み Operator の更新」を参照してください。
すべてのマシン設定プールが
UPDATED
のステータスを表示し、マシン設定プールがUPDATING
のステータスを表示していないことを確認します。すべてのマシン設定プールのステータスを表示するには、以下のコマンドを実行します。$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING master rendered-master-ecbb9582781c1091e1c9f19d50cf836c True False worker rendered-worker-00a3f0c68ae94e747193156b491553d5 True False
現在のバージョンは <4.y> で、更新する予定のバージョンは <4.y+2> です。次のコマンドを実行して、
eus-<4.y+2>
チャネルに変更します。$ oc adm upgrade channel eus-<4.y+2>
注記eus-<4.y+2>
が利用可能なチャネルの 1 つでないことを示すエラーメッセージが表示された場合、これは、Red Hat が EUS バージョンの更新をまだロールアウトしていることを示しています。通常、このロールアウトプロセスには GA 日から 45 ~ 90 日かかります。以下のコマンドを実行して、マスタープール以外のすべてのワーカーマシンプールを一時停止します。
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'
注記マスタープールを一時停止することはできません。
次のコマンドを実行して、最新バージョンに更新します。
$ oc adm upgrade --to-latest
出力例
Updating to latest version <4.y+1.z>
クラスターのバージョンを確認し、以下のコマンドを実行して更新が完了したことを確認します。
$ oc adm upgrade
出力例
Cluster version is <4.y+1.z> ...
次のコマンドを実行して、バージョン <4.y+2> に更新します。
$ oc adm upgrade --to-latest
次のコマンドを実行して、クラスターのバージョンを取得し、<4.y+2> の更新が完了していることを確認します。
$ oc adm upgrade
出力例
Cluster version is <4.y+2.z> ...
ワーカーノードを <4.y+2> に更新するには、次のコマンドを実行して、以前に一時停止したすべてのマシン設定プールの一時停止を解除します。
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'
重要プールの一時停止が解除されていない場合、クラスターは将来のマイナーバージョンへの更新が許可されず、一部のメンテナンスタスクが禁止されます。これにより、クラスターは将来の劣化のリスクにさらされます。
次のコマンドを実行して、以前に一時停止したプールが更新され、バージョン <4.y+2> への更新が完了したことを確認します。
$ oc get mcp
重要Red Hat Enterprise Linux (RHEL) コンピュートマシンを含むクラスターを更新すると、更新プロセス中はそれらのマシンが一時的に使用できなくなります。クラスターの更新の終了において各 RHEL マシンがのステートが
NotReady
になる際に、アップグレード Playbook を各 RHEL マシンに対して実行する必要があります。詳細は、関連情報セクションの「RHEL コンピュートマシンを含むクラスターの更新」を参照してください。出力例
NAME CONFIG UPDATED UPDATING master rendered-master-52da4d2760807cb2b96a3402179a9a4c True False worker rendered-worker-4756f60eccae96fb9dcb4c392c69d497 True False
3.3.1.3. レイヤード製品および Operator Lifecycle Manager でインストールされた Operator でコントロールプレーンのみの更新を実行する
次のものを含むクラスターでコントロールプレーンのみの更新を実行する場合、Web コンソールおよび CLI でのコントロールプレーンのみの更新手順に加えて、追加の手順を考慮する必要があります。
- レイヤード製品
- Operator Lifecycle Manager (OLM) でインストールされた Operator
レイヤード製品とは
レイヤード製品は、併用することが意図され、個別のサブスクリプションに分割できない複数の基礎となる製品で構成される製品を指します。OpenShift Container Platform レイヤード製品の例は、OpenShift のレイヤード製品 を参照してください。
レイヤード製品のクラスターおよび OLM でインストールされた Operator のクラスターに対してコントロールプレーンのみの更新を実行する場合は、以下を完了する必要があります。
- Operator Lifecycle Manager (OLM) を通じて以前にインストールされたすべての Operator を、ターゲットリリースと互換性のあるバージョンに更新している。Operator を更新することで、デフォルトの OperatorHub カタログが、クラスターの更新時に現行のマイナーバージョンから次のマイナーバージョンに切り替わる際、確実に有効な更新パスがあるようにします。「関連情報」セクションの「インストール済み Operator の更新」を参照し、互換性を確認する方法の詳細を確認して、インストールされている Operator を必要に応じて更新してください。
- 現在の Operator バージョンと更新後の Operator バージョン間のクラスターバージョン互換性を確認します。Red Hat OpenShift Container Platform Operator Update Information Checker を使用して、OLM Operator と互換性があるバージョンを確認できます。
例として、OpenShift Data Foundation (ODF) の <4.y> から <4.y+2> に、コントロールプレーンのみの更新を実行する手順を次に示します。これは、CLI または Web コンソールから実行できます。目的のインターフェイスからクラスターを更新する方法については、「関連情報」の Web コンソールを使用してコントロールプレーンのみの更新を実行する および CLI を使用してコントロールプレーンのみの更新を実行する を参照してください。
ワークフローの例
- ワーカーマシンプールを一時停止します。
-
OpenShift <4.y>
OpenShift <4.y+1> を更新します。 -
ODF <4.y>
ODF <4.y+1> を更新します。 -
OpenShift <4.y+1>
OpenShift <4.y+2> を更新します。 - ODF <4.y+2> に更新します。
- ワーカーマシンプールの一時停止を解除します。
ODF <4.y+2> への更新は、ワーカーマシンプールの一時停止が解除される前または後に実行できます。