Menu Close
Settings Close

Language and Page Formatting Options

アップグレード

OpenShift Dedicated 4

OpenShift Dedicated のアップグレード

概要

本書では、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にアップグレードする前に、管理者が手動で承認する必要があるという要件が導入されました。削除されたAPIが、クラスター上で実行されている、またはクラスターと対話しているワークロード、ツール、またはその他のコンポーネントによって引き続き使用される OpenShift Dedicated 4.9にアップグレードした後の問題を防ぐ上で役立ちます。管理者は、削除する予定の使用中の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 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.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 は削除するリソースを検索するため、結果に表示されます。
    • 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 を介して実行できます。

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 サービスの一部ではありません。アップグレードをスケジューリングする前に、アプリケーションとアプリケーションデータのバックアップポリシーが適用されていることを確認してください。

2.1.1. 定期的なアップグレード

アップグレードは、クラスターの所有者または管理者が指定した日時に、自動的に実行されるようにスケジュールできます。アップグレードは、その週にアップグレードが利用できない場合を除いて、毎週行われます。

クラスターの定期的な更新を選択する場合は、管理者の確認を提供する必要があります。OpenShift Cluster Manager は、管理者の確認を受け取らずに、マイナーバージョンのスケジュールされた y-stream 更新を開始しません。管理者の確認については、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。

注記

定期的なアップグレードポリシーは任意です。設定されていない場合、アップグレードポリシーはデフォルトで個別に設定されます。

2.1.2. 個別のアップグレード

個別のアップグレードを選択した場合は、ご自身でクラスターを更新する必要があります。承認が必要な更新バージョンを選択する場合は、管理者の確認を提供する必要があります。管理者の確認については、OpenShift4.9 にアップグレードする際の管理者の確認 を参照してください。

クラスターのバージョンが古くなると、限定サポートステータスに移行します。OpenShift ライフサイクルポリシーの詳細は、OpenShift Dedicated 更新ライフサイクル を参照してください。

2.1.3. アップグレードの通知

OpenShift Cluster Manager コンソールから、Overview タブからクラスターの履歴を表示できます。アップグレードの状態は、サービスログの Cluster history の見出しの下に表示されます。

状態が変更されるたびに、クラスターの所有者とサブスクライブされたユーザーへの電子メール通知もトリガーされます。以下のイベントのメール通知が送信されます。

  • アップグレードがスケジュールされました。
  • アップグレードが開始されました。
  • アップグレードが完了しました。
  • アップグレードがキャンセルされました。
注記

定期的なアップグレードの場合は、アップグレードが実行される前にも、以下の頻度に基づいてメール通知が送信されます。

  • 2 週間前に通知
  • 1 週間前に通知
  • 1 日前に通知

関連情報

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

OpenShift Cluster Manager を使用して、OpenShift Dedicated クラスターの z-stream パッチバージョンの定期的な自動アップグレードをスケジュールできます。アップストリームの変更に基づいて、更新がリリースされない場合もあります。したがって、その週のアップグレードは行われません。

手順

  1. OpenShift Cluster Manager で、クラスターリストからクラスターを選択します。
  2. Upgrade settings タブをクリックして、アップグレード Operator にアクセスします。
  3. 定期的なアップグレードをスケジュールするには、Recurring updates を選択します。
  4. 管理者の確認を提供し、Approve and continue をクリックします。OpenShift Cluster Manager は、管理者の確認を受け取らずに、マイナーバージョンのスケジュールされた y-stream 更新を開始しません。
  5. クラスターをアップグレードする曜日と時間を指定します。
  6. 保存 をクリックします。
  7. オプション: ドロップダウンリストから指定された時間を選択して、ノードドレイン の猶予期間を設定します。デフォルトで 1 時間 の猶予期間が設定されています。
  8. 既存の定期的なアップグレードポリシーを編集するには、Upgrade Settings タブから希望する日付または開始時間を編集します。保存 をクリックします。
  9. 定期的なアップグレードポリシーをキャンセルするには、Upgrade Settings タブからアップグレード方法を個別に切り替えます。保存 をクリックします。

Upgrade settings タブの Upgrade status ボックスには、アップグレードがスケジュールされていることが示されます。次のスケジュールされた更新日時が表示されます。

2.3. クラスターの個々のアップグレードのスケジュール

OpenShift Cluster Manager を使用して、OpenShift Dedicated クラスターを手動で 1 回アップグレードできます。

手順

  1. OpenShift Cluster Manager で、クラスターリストからクラスターを選択します。
  2. Upgrade settings タブをクリックして、アップグレード Operator にアクセスします。Details の見出しの下にあるクラスターバージョンの横の Update をクリックして、Overview タブからクラスターを更新することもできます。
  3. 個別のアップグレードをスケジュールするには、Individual updates を選択します。
  4. Update Status ボックスの Update をクリックします。
  5. クラスターをアップグレードするバージョンを選択します。推奨されるクラスターのアップグレードが UI に表示されます。利用可能な各アップグレードバージョンの詳細については、View release notes をクリックしてください。
  6. 承認が必要な更新バージョンを選択した場合は、管理者の確認を提供し、Approve and continue をクリックします。
  7. 次へ をクリックします。
  8. アップグレードをスケジュールするには、以下を実行します。

    • 今から 1 時間以内にアップグレードするには、Upgrade now をクリックします。
    • Schedule a different time をクリックし、クラスターをアップグレードする日時を指定します。
  9. 次へ をクリックします。
  10. アップグレードポリシーを確認し、Confirm upgrade をクリックします。
  11. クラスターのアップグレードがスケジュールされると、コンファメーションが表示されます。Close をクリックします。
  12. オプション: ドロップダウンリストから指定された時間を選択して、ノードドレイン の猶予期間を設定します。デフォルトで 1 時間 の猶予期間が設定されています。

UI は、クラスターバージョンの横にある Overview タブで、アップグレードがスケジュールされていることを示します。View details をクリックして、アップグレードの詳細を表示します。スケジュールされたアップグレードをキャンセルする必要がある場合は、View Details ポップアップから Cancel this upgrade をクリックします。

同じアップグレードの詳細は、Upgrade status ボックスの下の Upgrade settings タブで確認できます。スケジュールされたアップグレードをキャンセルする必要がある場合は、Upgrade status ボックスで Cancel this upgrade をクリックします。

警告

OpenShift Dedicated で CVE またはその他の重大な問題が見つかった場合、すべてのクラスターは、修正がリリースされてから 48 時間以内にアップグレードされます。修正が利用可能になると通知され、48 時間の期間が終了する前に、クラスターが最新の優先開始時間に自動的にアップグレードされることが通知されます。定期的なアップグレードを開始する前であれば、いつでも手動でアップグレードできます。