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

16.4. GitOps ZTP を使用したシングルノード OpenShift クラスターのイメージベースアップグレードの実行

ハブクラスター上の 1 つのリソース、ImageBasedGroupUpgrade カスタムリソース (CR) を使用して、すべてのステージを通じて、選択したマネージドクラスターのグループでイメージベースのアップグレードを管理できます。Topology Aware Lifecycle Manager (TALM) は、ImageBasedGroupUpgrade CR を調整し、手動制御のアップグレードフローまたは完全に自動のアップグレードフローにより、定められたステージ遷移を完了するための基盤リソースを作成します。

イメージベースのアップグレードの詳細は、「シングルノード OpenShift クラスターのイメージベースのアップグレードについて」を参照してください。

ImageBasedGroupUpgrade CR は、ImageBasedUpgrade API と ClusterGroupUpgrade API を組み合わせたものです。たとえば、ImageBasedGroupUpgrade API でも、ClusterGroupUpgrade API と同じ方法で、クラスターの選択とロールアウトストラテジーを定義できます。ステージ遷移は ImageBasedUpgrade API とは異なります。ImageBasedGroupUpgrade API を使用すると、アクションとも呼ばれる複数のステージ遷移を、1 つのロールアウトストラテジーを共有する 1 つのステップに組み合わせることができます。

ImageBasedGroupUpgrade.yaml の例

apiVersion: lcm.openshift.io/v1alpha1
kind: ImageBasedGroupUpgrade
metadata:
  name: <filename>
  namespace: default
spec:
  clusterLabelSelectors:
1 

    - matchExpressions:
      - key: name
        operator: In
        values:
        - spoke1
        - spoke4
        - spoke6
  ibuSpec:
    seedImageRef:
2 

      image: quay.io/seed/image:4.20.0-rc.1
      version: 4.20.0-rc.1
      pullSecretRef:
        name: "<seed_pull_secret>"
    extraManifests:
3 

      - name: example-extra-manifests
        namespace: openshift-lifecycle-agent
    oadpContent:
4 

      - name: oadp-cm
        namespace: openshift-adp
  plan:
5 

    - actions: ["Prep", "Upgrade", "FinalizeUpgrade"]
      rolloutStrategy:
        maxConcurrency: 200
6 

        timeout: 2400
7

1
アップグレードするクラスター。
2
ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。
注記

ハブクラスターの ImageBasedGroupUpgrade リソースと同じ namespace にシードイメージプルシークレットを追加すると、そのシークレットが Prep ステージのマニフェストリストに追加されます。シークレットは、openshift-lifecycle-agent namespace 内の各スポーククラスターで再作成されます。

3
オプション: シードイメージに含まれていない追加のマニフェストをターゲットクラスターに適用します。カスタムカタログソースの ConfigMap オブジェクトも適用します。
4
OADP の Backup および Restore CR を含む ConfigMap リソース。
5
アップグレードプランの詳細。
6
バッチで更新するクラスターの数。
7
アクションを完了するまでのタイムアウト制限 (分単位)。

16.4.1.1. サポートされているアクションの組み合わせ
リンクのコピー

アクションは、選択されたクラスターグループのアップグレードプランの各ステップで TALM が実行する一連のステージ遷移です。ImageBasedGroupUpgrade CR 内の action エントリーは、それぞれ個別のステップです。1 つのステップに、同じロールアウトストラテジーを共有する 1 つ以上のアクションを含めます。アクションをステップに分けることで、各アクションのロールアウトストラテジーをより細かく制御できます。

これらのアクションは、アップグレードプラン内でさまざまな方法で組み合わせることができます。後続のステップは、後で追加することができます。プランにステップを追加する前に、前のステップが完了するか失敗するまで待機します。前のステップで失敗したクラスターに対して追加するステップの最初のアクションは、Abort または Rollback のどちらかである必要があります。

重要

進行中のプランからアクションまたはステップを削除することはできません。

次の表にプランの例を示します。それぞれの例で、ロールアウトストラテジーに対する制御レベルが異なります。

Expand
表16.5 アップグレードプランの例
プランの例説明
plan:
- actions: ["Prep", "Upgrade", "FinalizeUpgrade"]
  rolloutStrategy:
    maxConcurrency: 200
    timeout: 60

すべてのアクションが同じストラテジーを共有しています。 

plan:
- actions: ["Prep", "Upgrade"]
  rolloutStrategy:
    maxConcurrency: 200
    timeout: 60
- actions: ["FinalizeUpgrade"]
  rolloutStrategy:
    maxConcurrency: 500
    timeout: 10

いくつかのアクションが同じストラテジーを共有しています。 

plan:
- actions: ["Prep"]
  rolloutStrategy:
    maxConcurrency: 200
    timeout: 60
- actions: ["Upgrade"]
  rolloutStrategy:
    maxConcurrency: 200
    timeout: 20
- actions: ["FinalizeUpgrade"]
  rolloutStrategy:
    maxConcurrency: 500
    timeout: 10

すべてのアクションに異なるストラテジーがあります。

重要

クラスターは、いずれかのアクションに失敗すると、同じステップの残りのアクションをスキップします。

ImageBasedGroupUpgrade API は次のアクションを受け入れます。

Prep
Prep ステージに進み、アップグレードリソースの準備を開始します。
Upgrade
Upgrade ステージに移行して、アップグレードを開始します。
FinalizeUpgrade
Idle ステージに移行して、Upgrade アクションを完了した特定のクラスターのアップグレードを確定します。
Rollback
Rollback ステージに移行して、正常にアップグレードされたクラスターでのみロールバックを開始します。
FinalizeRollback
Idle ステージに移行して、ロールバックを完了します。
AbortOnFailure
Idle ステージに移行して、Prep または Upgrade アクションに失敗した特定のクラスターのアップグレードをキャンセルします。
Abort
Idle ステージに移行して、まだアップグレードされていないクラスターでのみ、進行中のアップグレードをキャンセルします。

次のアクションの組み合わせがサポートされています。角括弧のペアは、plan セクションの 1 つのステップを表します。

  • ["Prep"]、["Abort"]
  • ["Prep", "Upgrade", "FinalizeUpgrade"]
  • ["Prep"]、["AbortOnFailure"]、["Upgrade"]、["AbortOnFailure"]、["FinalizeUpgrade"]
  • ["Rollback", "FinalizeRollback"]

完全に新しい ImageBasedGroupUpgrade CR から進行中のアップグレードを再開またはキャンセルする必要がある場合は、次のいずれかの組み合わせを使用します。

  • ["Upgrade","FinalizeUpgrade"]
  • ["FinalizeUpgrade"]
  • ["FinalizeRollback"]
  • ["Abort"]
  • ["AbortOnFailure"]

16.4.1.2. クラスター選択のためのラベル付け
リンクのコピー

最初のクラスターの選択には、spec.clusterLabelSelectors フィールドを使用します。さらに、TALM が、最後のステージ遷移の結果に応じて、マネージドクラスターにラベルを付けます。

ステージが完了または失敗すると、関連するクラスターに TALM が次のラベルを付けます。

  • lcm.openshift.io/ibgu-<stage>-completed
  • lcm.openshift.io/ibgu-<stage>-failed

これらのクラスターラベルは、発生した問題をトラブルシューティングした後、クラスターのグループのアップグレードをキャンセルまたはロールバックするために使用します。

重要

ImageBasedGroupUpgrade CR を使用してクラスターをアップグレードする場合は、マネージドクラスターでトラブルシューティングまたは復元手順を実行した後、lcm.openshift.io/ibgu-<stage>-completed または lcm.openshift.io/ibgu-<stage>-failed クラスターラベルが適切に更新されていることを確認してください。これにより、TALM がクラスターのイメージベースのアップグレードを引き続き管理できるようになります。

たとえば、アップグレードが正常に完了したクラスターを除くすべてのマネージドクラスターのアップグレードをキャンセルする場合は、プランに Abort アクションを追加できます。Abort アクションは、ImageBasedUpgrade CR を Idle ステージに戻し、まだアップグレードされていないクラスターのアップグレードをキャンセルします。個別の Abort アクションを追加すると、TALM が lcm.openshift.io/ibgu-upgrade-completed ラベルを持つクラスターに対して Abort アクションを実行しなくなります。

アップグレードが正常にキャンセルされるか完了すると、クラスターラベルが削除されます。

16.4.1.3. ステータスの監視
リンクのコピー

ImageBasedGroupUpgrade CR は、すべてのクラスターの包括的なステータスレポートを 1 カ所に集約し、より優れた監視エクスペリエンスを実現します。監視できるアクションは次のとおりです。

status.clusters.completedActions
plan セクションで定義されている完了したすべてのアクションを表示します。
status.clusters.currentAction
現在進行中のすべてのアクションを表示します。
status.clusters.failedActions
詳細なエラーメッセージとともに、失敗したすべてのアクションを表示します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る