アップグレード
Red Hat OpenShift Service on AWS のアップグレードオプションについて
概要
第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 がインストールホストにインストールされている。
-
インストールホストに ROSA CLI (
rosa
) の 1.1.10 以降がインストールされている。 -
必要に応じて、バージョン 4.9 以降の OpenShift CLI (
oc
) をワークステーションにインストールしている。 - AWS アカウント全体のロールおよびポリシーを更新するのに必要なパーミッションがある。
- クラスターの所有者または作成者である。
- 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 Kubernetes 1.22 から削除された v1beta1
API
リソース | 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
が結果に表示されます。すべての登録済み API を確認して削除するリソースを検索するため、これが表示されます。 -
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 (
rosa
) を介した個別のアップグレード - OpenShift Cluster Manager コンソールを使用した個別のアップグレード
AWS Security Token Service (STS) を使用しない ROSA クラスターをアップグレードする手順は、ROSA クラスターのアップグレード を参照してください。
2.2.1. ROSA CLI を使用したアップグレード
ROSA CLI (rosa
) を使用して、AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターを手動でアップグレードできます。
この方法では、より新しいバージョンが利用可能になると、クラスターの即時アップグレードがスケジュールされます。
前提条件
- インストールホストに、最新の ROSA CLI をインストールして設定している。
-
クラスターを 4.7 から 4.8 にアップグレードする場合は、AWS Identity and Access Management (IAM) アカウント全体のロールおよびポリシーをバージョン 4.8 にアップグレードしている。また、
CloudCredential
カスタムリソースのcloudcredential.openshift.io/upgradeable-to
アノテーションも更新している。
手順
クラスターの現行バージョンを確認するには、以下のコマンドを入力します。
$ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
- 1
<cluster_name|cluster_id>
はクラスター名またはクラスターの ID に置き換えます。
アップグレードが利用可能であることを確認するには、以下のコマンドを入力します。
$ rosa list upgrade --cluster=<cluster_name|cluster_id>
このコマンドは、推奨されるバージョンを含め、クラスターをアップグレードすることのできるバージョンのリストを返します。
クラスターを利用可能な最新バージョンにアップグレードするには、以下のコマンドを入力します。
$ rosa upgrade cluster --cluster=<cluster_name|cluster_id>
クラスターの即時アップグレードがスケジュールされます。このアクションには、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。
アップグレードが完了するとメールが送信されます。また、ROSA CLI から
rosa description cluster
コマンドを再度実行してステータスを確認したり、OpenShift Cluster Manager コンソールでステータスを表示したりすることもできます。
トラブルシューティング
- スケジュールされたアップグレードがトリガーされない場合があります。詳細はUpgrade maintenance cancelled を参照してください。
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 へのアップグレードの準備 を参照してください。
手順
- OpenShift Cluster Manager にログインします。
- アップグレードするクラスターを選択します。
- Settings タブをクリックします。
- Update strategy ペインで、Individual Updates を選択します。
- クラスターをアップグレードするバージョンを選択します。推奨されるクラスターのアップグレードが UI に表示されます。
承認が必要な更新バージョンを選択した場合は、管理者承認を指定し、Approve and continue をクリックします。
管理者の確認は、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。
Node draining ペインで、リストから猶予期間の間隔を選択します。猶予期間により、ノードは Pod のエビクションを強制する前に正常にドレイン (解放) できます。デフォルトは 1 時間 です。
注記アップグレードプロセスを開始した後は、ノードドレインの猶予期間を変更できません。
- Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。
Update status ペインで、Update available 情報を確認し、Update をクリックします。
注記Update ボタンは、アップグレードが利用可能な場合に限り有効になります。
- Select version ダイアログで、ターゲットアップグレードバージョンを選択し、Next をクリックします。
Schedule update ダイアログで、クラスターのアップグレードをスケジュールします。
- 1 時間以内にアップグレードするには、Update now を選択し、Next をクリックします。
- 後でアップグレードするには、Schedule a different time を選択し、アップグレードの日時を設定します。Next をクリックして確認ダイアログに進みます。
バージョンを確認し、概要をスケジュールしたら、Confirm update を選択します。
クラスターは、ターゲットバージョンにアップグレードするようにスケジュールされます。このアクションには、選択したアップグレードのスケジュールや、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。
ステータスが Update status ペインに表示されます。
トラブルシューティング
- スケジュールされたアップグレードがトリガーされない場合があります。詳細はUpgrade maintenance cancelled を参照してください。
第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 つあります。
-
ROSA CLI (
rosa
) を介した個別のアップグレード - OpenShift Cluster Managerを介した個別のアップグレード
- OpenShift Cluster Managerを介した定期的なアップグレード
AWS Security Token Service (STS) を使用する ROSA クラスターをアップグレードする手順は、STS を使用した ROSA クラスターのアップグレード を参照してください。
スケジュールされたアップグレードポリシーに従う場合、即時アップグレードであっても、アップグレードプロセスが開始されるまでに 1 時間以上の遅延が生じる可能性があります。アップグレードの所要時間は、ワークロードの設定によって異なる場合もあります。
3.2.1. ROSA CLI を使用したアップグレード
ROSA CLI (rosa
) を使用して、Red Hat OpenShift Service on AWS (ROSA) クラスターを手動でアップグレードできます。
この方法では、より新しいバージョンが利用可能になると、クラスターの即時アップグレードがスケジュールされます。
前提条件
- インストールホストに、最新の ROSA CLI をインストールして設定している。
手順
クラスターの現行バージョンを確認するには、以下のコマンドを入力します。
$ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
- 1
<cluster_name|cluster_id>
はクラスター名またはクラスターの ID に置き換えます。
アップグレードが利用可能であることを確認するには、以下のコマンドを入力します。
$ rosa list upgrade --cluster=<cluster_name|cluster_id>
このコマンドは、推奨されるバージョンを含め、クラスターをアップグレードすることのできるバージョンのリストを返します。
クラスターを利用可能な最新バージョンにアップグレードするには、以下のコマンドを入力します。
$ rosa upgrade cluster --cluster=<cluster_name|cluster_id>
クラスターの即時アップグレードがスケジュールされます。このアクションには、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。
アップグレードが完了するとメールが送信されます。また、ROSA CLI から
rosa description cluster
コマンドを再度実行してステータスを確認したり、OpenShift Cluster Manager コンソールでステータスを表示したりすることもできます。
トラブルシューティング
- スケジュールされたアップグレードがトリガーされない場合があります。詳細はUpgrade maintenance cancelled を参照してください。
3.2.2. OpenShift Cluster Manager コンソールを介した個別のアップグレードのスケジュール
OpenShift Cluster Manager コンソールを使用して、Red Hat OpenShift Service on AWS クラスターのアップグレードを手動で 1 回スケジュールできます。
手順
- OpenShift Cluster Manager にログインします。
- アップグレードするクラスターを選択します。
- Settings タブをクリックします。
- Update strategy ペインで、Individual Updates を選択します。
- クラスターをアップグレードするバージョンを選択します。推奨されるクラスターのアップグレードが UI に表示されます。
承認が必要な更新バージョンを選択した場合は、管理者承認を指定し、Approve and continue をクリックします。
管理者の確認は、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。
Node draining ペインで、リストから猶予期間の間隔を選択します。猶予期間により、ノードは Pod のエビクションを強制する前に正常にドレイン (解放) できます。デフォルトは 1 時間 です。
注記アップグレードプロセスを開始した後は、ノードドレインの猶予期間を変更できません。
- Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。
Update status ペインで、Update available 情報を確認し、Update をクリックします。
注記Update ボタンは、アップグレードが利用可能な場合に限り有効になります。
- Select version ダイアログで、ターゲットアップグレードバージョンを選択し、Next をクリックします。
Schedule update ダイアログで、クラスターのアップグレードをスケジュールします。
- 1 時間以内にアップグレードするには、Update now を選択し、Next をクリックします。
- 後でアップグレードするには、Schedule a different time を選択し、アップグレードの日時を設定します。Next をクリックして確認ダイアログに進みます。
バージョンを確認し、概要をスケジュールしたら、Confirm update を選択します。
クラスターは、ターゲットバージョンにアップグレードするようにスケジュールされます。このアクションには、選択したアップグレードのスケジュールや、Pod の停止状態の予算などのワークロード設定に応じて、1 時間以上かかる場合があります。
ステータスが Update status ペインに表示されます。
トラブルシューティング
- スケジュールされたアップグレードがトリガーされない場合があります。詳細はUpgrade maintenance cancelled を参照してください。
3.2.3. クラスターの定期アップグレードのスケジュール
OpenShift Cluster Manager コンソールを使用して、Red Hat OpenShift Service on AWS の z-stream パッチバージョンの定期的な自動アップグレードをスケジュールできます。
手順
- OpenShift Cluster Manager にログインします。
- アップグレードするクラスターを選択します。
- Settings タブをクリックします。
- Update strategy ペインで、Recurring updates を選択します。
- 更新が利用可能な場合は、アップグレードを希望する曜日および開始時刻を選択します。
管理者承認を指定し、Approve and continue をクリックします。OpenShift Cluster Manager が、管理者承認なしでマイナーバージョンのスケジュールされた y-stream 更新を開始することはありません。
管理者の確認は、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。
- Node draining ペインで、リストから猶予期間の間隔を選択します。猶予期間により、ノードは Pod のエビクションを強制する前に正常にドレイン (解放) できます。デフォルトは 1 時間 です。
Update strategy ペインで Save をクリックし、更新ストラテジーを適用します。
アップグレードが利用可能になると、希望する曜日および開始時間に、アップグレードがクラスターに自動的に適用されます。
第4章 HCP を使用した ROSA のアップグレード
ROSA コマンドラインインターフェイス (CLI) rosa
を使用して Hosted Control Plane とマシンプールを個別にアップグレードすることで、Hosted Control Plane (HCP) クラスターを使用して Red Hat OpenShift Service on AWS (ROSA) をアップグレードできます。
次のいずれかの方法を使用して、HCP クラスターをアップグレードします。
- Hosted Control Plane のみをアップグレードしてください。これはワーカーノードには影響しません。
- マシンプールのみをアップグレードします。これにより、特定のマシンプールのローリング再起動が開始されるので、特定のマシンプール上のワーカーノードに対して、一時的に影響があります。複数のマシンプールがある場合は、すべてのワーカーノードに影響があるわけではありません。
最初に Hosted Control Plane をアップグレードし、次にマシンプールをアップグレードします。
注記Hosted Control Plane とマシンプールの両方を同じバージョンにアップグレードする場合は、最初に Hosted Control Plane をアップグレードする必要があります。
アップグレードを計画するには、ROSA with HCP の更新ライフサイクル のドキュメントを確認してください。ライフサイクルページには、リリースの定義、サポートおよびアップグレードの要件、インストールポリシー情報、およびライフサイクルの日付が含まれます。
Hosted Control Plane のアップグレード期間はワークロード設定、マシンプールのアップグレード期間はワーカーノードの数によって異なります。
4.1. 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 の最新バージョンがインストール、設定されている。
手順
次のコマンドを実行して、クラスターの現在のバージョンを確認します。
$ rosa describe cluster --cluster=<cluster_name_or_id> 1
- 1
<cluster_name_or_id>
は、クラスター名またはクラスター ID に置き換えます。
次のコマンドを実行して、コントロールプレーンとマシンプールをアップグレードできるバージョンを一覧表示します。
コントロールプレーンのバージョンの場合は、次のコマンドを実行します。
$ rosa list upgrade --cluster=<cluster_name|cluster_id>
このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。
出力例
VERSION NOTES 4.14.8 recommended 4.14.7 4.14.6
マシンプールのバージョンについては、次のコマンドを実行します。
$ rosa list upgrade --cluster <cluster-name> --machinepool <machinepool_name>
このコマンドは、推奨バージョンを含む、利用可能な更新のリストを返します。
出力例
VERSION NOTES 4.14.5 recommended 4.14.4 4.14.3 4.14.2 4.14.1
注記マシンプールで利用可能な最新の更新は、コントロールプレーンの現在のバージョンに限定されます。まずコントロールプレーンが最新であることを確認してください。
以下のオプションのいずれかでクラスターをアップグレードします。
次のコマンドを実行して、クラスターの 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> <your_machine_pool_id> [--schedule-date=XX --schedule-time=XX] [--version <version_number>]
これで、マシンプールのアップグレードがスケジュールされました。
トラブルシューティング
- スケジュールされたアップグレードが開始されない場合があります。詳細は Upgrade maintenance cancelled を参照してください。