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


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

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

15.4.1. ハブ上の ImageBasedGroupUpgrade CR を使用してイメージベースのアップグレードを大規模に管理する

ImageBasedGroupUpgrade CR は、ImageBasedUpgrade APIClusterGroupUpgrade 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.17.0-rc.1
      version: 4.17.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
ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。
3
オプション: シードイメージに含まれていない追加のマニフェストをターゲットクラスターに適用します。カスタムカタログソースの ConfigMap オブジェクトも適用します。
4
OADP の Backup および Restore CR を含む ConfigMap リソース。
5
アップグレードプランの詳細。
6
バッチで更新するクラスターの数。
7
アクションを完了するまでのタイムアウト制限 (分単位)。

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

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

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

重要

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

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

表15.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"]

15.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 アクションを実行しなくなります。

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

15.4.1.3. ステータスの監視

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

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

15.4.2. 複数のステップでマネージドクラスターのイメージベースのアップグレードを大規模に実行する

アップグレードによってサービスが中断されるタイミングを適切に制御する必要があるユースケースの場合は、ImageBasedGroupUpgrade CR を使用し、前のステップが完了した後にアクションを追加することで、マネージドクラスターのセットをアップグレードできます。前のステップの結果を評価した後、次のアップグレードステージに進むことも、手順全体の失敗したステップをトラブルシューティングすることもできます。

重要

特定のアクションの組み合わせのみがサポートされています。これは サポートされているアクションの組み合わせ に記載されています。

前提条件

  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • イメージベースのアップグレードで使用するリソースのポリシーと ConfigMap オブジェクトを作成した。
  • ハブクラスターを介して、すべてのマネージドクラスターに Lifecycle Agent と OADP Operator をインストールした。

手順

  1. ハブクラスターで、ImageBasedGroupUpgrade CR を含む 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.16.0-rc.1
          version: 4.16.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"]
        rolloutStrategy:
          maxConcurrency: 2
          timeout: 2400
    1
    アップグレードするクラスター。
    2
    ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。
    3
    オプション: シードイメージに含まれていない追加のマニフェストをターゲットクラスターに適用します。カスタムカタログソースの ConfigMap オブジェクトも適用します。
    4
    OADP の Backup および Restore CR を含む ConfigMap リソースのリスト。
    5
    アップグレードプランの詳細。
  2. ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。

    $ oc apply -f <filename>.yaml
  3. ハブクラスターで次のコマンドを実行して、ステータスの更新を監視します。

    $ oc get ibgu -o yaml

    出力例

    # ...
    status:
      clusters:
      - completedActions:
        - action: Prep
        name: spoke1
      - completedActions:
        - action: Prep
        name: spoke4
      - failedActions:
        - action: Prep
        name: spoke6
    # ...

    上記のサンプルプランの出力は、始めは Prep ステージだけです。前のステップの結果に基づいて、このプランにアクションを追加してください。TALM により、アップグレードが成功したか失敗したかを示すラベルがクラスターに追加されます。たとえば、Prep ステージに失敗したクラスターには、lcm.openshift.io/ibgu-prep-failed が適用されます。

    失敗を調査した後、アップグレードプランに AbortOnFailure ステップを追加できます。このステップにより、lcm.openshift.io/ibgu-<action>-failed というラベルの付いたクラスターが Idle ステージに戻されます。選択されたクラスターのアップグレードに関連するリソースがすべて削除されます。

  4. オプション: 次のコマンドを実行して、既存の ImageBasedGroupUpgrade CR に AbortOnFailure アクションを追加します。

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
    1. 次のコマンドを実行して、ステータスの更新の監視を継続します。

      $ oc get ibgu -o yaml
  5. 次のコマンドを実行して、既存の ImageBasedGroupUpgrade CR にアクションを追加します。

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
  6. オプション: 次のコマンドを実行して、既存の ImageBasedGroupUpgrade CR に AbortOnFailure アクションを追加します。

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
    1. 次のコマンドを実行して、ステータスの更新の監視を継続します。

      $ oc get ibgu -o yaml
  7. 次のコマンドを実行して、既存の ImageBasedGroupUpgrade CR にアクションを追加します。

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["FinalizeUpgrade"], "rolloutStrategy": {"maxConcurrency": 10, "timeout": 3}}}]'

検証

  • 次のコマンドを実行してステータスの更新を監視します。

    $ oc get ibgu -o yaml

    出力例

    # ...
    status:
      clusters:
      - completedActions:
        - action: Prep
        - action: AbortOnFailure
        failedActions:
        - action: Upgrade
        name: spoke1
      - completedActions:
        - action: Prep
        - action: Upgrade
        - action: FinalizeUpgrade
        name: spoke4
      - completedActions:
        - action: AbortOnFailure
        failedActions:
        - action: Prep
        name: spoke6
    # ...

15.4.3. 1 つのステップでマネージドクラスターのイメージベースのアップグレードを大規模に実行する

サービスの中断が問題にならないユースケースの場合は、ImageBasedGroupUpgrade CR を使用し、1 つのロールアウトストラテジーによって複数のアクションを 1 つのステップに組み合わせることで、マネージドクラスターのセットをアップグレードできます。ロールアウトストラテジーを 1 つにすると、アップグレード時間を短縮できます。ただし、アップグレードプランが完了した後でないと、失敗したクラスターのトラブルシューティングを行うことができません。

前提条件

  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • イメージベースのアップグレードで使用するリソースのポリシーと ConfigMap オブジェクトを作成した。
  • ハブクラスターを介して、すべてのマネージドクラスターに Lifecycle Agent と OADP Operator をインストールした。

手順

  1. ハブクラスターで、ImageBasedGroupUpgrade CR を含む 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.17.0-rc.1
          version: 4.17.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
    ターゲットプラットフォームのバージョン、使用するシードイメージ、およびイメージにアクセスするために必要なシークレット。
    3
    オプション: シードイメージに含まれていない追加のマニフェストをターゲットクラスターに適用します。カスタムカタログソースの ConfigMap オブジェクトも適用します。
    4
    OADP の Backup および Restore CR を含む ConfigMap リソース。
    5
    アップグレードプランの詳細。
    6
    バッチで更新するクラスターの数。
    7
    アクションを完了するまでのタイムアウト制限 (分単位)。
  2. ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。

    $ oc apply -f <filename>.yaml

検証

  • 次のコマンドを実行してステータスの更新を監視します。

    $ oc get ibgu -o yaml

    出力例

    # ...
    status:
      clusters:
      - completedActions:
        - action: Prep
        failedActions:
        - action: Upgrade
        name: spoke1
      - completedActions:
        - action: Prep
        - action: Upgrade
        - action: FinalizeUpgrade
        name: spoke4
      - failedActions:
        - action: Prep
        name: spoke6
    # ...

15.4.4. マネージドクラスターのイメージベースのアップグレードを大規模にキャンセルする

Prep ステージを完了したマネージドクラスターのセットのアップグレードをキャンセルできます。

重要

特定のアクションの組み合わせのみがサポートされています。これは サポートされているアクションの組み合わせ に記載されています。

前提条件

  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。

手順

  1. ハブクラスターで、ImageBasedGroupUpgrade CR を含む別の YAML ファイルを作成します。

    apiVersion: lcm.openshift.io/v1alpha1
    kind: ImageBasedGroupUpgrade
    metadata:
      name: <filename>
      namespace: default
    spec:
      clusterLabelSelectors:
      - matchExpressions:
        - key: name
          operator: In
          values:
          - spoke4
      ibuSpec:
        seedImageRef:
          image: quay.io/seed/image:4.16.0-rc.1
          version: 4.16.0-rc.1
          pullSecretRef:
            name: "<seed_pull_secret>"
      extraManifests:
        - name: example-extra-manifests
          namespace: openshift-lifecycle-agent
      oadpContent:
        - name: oadp-cm
          namespace: openshift-adp
      plan:
      - actions: ["Abort"]
        rolloutStrategy:
          maxConcurrency: 5
          timeout: 10

    Prep ステージを完了したすべてのマネージドクラスターが、Idle ステージに戻ります。

  2. ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。

    $ oc apply -f <filename>.yaml

検証

  • 次のコマンドを実行してステータスの更新を監視します。

    $ oc get ibgu -o yaml

    出力例

    # ...
    status:
      clusters:
      - completedActions:
        - action: Prep
        currentActions:
        - action: Abort
        name: spoke4
    # ...

15.4.5. マネージドクラスターのイメージベースのアップグレードを大規模にロールバックする

アップグレードが成功した後に解決できない問題が発生した場合は、管理対象クラスターのセットの変更をロールバックします。別の ImageBasedGroupUpgrade CR を作成し、ロールバックするマネージドクラスターのセットを定義する必要があります。

重要

特定のアクションの組み合わせのみがサポートされています。これは サポートされているアクションの組み合わせ に記載されています。

前提条件

  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。

手順

  1. ハブクラスターで、ImageBasedGroupUpgrade CR を含む別の YAML ファイルを作成します。

    apiVersion: lcm.openshift.io/v1alpha1
    kind: ImageBasedGroupUpgrade
    metadata:
      name: <filename>
      namespace: default
    spec:
      clusterLabelSelectors:
      - matchExpressions:
        - key: name
          operator: In
          values:
          - spoke4
      ibuSpec:
        seedImageRef:
          image: quay.io/seed/image:4.17.0-rc.1
          version: 4.17.0-rc.1
          pullSecretRef:
            name: "<seed_pull_secret>"
      extraManifests:
        - name: example-extra-manifests
          namespace: openshift-lifecycle-agent
      oadpContent:
        - name: oadp-cm
          namespace: openshift-adp
      plan:
      - actions: ["Rollback", "FinalizeRollback"]
        rolloutStrategy:
          maxConcurrency: 200
          timeout: 2400
  2. ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。

    $ oc apply -f <filename>.yaml

    定義したラベルに一致するすべてのマネージドクラスターが、Rollback ステージに戻されます。その後 Idle ステージに移行してロールバックが完了します。

検証

  • 次のコマンドを実行してステータスの更新を監視します。

    $ oc get ibgu -o yaml

    出力例

    # ...
    status:
      clusters:
      - completedActions:
        - action: Rollback
        - action: FinalizeRollback
        name: spoke4
    # ...

15.4.6. Lifecycle Agent を使用したイメージベースアップグレードのトラブルシューティング

問題の影響を受けるマネージドクラスターでトラブルシューティング手順を実行します。

重要

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

15.4.6.1. ログの収集

oc adm must-gather CLI を使用して、デバッグとトラブルシューティングのための情報を収集できます。

手順

  • 次のコマンドを実行して、Operator に関するデータを収集します。

    $  oc adm must-gather \
      --dest-dir=must-gather/tmp \
      --image=$(oc -n openshift-lifecycle-agent get deployment.apps/lifecycle-agent-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name == "manager")].image}') \
      --image=quay.io/konveyor/oadp-must-gather:latest \// 1
      --image=quay.io/openshift/origin-must-gather:latest 2
    1
    オプション: OADP Operator からさらに情報を収集する必要がある場合は、このオプションを追加します。
    2
    オプション: SR-IOV Operator からさらに情報を収集する必要がある場合は、このオプションを追加します。

15.4.6.2. AbortFailed または FinalizeFailed エラー

問題

最終ステージの間、または Prep ステージでプロセスを停止すると、Lifecycle Agent は次のリソースをクリーンアップします。

  • 不要になった stateroot
  • リソースの事前キャッシュ
  • OADP CR
  • ImageBasedUpgrade CR

Lifecycle Agent が上記の手順を実行できない場合は、AbortFailed または FinalizeFailed 状態に移行します。条件メッセージとログには、どの手順が失敗したかが表示されます。

エラーメッセージの例

message: failed to delete all the backup CRs. Perform cleanup manually then add 'lca.openshift.io/manual-cleanup-done' annotation to ibu CR to transition back to Idle
      observedGeneration: 5
      reason: AbortFailed
      status: "False"
      type: Idle

解決方法
  1. ログを調べて、失敗が発生した理由を特定します。
  2. Lifecycle Agent にクリーンアップを再試行するように指示するには、ImageBasedUpgrade CR に lca.openshift.io/manual-cleanup-done アノテーションを追加します。

    このアノテーションを確認した後、Lifecycle Agent はクリーンアップを再試行し、成功した場合は ImageBasedUpgrade ステージが Idle に移行します。

    クリーンアップが再度失敗した場合は、リソースを手動でクリーンアップできます。

15.4.6.2.1. 手動での stateroot のクリーンアップ
問題
Lifecycle Agent は Prep ステージで停止し、新しい stateroot をクリーンアップします。アップグレードまたはロールバックが成功した後に終了すると、Lifecycle Agent は古い stateroot をクリーンアップします。この手順が失敗した場合は、ログを調べて失敗の原因を特定することを推奨します。
解決方法
  1. 次のコマンドを実行して、stateroot に既存のデプロイメントがあるか確認します。

    $ ostree admin status
  2. ある場合は、次のコマンドを実行して既存のデプロイメントをクリーンアップします。

    $ ostree admin undeploy <index_of_deployment>
  3. stateroot のすべてのデプロイメントをクリーンアップした後、次のコマンドを実行して stateroot ディレクトリーを消去します。

    警告

    起動されたデプロイメントがこの stateroot にないことを確認します。

    $ stateroot="<stateroot_to_delete>"
    $ unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
15.4.6.2.2. OADP リソースを手動でクリーンアップする
問題
Lifecycle Agent と S3 バックエンド間の接続の問題により、OADP リソースの自動クリーンアップが失敗する可能性があります。接続を復元し、lca.openshift.io/manual-cleanup-done アノテーションを追加することで、Lifecycle Agent はバックアップリソースを正常にクリーンアップできます。
解決方法
  1. 次のコマンドを実行して、バックエンドの接続を確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    出力例

    NAME                          PHASE       LAST VALIDATED   AGE   DEFAULT
    dataprotectionapplication-1   Available   33s              8d    true

  2. すべてのバックアップリソースを削除してから、lca.openshift.io/manual-cleanup-done アノテーションを ImageBasedUpgrade CR に追加します。

15.4.6.3. LVM Storage ボリュームの内容が復元されない

LVM Storage を使用して動的永続ボリュームストレージを提供する場合、LVM Storage が正しく設定されていないと、永続ボリュームの内容が復元されない可能性があります。

15.4.6.3.1. Backup CR に LVM Storage 関連のフィールドがない
問題

Backup CR に、永続ボリュームを復元するために必要なフィールドが欠落している可能性があります。以下を実行すると、アプリケーション Pod 内のイベントをチェックして、この問題が発生しているか確認できます。

$ oc describe pod <your_app_name>

Backup CR に LVM Storage 関連のフィールドがないことを示す出力例

Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  58s (x2 over 66s)  default-scheduler  0/1 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
  Normal   Scheduled         56s                default-scheduler  Successfully assigned default/db-1234 to sno1.example.lab
  Warning  FailedMount       24s (x7 over 55s)  kubelet            MountVolume.SetUp failed for volume "pvc-1234" : rpc error: code = Unknown desc = VolumeID is not found

解決方法

アプリケーション Backup CR に logicalvolumes.topolvm.io を含める必要があります。このリソースがない場合、アプリケーションは永続ボリューム要求と永続ボリュームマニフェストを正しく復元しますが、この永続ボリュームに関連付けられた logicalvolume はピボット後に適切に復元されません。

Backup CR の例

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: small-app
  namespace: openshift-adp
spec:
  includedNamespaces:
  - test
  includedNamespaceScopedResources:
  - secrets
  - persistentvolumeclaims
  - deployments
  - statefulsets
  includedClusterScopedResources: 1
  - persistentVolumes
  - volumesnapshotcontents
  - logicalvolumes.topolvm.io

1
アプリケーションの永続ボリュームを復元するには、このセクションを次のように設定する必要があります。
15.4.6.3.2. Restore CR に LVM Storage 関連のフィールドがない
問題

アプリケーションの予想されるリソースは復元されますが、アップグレード後に永続ボリュームの内容は保持されません。

  1. ピボット前に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。

    $ oc get pv,pvc,logicalvolumes.topolvm.io -A

    ピボット前の出力例

    NAME                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
    persistentvolume/pvc-1234   1Gi        RWO            Retain           Bound    default/pvc-db   lvms-vg1                4h45m
    
    NAMESPACE   NAME                           STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    default     persistentvolumeclaim/pvc-db   Bound    pvc-1234   1Gi        RWO            lvms-vg1       4h45m
    
    NAMESPACE   NAME                                AGE
                logicalvolume.topolvm.io/pvc-1234   4h45m

  2. ピボット後に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。

    $ oc get pv,pvc,logicalvolumes.topolvm.io -A

    ピボット後の出力例

    NAME                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
    persistentvolume/pvc-1234   1Gi        RWO            Delete           Bound    default/pvc-db   lvms-vg1                19s
    
    NAMESPACE   NAME                           STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    default     persistentvolumeclaim/pvc-db   Bound    pvc-1234   1Gi        RWO            lvms-vg1       19s
    
    NAMESPACE   NAME                                AGE
                logicalvolume.topolvm.io/pvc-1234   18s

解決方法

この問題は、logicalvolume ステータスが Restore CR に保存されないことが原因となっています。このステータスは、Velero がピボット後に保持する必要があるボリュームを参照する必要があるため重要です。アプリケーションの Restore CR には、次のフィールドを含める必要があります。

Restore CR の例

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: sample-vote-app
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "3"
spec:
  backupName:
    sample-vote-app
  restorePVs: true 1
  restoreStatus: 2
    includedResources:
      - logicalvolumes

1
アプリケーションの永続ボリュームを保持するには、restorePVstrue に設定する必要があります。
2
アプリケーションの永続ボリュームを保持するには、このセクションを次のように設定する必要があります。

15.4.6.4. 失敗した Backup CR および Restore CR のデバッグ

問題
アーティファクトのバックアップまたは復元に失敗しました。
解決方法

Velero CLI ツールを使用して、Backup および Restore CR をデバッグし、ログを取得できます。Velero CLI ツールは、OpenShift CLI ツールよりも詳細な情報を提供します。

  1. 次のコマンドを実行して、エラーを含む Backup CR を説明します。

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
  2. 次のコマンドを実行して、エラーを含む Restore CR を説明します。

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
  3. 次のコマンドを実行して、バックアップされたリソースをローカルディレクトリーにダウンロードします。

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero backup download -n openshift-adp backup-acm-klusterlet -o ~/backup-acm-klusterlet.tar.gz
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.