検索

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

download PDF

GitOps Zero Touch Provisioning (ZTP) を介したイメージベースアップグレードにより、シングルノード OpenShift マネージドクラスターをアップグレードできます。

クラスターに Lifecycle Agent をデプロイすると、ImageBasedUpgrade CR が自動的に作成されます。この CR を更新して、シードイメージのイメージリポジトリーを指定し、さまざまなステージを移動します。

15.4.1. Lifecycle Agent と GitOps ZTP を使用したイメージベースアップグレードの Prep ステージへの移行

クラスターに Lifecycle Agent をデプロイすると、ImageBasedUpgrade CR が自動的に作成されます。この CR を更新して、シードイメージのイメージリポジトリーを指定し、さまざまなステージを移動します。

ztp-site-generate コンテナー内の ImageBasedUpgrade CR

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle

前提条件

  • イメージベースアップグレードで使用されるリソースのポリシーと ConfigMap オブジェクトを作成している。詳細は、「GitOps ZTP を使用したイメージベースアップグレード用の ConfigMap オブジェクトの作成」を参照してください。

手順

  1. ibu-upgrade-ranGen.yaml という既存の PolicyGenTemplate グループに、PrepUpgradeIdle の各ステージのポリシーを追加します。

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: example-group-ibu
      namespace: "ztp-group"
    spec:
      bindingRules:
        group-du-sno: ""
      mcp: "master"
      evaluationInterval: 1
        compliant: 10s
        noncompliant: 10s
      sourceFiles:
        - fileName: ConfigMapGeneric.yaml
          complianceType: mustonlyhave
          policyName: "oadp-cm-policy"
          metadata:
            name: oadp-cm
            namespace: openshift-adp
        - fileName: ibu/ImageBasedUpgrade.yaml
          policyName: "prep-stage-policy"
          spec:
            stage: Prep
            seedImageRef: 2
              version: "4.15.0"
              image: "quay.io/user/lca-seed:4.15.0"
              pullSecretRef:
                name: "<seed_pull_secret>"
            oadpContent: 3
            - name: "oadp-cm"
              namespace: "openshift-adp"
          status:
            conditions:
              - reason: Completed
                status: "True"
                type: PrepCompleted
                message: "Prep stage completed successfully"
        - fileName: ibu/ImageBasedUpgrade.yaml
          policyName: "upgrade-stage-policy"
          spec:
            stage: Upgrade
          status:
            conditions:
              - reason: Completed
                status: "True"
                type: UpgradeCompleted
        - fileName: ibu/ImageBasedUpgrade.yaml
          policyName: "finalize-stage-policy"
          complianceType: mustonlyhave
          spec:
            stage: Idle
        - fileName: ibu/ImageBasedUpgrade.yaml
          policyName: "finalize-stage-policy"
          status:
            conditions:
              - reason: Idle
                status: "True"
                type: Idle
    1
    準拠ポリシーと非準拠ポリシーのポリシー評価間隔。ポリシーのステータスが現在のアップグレードステータスを正確に反映するように、これらを 10s に設定します。
    2
    Prep ステージで、アップグレード用のシードイメージ、OpenShift Container Platform バージョン、プルシークレットを定義します。
    3
    バックアップと復元に必要な OADP ConfigMap リソースを定義します。
  2. 次のコマンドを実行して、イメージベースアップグレードに必要なポリシーが作成されていることを確認します。

    $ oc get policies -n spoke1 | grep -E "example-group-ibu"

    出力例

    ztp-group.example-group-ibu-oadp-cm-policy             inform               NonCompliant          31h
    ztp-group.example-group-ibu-prep-stage-policy          inform               NonCompliant          31h
    ztp-group.example-group-ibu-upgrade-stage-policy       inform               NonCompliant          31h
    ztp-group.example-group-ibu-finalize-stage-policy      inform               NonCompliant          31h
    ztp-group.example-group-ibu-rollback-stage-policy      inform               NonCompliant          31h

  3. du-profile クラスターラベルを、ターゲットプラットフォームバージョンまたは SiteConfig CR 内の対応するポリシーバインディングラベルに更新します。

    apiVersion: ran.openshift.io/v1
    kind: SiteConfig
    [...]
    spec:
      [...]
        clusterLabels:
          du-profile: "4.15.0"
    重要

    ラベルをターゲットプラットフォームバージョンに更新すると、既存のポリシーセットがバインド解除されます。

  4. 更新された SiteConfig CR をコミットして Git リポジトリーにプッシュします。
  5. Prep ステージに移行する準備ができたら、Prep および OADP ConfigMap ポリシーを使用して、ターゲットハブクラスターに ClusterGroupUpgrade CR を作成します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-ibu-prep
      namespace: default
    spec:
      clusters:
      - spoke1
      enable: true
      managedPolicies:
      - example-group-ibu-oadp-cm-policy
      - example-group-ibu-prep-stage-policy
      remediationStrategy:
        canaries:
          - spoke1
        maxConcurrency: 1
        timeout: 240
  6. 以下のコマンドを実行して Prep ポリシーを適用します。

    $ oc apply -f cgu-ibu-prep.yml

    OADP リソースと追加のマニフェストの ConfigMap オブジェクトを指定すると、Lifecycle Agent は Prep ステージで指定された ConfigMap オブジェクトを検証します。以下の問題が発生する可能性があります。

    • Lifecycle Agent が extraManifests に問題を検出した場合の検証警告またはエラー
    • Lifecycle Agent が oadpContent に問題を検出した場合の検証エラー

    検証警告は Upgrade ステージをブロックしませんが、アップグレードを続行しても安全かどうかを判断する必要があります。これらの警告 (CRD の欠落、namespace の欠落、またはドライランの失敗など) は、警告に関する詳細で Prep ステージの status.conditionsImageBasedUpgrade CR の annotation フィールドを更新します。

    検証警告の例

    [...]
    metadata:
    annotations:
      extra-manifest.lca.openshift.io/validation-warning: '...'
    [...]

    ただし、MachineConfig または Operator マニフェストを追加マニフェストに追加するなどの検証エラーが発生すると、Prep ステージが失敗し、Upgrade ステージがブロックされます。

    検証に合格すると、クラスターは新しい ostree stateroot を作成します。これには、シードイメージのプルと展開、およびホストレベルのコマンドの実行が含まれます。最後に、必要なすべてのイメージがターゲットクラスターに事前キャッシュされます。

  7. 次のコマンドを実行して、ステータスを監視し、cgu-ibu-prep ClusterGroupUpgradeCompleted を報告するまで待ちます。

    $ oc get cgu -n default

    出力例

    NAME                    AGE   STATE       DETAILS
    cgu-ibu-prep            31h   Completed   All clusters are compliant with all the managed policies

15.4.2. Lifecycle Agent と GitOps ZTP を使用したイメージベースアップグレードの Upgrade ステージへの移行

Prep ステージが完了したら、ターゲットクラスターをアップグレードできます。アップグレードプロセス中に、OADP Operator は OADP CR で指定されたアーティファクトのバックアップを作成し、その後、Lifecycle Agent がクラスターをアップグレードします。

アップグレードが失敗または停止した場合は、自動ロールバックが開始されます。アップグレード後に問題が発生した場合は、手動でロールバックを開始できます。手動ロールバックの詳細は、「(オプション) Lifecycle Agent と GitOps ZTP を使用したロールバックの開始」を参照してください。

前提条件

  • Prep ステージを完了している。

手順

  1. Upgrade ステージに移行する準備ができたら、Upgrade ポリシーを参照するターゲットハブクラスターに ClusterGroupUpgrade CR を作成します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-ibu-upgrade
      namespace: default
    spec:
      actions:
        beforeEnable:
          addClusterAnnotations:
            import.open-cluster-management.io/disable-auto-import: "true" 1
        afterCompletion:
          removeClusterAnnotations:
          - import.open-cluster-management.io/disable-auto-import 2
      clusters:
      - spoke1
      enable: true
      managedPolicies:
      - example-group-ibu-upgrade-stage-policy
      remediationStrategy:
        canaries:
          - spoke1
        maxConcurrency: 1
        timeout: 240
    1
    アップグレードを開始する前に、マネージドクラスターに disable-auto-import アノテーションを適用します。このアノテーションにより、クラスターの準備が整うまで、アップグレード段階でマネージドクラスターの自動インポートが無効になります。
    2
    アップグレードが完了したら、disable-auto-import アノテーションを削除します。
  2. 次のコマンドを実行して Upgrade ポリシーを適用します。

    $ oc apply -f cgu-ibu-upgrade.yml
  3. 次のコマンドを実行してステータスを監視し、cgu-ibu-upgrade ClusterGroupUpgradeCompleted を報告するまで待ちます。

    $ oc get cgu -n default

    出力例

    NAME                              AGE   STATE       DETAILS
    cgu-ibu-prep                      31h   Completed   All clusters are compliant with all the managed policies
    cgu-ibu-upgrade                   31h   Completed   All clusters are compliant with all the managed policies

  4. 正常に変更され、アップグレードを終了する準備ができたら、アップグレードを終了するポリシーを参照するターゲットハブクラスターに ClusterGroupUpgrade CR を作成します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-ibu-finalize
      namespace: default
    spec:
      actions:
        beforeEnable:
          removeClusterAnnotations:
          - import.open-cluster-management.io/disable-auto-import
      clusters:
      - spoke1
      enable: true
      managedPolicies:
      - example-group-ibu-finalize-stage-policy
      remediationStrategy:
        canaries:
          - spoke1
        maxConcurrency: 1
        timeout: 240
    重要

    他の ClusterGroupUpgrade CR が進行中でないことを確認してください。進行中の場合、TALM がそれらを継続的に調整することになります。cgu-ibu-finalize.yaml を適用する前に、すべての "In-Progress" ClusterGroupUpgrade CR を削除します。

  5. 以下のコマンドを実行してポリシーを適用します。

    $ oc apply -f cgu-ibu-finalize.yaml
  6. 次のコマンドを実行して、ステータスを監視し、cgu-ibu-finalize ClusterGroupUpgradeCompleted になるまで待ちます。

    $ oc get cgu -n default

    出力例

    NAME                    AGE   STATE       DETAILS
    cgu-ibu-finalize        30h   Completed   All clusters are compliant with all the managed policies
    cgu-ibu-prep            31h   Completed   All clusters are compliant with all the managed policies
    cgu-ibu-upgrade         31h   Completed   All clusters are compliant with all the managed policies

  7. アップグレードが成功したら、OADP Operator とその設定ファイルを削除できます。

    1. common-ranGen.yaml ファイル内の OADP Operator namespace、Operator グループ、およびサブスクリプションの complianceTypemustnothave に変更します。

      [...]
      - fileName: OadpSubscriptionNS.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
      - fileName: OadpSubscriptionOperGroup.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
      - fileName: OadpSubscription.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
      - fileName: OadpOperatorStatus.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
      [...]
    2. サイトの PolicyGenTemplate ファイルで、OADP Operator namespace、Operator グループ、およびサブスクリプションの complianceTypemustnothave に変更します。

      - fileName: OadpSecret.yaml
        policyName: "config-policy"
        complianceType: mustnothave
      - fileName: OadpBackupStorageLocationStatus.yaml
        policyName: "config-policy"
        complianceType: mustnothave
      - fileName: DataProtectionApplication.yaml
        policyName: "config-policy"
        complianceType: mustnothave
    3. 変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。common-subscriptions-policy ポリシーと example-cnf-config-policy ポリシーのステータスが Non-Compliant に変わります。
    4. Topology Aware Lifecycle Manager を使用して、ターゲットクラスターに変更を適用します。設定変更のロールアウトの詳細は、「マネージドクラスターでのポリシーの更新」を参照してください。
    5. プロセスを監視します。ターゲットクラスターの common-subscriptions-policy ポリシーと example-cnf-config-policy ポリシーのステータスが Compliant の場合、OADP Operator はクラスターから削除されています。次のコマンドを実行して、ポリシーのステータスを取得します。

      $ oc get policy -n ztp-common common-subscriptions-policy
      $ oc get policy -n ztp-site example-cnf-config-policy
    6. common-ranGen.yaml およびサイト PolicyGenTemplate ファイルの spec.sourceFiles から、OADP Operator namespace、Operator グループとサブスクリプション、および設定 CR を削除します。
    7. 変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。ポリシーは準拠したままです。

15.4.3. Lifecycle Agent と GitOps ZTP を使用したイメージベースアップグレードの Rollback ステージへの移行

アップグレード後に問題が発生した場合は、手動でロールバックを開始できます。

前提条件

  • 元の stateroot 上のコントロールプレーン証明書が有効である。証明書の有効期限が切れている場合は、「コントロールプレーン証明書の期限切れの状態からのリカバリー」を参照してください。

手順

  1. du-profile または対応するポリシーバインディングラベルを、SiteConfig CR の元のプラットフォームバージョンに戻します。

    apiVersion: ran.openshift.io/v1
    kind: SiteConfig
    [...]
    spec:
      [...]
        clusterLabels:
          du-profile: "4.14.x"
  2. ロールバックを開始する準備ができたら、既存の PolicyGenTemplate CR グループに Rollback ポリシーを追加します。

    [...]
    - fileName: ibu/ImageBasedUpgrade.yaml
      policyName: "rollback-stage-policy"
      spec:
        stage: Rollback
      status:
        conditions:
          - message: Rollback completed
            reason: Completed
            status: "True"
            type: RollbackCompleted
  3. Rollback ポリシーを参照するターゲットハブクラスターに ClusterGroupUpgrade CR を作成します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-ibu-rollback
      namespace: default
    spec:
      actions:
        beforeEnable:
          removeClusterAnnotations:
          - import.open-cluster-management.io/disable-auto-import
      clusters:
      - spoke1
      enable: true
      managedPolicies:
      - example-group-ibu-rollback-stage-policy
      remediationStrategy:
        canaries:
          - spoke1
        maxConcurrency: 1
        timeout: 240
  4. 次のコマンドを実行して、Rollback ポリシーを適用します。

    $ oc apply -f cgu-ibu-rollback.yml
  5. 正常に変更され、ロールバックを終了する準備ができたら、ロールバックを終了するポリシーを参照するターゲットハブクラスターに ClusterGroupUpgrade CR を作成します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-ibu-finalize
      namespace: default
    spec:
      actions:
        beforeEnable:
          removeClusterAnnotations:
          - import.open-cluster-management.io/disable-auto-import
      clusters:
      - spoke1
      enable: true
      managedPolicies:
      - example-group-ibu-finalize-stage-policy
      remediationStrategy:
        canaries:
          - spoke1
        maxConcurrency: 1
        timeout: 240
  6. 以下のコマンドを実行してポリシーを適用します。

    $ oc apply -f cgu-ibu-finalize.yml

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

イメージベースアップグレード中に問題が発生する可能性があります。

15.4.4.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.4.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.4.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.4.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.4.3. LVM Storage ボリュームの内容が復元されない

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

15.4.4.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.4.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.4.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.