サポートコンソール開発者トライアルの開始お問い合わせ

第15章 シングルノード OpenShift クラスターのイメージベースアップグレード

15.1. シングルノード OpenShift クラスターのイメージベースのアップグレードについて

OpenShift Container Platform 4.14.13 以降では、Lifecycle Agent によって、シングルノード OpenShift クラスターのプラットフォームバージョンをアップグレードする別の方法が提供されます。イメージベースアップグレードは標準のアップグレード方法よりも高速で、OpenShift Container Platform <4.y> から <4.y+2>、<4.y.z> から <4.y.z+n> に直接アップグレードできます。

このアップグレード方法では、ターゲットのシングルノード OpenShift クラスターに新しい ostree stateroot としてインストールされている専用のシードクラスターから生成された OCI イメージを使用します。シードクラスターは、ターゲットの OpenShift Container Platform バージョン、Day 2 Operator、およびすべてのターゲットクラスターに共通の設定を使用してデプロイされたシングルノード OpenShift クラスターです。

シードクラスターから生成されたシードイメージを使用して、シードクラスターと同じハードウェア、Day 2 Operator、およびクラスター設定の組み合わせを持つ任意のシングルノード OpenShift クラスター上のプラットフォームバージョンをアップグレードできます。

重要

イメージベースアップグレードでは、クラスターが実行されているハードウェアプラットフォームに固有のカスタムイメージが使用されます。それぞれのハードウェアプラットフォームには、個別のシードイメージが必要です。

Lifecycle Agent は、参加しているクラスター上の 2 つのカスタムリソース (CR) を使用してアップグレードを行います。

  • シードクラスターでは、SeedGenerator CR によってシードイメージの生成が可能になります。この CR は、シードイメージをプッシュするリポジトリーを指定します。
  • ターゲットクラスターでは、ImageBasedUpgrade CR によって、ターゲットクラスターのアップグレード用のシードイメージとワークロードのバックアップ設定が指定されます。

SeedGenerator CR の例

apiVersion: lca.openshift.io/v1
kind: SeedGenerator
metadata:
  name: seedimage
spec:
  seedImage: <seed_image>

ImageBasedUpgrade CR の例

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle 1
  seedImageRef: 2
    version: <target_version>
    image: <seed_container_image>
    pullSecretRef:
      name: <seed_pull_secret>
  autoRollbackOnFailure: {}
#    initMonitorTimeoutSeconds: 1800 3
  extraManifests: 4
  - name: example-extra-manifests
    namespace: openshift-lifecycle-agent
  oadpContent: 5
  - name: oadp-cm-example
    namespace: openshift-adp

1
ImageBasedUpgrade CR のステージ。値は、Idle、Prep、Upgrade、または Rollback になります。
2
ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。
3
オプション: ロールバックする時間枠 (秒単位)。最初の再起動後、この時間枠内にアップグレードが完了しないと、ロールバックが実行されます。定義されていないか 0 に設定されている場合は、デフォルト値の 1800 秒 (30 分) が使用されます。
4
オプション: アップグレード後に保持するカスタムカタログソースと、ターゲットクラスターに適用する、シードイメージに含まれていない追加のマニフェストを含む ConfigMap リソースのリスト。
5
OADP の Backup および Restore CR を含む ConfigMap リソースのリスト。

15.1.1. イメージベースアップグレードの各ステージ

シードクラスターでシードイメージを生成した後、ImageBasedUpgrade CR で spec.stage フィールドを以下のいずれかの値に設定することで、ターゲットクラスターのステージを移動できます。

  • Idle
  • Prep
  • Upgrade
  • Rollback (オプション)

図15.1 イメージベースアップグレードの各ステージ

イメージベースアップグレードの各ステージ

15.1.1.1. Idle ステージ

Lifecycle Agent は、Operator が最初にデプロイされるときに、stage: Idle に設定された ImageBasedUpgrade CR を作成します。これはデフォルトのステージです。進行中のアップグレードはなく、クラスターは Prep ステージに移行する準備ができています。

図15.2 Idle ステージからの移行

Idle ステージからの移行

Idle ステージに移行して、次のいずれかの手順も実行します。

  • 正常なアップグレードを終了する
  • ロールバックを終了する
  • Upgrade ステージのピボット前フェーズまで、進行中のアップグレードをキャンセルする

Idle ステージに移行すると、Lifecycle Agent によってリソースが確実にクリーンアップされるため、クラスターの再アップグレードへの準備が整います。

図15.3 Idle ステージへの移行

Idle ステージへの移行
重要

アップグレードをキャンセルするときに RHACM を使用する場合は、ターゲットのマネージドクラスターから import.open-cluster-management.io/disable-auto-import アノテーションを削除して、クラスターの自動インポートを再度有効にする必要があります。

15.1.1.2. Prep ステージ

注記

このステージは、スケジュールされたメンテナンス期間の前に完了できます。

Prep ステージでは、ImageBasedUpgrade CR で以下のアップグレードの詳細を指定します。

  • 使用するシードイメージ
  • バックアップするリソース
  • 適用する追加のマニフェストと、アップグレード後に保持するカスタムカタログソース (ある場合)

次に、指定した内容に基づいて、Lifecycle Agent は現在実行中のバージョンに影響を与えずにアップグレードの準備をします。このステージでは、Lifecycle Agent は、ターゲットクラスターが特定の条件を満たしているかどうかをチェックして、Upgrade ステージに進む準備ができていることを確認します。Operator により、シードイメージが、シードイメージで指定された追加のコンテナーイメージとともに、ターゲットクラスターにプルされます。Lifecycle Agent は、コンテナーストレージディスクに十分な領域があるかどうかを確認します。必要に応じて、ディスク使用量が指定のしきい値を下回るまで、固定されていないイメージが Operator によって削除されます。コンテナーストレージディスクのクリーンアップを設定または無効にする方法の詳細は、「コンテナーストレージディスクの自動イメージクリーンアップの設定」を参照してください。

また、OADP Operator の Backup および Restore CR を使用して、バックアップリソースを準備します。これらの CR は、クラスターを再設定し、クラスターを RHACM に登録して、アプリケーションアーティファクトを復元するために Upgrade ステージで使用されます。

OADP Operator に加えて、Lifecycle Agent は ostree バージョン管理システムを使用してバックアップを作成します。これにより、アップグレードとロールバックの両方の後に、クラスターの完全な再設定が可能となります。

Prep ステージが終了したら、Idle ステージに移動してアップグレードプロセスをキャンセルするか、ImageBasedUpgrade CR の Upgrade ステージに移動してアップグレードを開始できます。アップグレードをキャンセルすると、Operator はクリーンアップ操作を実行します。

図15.4 Prep ステージからの移行

Prep ステージからの移行

15.1.1.3. Upgrade ステージ

Upgrade ステージは 2 つのフェーズで構成されています。

ピボット前
新しい stateroot にピボットする直前に、Lifecycle Agent は必要なクラスター固有のアーティファクトを収集し、新しい stateroot に保存します。Prep ステージで指定されたクラスターリソースのバックアップは、互換性のあるオブジェクトストレージソリューション上に作成されます。Lifecycle Agent は、ImageBasedUpgrade CR の extraManifests フィールドに指定された CR、またはターゲットクラスターにバインドされた ZTP ポリシーに記述されている CR をエクスポートします。ピボット前のフェーズが完了すると、Lifecycle Agent は新しい stateroot デプロイメントをデフォルトのブートエントリーとして設定し、ノードを再起動します。
ピボット後
新しい stateroot から起動した後、Lifecycle Agent はシードイメージのクラスター暗号化も再生成します。これにより、同じシードイメージでアップグレードされた各シングルノード OpenShift クラスターに、一意で有効な暗号化オブジェクトが確保されます。次に、Operator は、ピボット前のフェーズで収集されたクラスター固有のアーティファクトを適用して、クラスターを再設定します。Operator は保存されたすべての CR を適用し、バックアップを復元します。

アップグレードが完了し、変更が正常に行われたら、Idle ステージに移行してアップグレードを終了できます。

重要

アップグレードを終了すると、元のリリースにロールバックすることはできません。

図15.5 Upgrade ステージからの移行

Upgrade ステージからの移行

アップグレードをキャンセルする場合は、Upgrade ステージのピボット前フェーズまではキャンセルできます。アップグレード後に問題が発生した場合は、Rollback ステージに進んで手動でロールバックすることができます。

15.1.1.4. Rollback ステージ

Rollback ステージは、失敗時に手動または自動で開始できます。Rollback ステージでは、Lifecycle Agent は元の ostree stateroot デプロイメントをデフォルトとして設定します。その後、ノードは OpenShift Container Platform の以前のリリースとアプリケーション設定で再起動します。

警告

ロールバック後に Idle ステージに移行すると、Lifecycle Agent は失敗したアップグレードのトラブルシューティングに使用できるリソースをクリーンアップします。

指定された制限時間内にアップグレードが完了しない場合、Lifecycle Agent は自動ロールバックを開始します。自動ロールバックの詳細は、「Lifecycle Agent を使用した Rollback ステージへの移行」または「Lifecycle Agent と GitOps ZTP を使用した Rollback ステージへの移行」セクションを参照してください。

図15.6 Rollback ステージからの移行

Rollback ステージからの移行

関連情報

15.1.2. イメージベースアップグレードのガイドライン

イメージベースアップグレードを成功させるには、デプロイメントが特定の要件を満たしている必要があります。

イメージベースアップグレードを実行できるさまざまなデプロイメント方法があります。

GitOps ZTP
クラスターをデプロイおよび設定するには、GitOps Zero Touch Provisioning (ZTP) を使用します。
非 GitOps
クラスターを手動でデプロイおよび設定します。

非接続環境でイメージベースアップグレードを実行できます。非接続環境でイメージをミラーリングする方法の詳細は、「非接続インストールのイメージのミラーリング」を参照してください。

関連情報

15.1.2.1. コンポーネントの最小ソフトウェアバージョン

デプロイメント方法に応じて、イメージベースアップグレードには次の最小ソフトウェアバージョンが必要です。

表15.1 コンポーネントの最小ソフトウェアバージョン
コンポーネントソフトウェアバージョン必須

Lifecycle Agent

4.16

はい

OADP Operator

1.4.1

はい

マネージドクラスターのバージョン

4.14.13

はい

ハブクラスターのバージョン

4.16

いいえ

RHACM

2.10.2

いいえ

GitOps ZTP プラグイン

4.16

GitOps ZTP デプロイメント方式のみ

Red Hat OpenShift GitOps

1.12

GitOps ZTP デプロイメント方式のみ

Topology Aware Lifecycle Manager (TALM)

4.16

GitOps ZTP デプロイメント方式のみ

Local Storage Operator [1]

4.14

はい

論理ボリュームマネージャー (LVM) ストレージ [1]

4.14.2

はい

  1. 永続ストレージは、LVM Storage または Local Storage Operator のいずれかによって提供される必要があり、両方によって提供される必要はありません。

15.1.2.2. ハブクラスターのガイドライン

Red Hat Advanced Cluster Management (RHACM) を使用している場合は、ハブクラスターは次の条件を満たしている必要があります。

  • シードイメージに RHACM リソースが含まれないようにするには、シードイメージを生成する前に、オプションの RHACM アドオンをすべて無効にする必要があります。
  • ターゲットのシングルノード OpenShift クラスターでイメージベースアップグレードを実行する前に、ハブクラスターを少なくともターゲットバージョンにアップグレードする必要があります。

15.1.2.3. シードイメージのガイドライン

シードイメージは、同じハードウェアと同様の設定を持つシングルノードの OpenShift クラスターのセットを対象とします。つまり、シードクラスターは、次の項目についてターゲットクラスターの設定と一致する必要があります。

  • CPU トポロジー

    • CPU コア数
    • チューニング済みのパフォーマンス設定 (予約 CPU 数など)
  • ターゲットクラスターの MachineConfig リソース

  • IP バージョン

    注記

    このリリースではデュアルスタックネットワークはサポートされていません。

  • Lifecycle Agent と OADP Operator を含む Day 2 Operator のセット
  • 非接続レジストリー
  • FIPS 設定

次の設定は、参加するクラスターで部分的に一致している必要があります。

  • ターゲットクラスターにプロキシー設定がある場合、シードクラスターにもプロキシー設定が必要ですが、設定は同じである必要はありません。
  • 参加するすべてのクラスターでは、コンテナーストレージ用のプライマリーディスク上に専用のパーティションが必要です。ただし、パーティションのサイズと開始は同じである必要はありません。MachineConfig CR 内の spec.config.storage.disks.partitions.label: varlibcontainers ラベルのみが、シードクラスターとターゲットクラスターの両方で一致する必要があります。ディスクパーティションの作成方法の詳細は、「ostree stateroot 間の共有コンテナーパーティションの設定」または「GitOps ZTP を使用した場合の ostree stateroot 間の共有コンテナーパーティションの設定」を参照してください。

シードイメージに含める内容の詳細は、「シードイメージの設定」および「RAN DU プロファイルを使用したシードイメージの設定」を参照してください。

関連情報

15.1.2.4. OADP バックアップおよび復元ガイドライン

OADP Operator を使用すると、ConfigMap オブジェクトにラップされた Backup および Restore CR を使用して、ターゲットクラスター上のアプリケーションをバックアップおよび復元できます。アプリケーションは、アップグレード後に復元できるように、OpenShift Container Platform の現行バージョンとターゲットバージョンで動作する必要があります。バックアップには、最初に作成されたリソースが含まれている必要があります。

次のリソースはバックアップから除外する必要があります。

  • pods
  • endpoints
  • controllerrevision
  • podmetrics
  • packagemanifest
  • replicaset
  • localvolume (Local Storage Operator (LSO) を使用する場合)

シングルノード OpenShift には 2 つのローカルストレージ実装があります。

Local Storage Operator (LSO)
Lifecycle Agent は、localvolume リソースとそれに関連付けられた StorageClass リソースを含む、必要なアーティファクトを自動的にバックアップおよび復元します。アプリケーション Backup CR で persistentvolumes リソースを除外する必要があります。
LVM Storage
LVM Storage アーティファクトの Backup および Restore CR を作成する必要があります。アプリケーション Backup CR に persistentVolumes リソースを含める必要があります。

イメージベースアップグレードの場合、特定のターゲットクラスターでは 1 つの Operator のみがサポートされます。

重要

両方の Operator の場合、ImageBasedUpgrade CR を介して Operator CR を追加のマニフェストとして適用しないでください。

永続ボリュームの内容は保存され、ピボット後も使用されます。DataProtectionApplication CR を設定するときは、イメージベースアップグレード用に .spec.configuration.restic.enable が false に設定されていることを確認する必要があります。これにより、Container Storage Interface の統合が無効になります。

15.1.2.4.1. lca.openshift.io/apply-wave ガイドライン

lca.openshift.io/apply-wave アノテーションは、Backup or Restore CR の適用順序を決定します。アノテーションの値は文字列数値である必要があります。Backup CR または Restore CR で lca.openshift.io/apply-wave アノテーションを定義すると、アノテーションの値に基づいて昇順に適用されます。アノテーションを定義しない場合は、それらが一緒に適用されます。

lca.openshift.io/apply-wave アノテーションは、プラットフォームの Restore CR (RHACM や LVM Storage アーティファクトなど) では、アプリケーションのアノテーションよりも数値的に低くする必要があります。これにより、アプリケーションの前にプラットフォームアーティファクトが復元されます。

アプリケーションにクラスタースコープのリソースが含まれている場合は、バックアップの範囲をアプリケーションによって作成された特定のクラスタースコープのリソースに設定するために、個別の Backup CR と Restore CR を作成する必要があります。クラスタースコープのリソースの Restore CR は、残りのアプリケーションの Restore CR の前に復元する必要があります。

15.1.2.4.2. lca.openshift.io/apply-label ガイドライン

lca.openshift.io/apply-label アノテーションを使用して、特定のリソースのみをバックアップできます。アノテーションで定義したリソースに基づいて、Lifecycle Agent は、Backup CR の作成時に、指定されたリソースに lca.openshift.io/backup: <backup_name> ラベルを適用し、labelSelector.matchLabels.lca.openshift.io/backup: <backup_name> ラベルセレクターを追加します。

特定のリソースをバックアップするために lca.openshift.io/apply-label アノテーションを使用するには、アノテーションにリストされているリソースも spec セクションに含める必要があります。lca.openshift.io/apply-label アノテーションが Backup CR で使用される場合、spec セクションで他のリソースタイプが指定されているかどうかに関係なく、アノテーションにリストされているリソースのみがバックアップされます。

CR の例:

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: acm-klusterlet
  namespace: openshift-adp
  annotations:
    lca.openshift.io/apply-label: rbac.authorization.k8s.io/v1/clusterroles/klusterlet,apps/v1/deployments/open-cluster-management-agent/klusterlet 1
  labels:
    velero.io/storage-location: default
spec:
  includedNamespaces:
   - open-cluster-management-agent
  includedClusterScopedResources:
   - clusterroles
  includedNamespaceScopedResources:
   - deployments

1
値は、クラスタースコープのリソースの場合は group/version/resource/name 形式、namespace スコープのリソースの場合は group/version/resource/namespace/name 形式のコンマ区切りのオブジェクトのリストである必要があり、関連する Backup CR にアタッチされている必要があります。

15.1.2.5. 追加のマニフェストガイドライン

Lifecycle Agent は、新しい stateroot デプロイメントで再起動した後、そしてアプリケーションアーティファクトを復元する前に、追加のマニフェストを使用してターゲットクラスターを復元します。

デプロイメント方法が異なると、追加のマニフェストを適用する方法も異なります。

GitOps ZTP

lca.openshift.io/target-ocp-version: <target_ocp_version> ラベルを使用して、ピボット後に Lifecycle Agent が抽出および適用する必要がある追加のマニフェストをマークします。ImageBasedUpgrade CR の lca.openshift.io/target-ocp-version-manifest-count アノテーションを使用して、lca.openshift.io/target-ocp-version のラベルが付けられたマニフェストの数を指定できます。指定されている場合、Lifecycle Agent は、Prep ステージと Upgrade ステージで、ポリシーから抽出されたマニフェストの数がアノテーションで指定された数と一致することを確認します。

lca.openshift.io/target-ocp-version-manifest-count アノテーションの例

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  annotations:
    lca.openshift.io/target-ocp-version-manifest-count: "5"
  name: upgrade

非 Gitops
適用順序を決定するには、追加のマニフェストを lca.openshift.io/apply-wave アノテーションでマークします。ラベル付けされた追加マニフェストは ConfigMap オブジェクトにラップされ、ピボット後に Lifecycle Agent が使用する ImageBasedUpgrade CR で参照されます。

ターゲットクラスターがカスタムカタログソースを使用する場合は、正しいリリースバージョンを指す追加のマニフェストとしてそれらを含める必要があります。

重要

以下の項目を追加マニフェストとして適用することはできません。

  • MachineConfig オブジェクト
  • OLM Operator サブスクリプション

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.