アップグレード
OpenShift Dedicated のアップグレード
概要
第1章 OpenShift Dedicated の 4.9 へのアップグレードの準備
OpenShift Dedicated クラスターを OpenShift 4.9 にアップグレードするには、最新バージョンの Kubernetes で多数の API が削除されているため、API を評価して移行する必要があります。
OpenShift Dedicated クラスターをアップグレードする前に、必要なツールを適切なバージョンに更新する必要があります。
1.1. OpenShift 4.9 へのアップグレード時の管理者承認
OpenShift Dedicated 4.9 は Kubernetes 1.22 を使用します。これにより、非推奨となった v1beta1
API が大幅に削除されました。
OpenShift Dedicated 4.8.14 では、クラスターを OpenShift Dedicated 4.8 から 4.9 にアップグレードする前に、管理者が手動で承認する必要があるという要件が導入されました。これは、OpenShift Dedicated 4.9 にアップグレードした後に発生する、ワークロード、ツール、またはクラスターで実行中またはクラスターと対話するその他のコンポーネントで削除された API が引き続き使用される問題を防ぐのに役立ちます。管理者は、削除が予定されている使用中の API に対するクラスターの評価を実施し、影響を受けるコンポーネントを移行して適切な新規 API バージョンを使用する必要があります。これが完了すると、管理者による承認が可能です。
すべての OpenShift Dedicated 4.8 クラスターでは、OpenShift Dedicated 4.9 にアップグレードする前に、この管理者承認が必要になります。
1.2. Kubernetes API の削除
OpenShift Dedicated 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.3. 削除された API に対するクラスターの評価
削除予定の API が使用されている場所を特定するために管理者が使用できる方法がいくつかあります。ただし、OpenShift Dedicated はすべてのインスタンスを特定できるわけではありません。特にアイドル状態のワークロードや使用されている外部ツールは特定できません。管理者は、すべてのワークロードと削除された API のインスタンスにおけるすべてのワークロードや統合について適切に評価する必要があります。
1.3.1. 削除された API の使用を特定するためのアラートの確認
APIRemovedInNextReleaseInUse
アラートは、クラスターで使用されている API が削除されたことを示しています。このアラートがクラスターで発生した場合はアラートを確認し、新しい API バージョンを使用するようにマニフェストと API クライアントを移行することでアラートをクリアします。APIRequestCount API
を使用して、どの API が使用されているか、どのワークロードが削除された API を使用しているかについて、詳しい情報を取得できます。
1.3.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.3.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.4. 削除された API インスタンスの移行
削除された Kubernetes API を移行する方法は、Kubernetes ドキュメントの Deprecated API Migration Guide を参照してください。
第2章 OpenShift Dedicated クラスターのアップグレード
自動アップグレードまたは手動アップグレードポリシーをスケジュールして、OpenShift Dedicated クラスターのバージョンを更新できます。OpenShift Dedicated クラスターのアップグレードは、Red Hat OpenShift Cluster Manager または OpenShift Cluster Manager CLI を介して実行できます。
Red Hat Site Reliability Engineers (SRE) はアップグレードの進捗を監視し、発生した問題に対応します。
2.1. OpenShift Dedicated クラスターのアップグレードについて
OpenShift Dedicated クラスターのアップグレードが利用可能になったら、Red Hat OpenShift Cluster Manager または OpenShift Cluster Manager CLI を使用して最新バージョンにアップグレードできます。既存クラスターに対して、またはクラスターを作成する際に、アップグレードポリシーを設定できます。アップグレードは、自動または手動で行うようにスケジュールできます。
Red Hat Site Reliability Engineers (SRE) は、OpenShift Dedicated クラスターで利用可能なバージョンのリストを提供します。クラスターごとに、利用可能なリリースの完全なリストに加え、対応するリリースノートを確認できます。OpenShift Cluster Manager により、サポートされている最新バージョンのクラスターのインストールが可能になります。アップグレードはいつでもキャンセルできます。
PodDisruptionBudget
で保護されたワークロードがアップグレード時に尊重される期間に対し、猶予期間を設定することもできます。この猶予期間の後に、PodDisruptionBudget
によって保護されたワークロードで、ノードから正常にドレインされていないものは、強制的に削除されます。
各 OpenShift Dedicated クラスターの Kubernetes オブジェクトおよび PV は、すべて OpenShift Dedicated サービスの一部としてバックアップされます。アプリケーションおよびアプリケーションデータのバックアップは、OpenShift Dedicated サービスの一部ではありません。アップグレードをスケジューリングする前に、アプリケーションとアプリケーションデータのバックアップポリシーが適用されていることを確認してください。
スケジュールされたアップグレードポリシーに従う場合、即時アップグレードであっても、アップグレードプロセスが開始されるまでに 1 時間以上の遅延が生じる可能性があります。アップグレードの所要時間は、ワークロードの設定によって異なる場合もあります。
2.1.1. 定期的なアップグレード
アップグレードは、クラスターの所有者または管理者が指定した日時に、自動的に実行されるようにスケジュールできます。アップグレードは、その週にアップグレードが利用できない場合を除いて、毎週行われます。
クラスターの定期的な更新を選択する場合は、管理者承認を指定する必要があります。OpenShift Cluster Manager が、管理者承認なしでマイナーバージョンのスケジュールされた y-stream 更新を開始することはありません。管理者承認については、OpenShift 4.9 へのアップグレード時の管理者承認 を参照してください。
定期的なアップグレードポリシーは任意で設定できます。設定されていない場合、アップグレードポリシーはデフォルトで個別に設定されます。
2.1.2. 個別のアップグレード
個別のアップグレードを選択した場合は、ユーザー自身でクラスターを更新する必要があります。承認が必要な更新バージョンを選択する場合は、管理者承認を指定する必要があります。管理者の確認は、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。
クラスターのバージョンが古くなると、限定サポートステータスに移行します。OpenShift ライフサイクルポリシーの詳細は、OpenShift Dedicated 更新ライフサイクル を参照してください。
2.1.3. アップグレードの通知
OpenShift Cluster Manager コンソールの Overview タブからクラスターの履歴を表示できます。アップグレードの状態は、サービスログの Cluster history の見出しの下に表示されます。
状態が変更されるたびに、クラスターの所有者とサブスクライブしているユーザーへの電子メール通知もトリガーされます。以下のイベントに対するメール通知が送信されます。
- アップグレードがスケジュールされた。
- アップグレードが開始された。
- アップグレードが完了した。
- アップグレードがキャンセルされた。
定期的なアップグレードの場合は、アップグレードが実行される前にも、以下の頻度でメール通知が送信されます。
- 2 週間前に通知
- 1 週間前に通知
- 1 日前に通知
関連情報
- サービスログおよびクラスター通知の連絡先について、詳しくは OpenShift Dedicated クラスターのサービスログへのアクセス を参照してください。
2.2. クラスターの定期アップグレードのスケジュール
OpenShift Cluster Manager を使用して、OpenShift Dedicated クラスターの z-stream パッチバージョンの定期的な自動アップグレードをスケジュールできます。アップストリームの変更によっては更新がリリースされない場合もあります。その場合、その週のアップグレードは行われません。
手順
- OpenShift Cluster Manager で、クラスターリストからクラスターを選択します。
- Upgrade settings タブをクリックして、アップグレード Operator にアクセスします。
- 定期的なアップグレードをスケジュールするには、Recurring updates を選択します。
- 管理者承認を指定し、Approve and continue をクリックします。OpenShift Cluster Manager が、管理者承認なしでマイナーバージョンのスケジュールされた y-stream 更新を開始することはありません。
- クラスターをアップグレードする曜日と時間を指定します。
- Save をクリックします。
- オプション: ドロップダウンリストから指定された時間を選択して、Node draining の猶予期間を設定します。デフォルトで 1 hour の猶予期間が設定されています。
- 既存の定期的なアップグレードポリシーを編集するには、Upgrade Settings タブから希望する日付または開始時間を編集します。Save をクリックします。
- 定期的なアップグレードポリシーをキャンセルするには、Upgrade Settings タブからアップグレード方法を個別に切り替えます。Save をクリックします。
Upgrade settings タブの Upgrade status ボックスには、アップグレードがスケジュールされていることが示されます。次のスケジュールされた更新日時が表示されます。
2.3. クラスターの個々のアップグレードのスケジュール
OpenShift Cluster Manager を使用して、OpenShift Dedicated クラスターを手動で 1 回アップグレードできます。
手順
- OpenShift Cluster Manager で、クラスターリストからクラスターを選択します。
- Upgrade settings タブをクリックして、アップグレード Operator にアクセスします。Details の見出しの下にあるクラスターバージョンの横の Update をクリックして、Overview タブからクラスターを更新することもできます。
- 個別のアップグレードをスケジュールするには、Individual updates を選択します。
- Update Status ボックスの Update をクリックします。
- クラスターをアップグレードするバージョンを選択します。推奨されるクラスターのアップグレードが UI に表示されます。利用可能な各アップグレードバージョンの詳細については、View release notes をクリックしてください。
- 承認が必要な更新バージョンを選択した場合は、管理者承認を指定し、Approve and continue をクリックします。
- Next をクリックします。
アップグレードをスケジュールするには、以下を実行します。
- 今から 1 時間以内にアップグレードするには、Upgrade now をクリックします。
- Schedule a different time をクリックし、クラスターをアップグレードする日時を指定します。
- Next をクリックします。
- アップグレードポリシーを確認し、Confirm upgrade をクリックします。
- クラスターのアップグレードがスケジュールされると、確認が表示されます。Close をクリックします。
- オプション: ドロップダウンリストから指定された時間を選択して、Node draining の猶予期間を設定します。デフォルトで 1 hour の猶予期間が設定されています。
Overview タブのクラスターバージョンの横にある UI に、アップグレードがスケジュールされていることが示されます。View details をクリックして、アップグレードの詳細を表示します。スケジュールされたアップグレードをキャンセルする必要がある場合は、View Details ポップアップから Cancel this upgrade をクリックします。
同じアップグレードの詳細は、Upgrade status ボックスの下の Upgrade settings タブで確認できます。スケジュールされたアップグレードをキャンセルする必要がある場合は、Upgrade status ボックスで Cancel this upgrade をクリックします。
OpenShift Dedicated で CVE またはその他の重大な問題が見つかった場合、修正がリリースされてから 48 時間以内にすべてのクラスターがアップグレードされます。修正が利用可能になると、その時点から 48 時間以内の希望する最も早い時間に、アップグレードが自動的に開始されることが通知されます。定期的なアップグレードを開始する前であれば、いつでも手動でアップグレードできます。