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

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

Lifecycle Agent を使用して、シングルノード OpenShift クラスターのイメージベースアップグレードを手動で実行できます。

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

15.3.1. Lifecycle Agent を使用したイメージベースアップグレードの Prep ステージへの移行
リンクのコピー

クラスターに Lifecycle Agent をデプロイすると、ImageBasedUpgrade カスタムリソース (CR) が自動的に作成されます。

アップグレード中に必要なすべてのリソースを作成したら、Prep ステージに進むことができます。詳細は、「Lifecycle Agent を使用したイメージベースアップグレード用の ConfigMap オブジェクトの作成」セクションを参照してください。

注記

非接続環境で、シードクラスターのリリースイメージレジストリーがターゲットクラスターのリリースイメージレジストリーと異なる場合は、ImageDigestMirrorSet (IDMS) リソースを作成して、別のミラーリングされるリポジトリーの場所を設定する必要があります。詳細は、「イメージレジストリーのリポジトリーミラーリングの設定」を参照してください。

次のコマンドを実行すると、シードイメージで使用されているリリースレジストリーを取得できます。 

$ skopeo inspect docker://<imagename> | jq -r '.Labels."com.openshift.lifecycle-agent.seed_cluster_info" | fromjson | .release_registry'
Copy to Clipboard Toggle word wrap

前提条件

  • クラスターをバックアップおよび復元するためのリソースを作成している。

手順

  1. ImageBasedUpgrade CR にパッチが適用されていることを確認します。 

    apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle
  seedImageRef:
    version: 4.15.2
    1 
    
    image: <seed_container_image>
    2 
    
    pullSecretRef: <seed_pull_secret>
    3 
    
  autoRollbackOnFailure: {}
#    initMonitorTimeoutSeconds: 1800
    4 
    
  extraManifests:
    5 
    
  - name: example-extra-manifests-cm
    namespace: openshift-lifecycle-agent
  - name: example-catalogsources-cm
    namespace: openshift-lifecycle-agent
  oadpContent:
    6 
    
  - name: oadp-cm-example
    namespace: openshift-adp
    Copy to Clipboard Toggle word wrap
    1
    ターゲットプラットフォームのバージョンを指定します。値はシードイメージのバージョンと一致する必要があります。
    2
    ターゲットクラスターがシードイメージをプルできるリポジトリーを指定します。
    3
    イメージがプライベートレジストリー内にある場合は、コンテナーイメージをプルするための認証情報を含むシークレットへの参照を指定します。
    4
    (オプション) 最初の再起動後、指定された時間枠内にアップグレードが完了しない場合にロールバックする時間枠を秒単位で指定します。定義されていないか 0 に設定されている場合は、デフォルト値の 1800 秒 (30 分) が使用されます。
    5
    (オプション) アップグレード後に保持するカスタムカタログソースと、シードイメージの一部ではないターゲットクラスターに適用する追加のマニフェストを含む ConfigMap リソースのリストを指定します。
    6
    OADP ConfigMap 情報を含む oadpContent セクションを追加します。

  2. Prep ステージを開始するには、次のコマンドを実行して、ImageBasedUpgrade CR の stage フィールドの値を Prep に変更します。 

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agent
    Copy to Clipboard Toggle word wrap

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

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

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

    検証警告の例

    [...]
metadata:
annotations:
  extra-manifest.lca.openshift.io/validation-warning: '...'
[...]
    Copy to Clipboard Toggle word wrap

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

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

検証

  • 次のコマンドを実行して、ImageBasedUpgrade CR のステータスを確認します。 

    $ oc get ibu -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

      conditions:
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: In progress
    observedGeneration: 13
    reason: InProgress
    status: "False"
    type: Idle
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Prep completed
    observedGeneration: 13
    reason: Completed
    status: "False"
    type: PrepInProgress
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Prep stage completed successfully
    observedGeneration: 13
    reason: Completed
    status: "True"
    type: PrepCompleted
  observedGeneration: 13
  validNextStages:
  - Idle
  - Upgrade
    Copy to Clipboard Toggle word wrap

15.3.2. Lifecycle Agent を使用したイメージベースアップグレードの Upgrade ステージへの移行
リンクのコピー

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

アップグレードが失敗または停止した場合は、自動ロールバックが開始されます。アップグレード後に問題が発生した場合は、手動でロールバックを開始できます。手動ロールバックの詳細は、「Lifecycle Agent を使用したイメージベースアップグレードの Rollback ステージへの移行」を参照してください。

前提条件

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

手順

  1. Upgrade ステージに移動するには、次のコマンドを実行して、ImageBasedUpgrade CR の stage フィールドの値を Upgrade に変更します。 

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Upgrade"}}' --type=merge
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、ImageBasedUpgrade CR のステータスを確認します。 

    $ oc get ibu -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    status:
  conditions:
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: In progress
    observedGeneration: 5
    reason: InProgress
    status: "False"
    type: Idle
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Prep completed
    observedGeneration: 5
    reason: Completed
    status: "False"
    type: PrepInProgress
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Prep completed successfully
    observedGeneration: 5
    reason: Completed
    status: "True"
    type: PrepCompleted
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: |-
      Waiting for system to stabilize: one or more health checks failed
        - one or more ClusterOperators not yet ready: authentication
        - one or more MachineConfigPools not yet ready: master
        - one or more ClusterServiceVersions not yet ready: sriov-fec.v2.8.0
    observedGeneration: 1
    reason: InProgress
    status: "True"
    type: UpgradeInProgress
  observedGeneration: 1
  rollbackAvailabilityExpiration: "2024-05-19T14:01:52Z"
  validNextStages:
  - Rollback
    Copy to Clipboard Toggle word wrap

    OADP Operator は、OADP Backup および Restore CR で指定されたデータのバックアップを作成し、ターゲットクラスターが再起動します。

  3. 次のコマンドを実行して、CR のステータスを監視します。 

    $ oc get ibu -o yaml
    Copy to Clipboard Toggle word wrap

  4. 正常にアップグレードされたら、次のコマンドを実行して、ImageBasedUpgrade CR の stage フィールドの値を Idle にパッチして、変更を終了します。 

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge
    Copy to Clipboard Toggle word wrap
    重要

    アップグレード後に Idle ステージに移行すると、変更をロールバックすることはできません。

    Lifecycle Agent は、アップグレードプロセス中に作成されたすべてのリソースを削除します。

  5. アップグレードが成功したら、OADP Operator とその設定ファイルを削除できます。詳細は、「クラスターからの Operator の削除」を参照してください。

検証

  1. 次のコマンドを実行して、ImageBasedUpgrade CR のステータスを確認します。 

    $ oc get ibu -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    status:
  conditions:
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: In progress
    observedGeneration: 5
    reason: InProgress
    status: "False"
    type: Idle
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Prep completed
    observedGeneration: 5
    reason: Completed
    status: "False"
    type: PrepInProgress
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Prep completed successfully
    observedGeneration: 5
    reason: Completed
    status: "True"
    type: PrepCompleted
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Upgrade completed
    observedGeneration: 1
    reason: Completed
    status: "False"
    type: UpgradeInProgress
  - lastTransitionTime: "2024-01-01T09:00:00Z"
    message: Upgrade completed
    observedGeneration: 1
    reason: Completed
    status: "True"
    type: UpgradeCompleted
  observedGeneration: 1
  rollbackAvailabilityExpiration: "2024-01-01T09:00:00Z"
  validNextStages:
  - Idle
  - Rollback
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、クラスターの復元ステータスを確認します。 

    $ oc get restores -n openshift-adp -o custom-columns=NAME:.metadata.name,Status:.status.phase,Reason:.status.failureReason
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             Status      Reason
acm-klusterlet   Completed   <none>
    1 
    
apache-app       Completed   <none>
localvolume      Completed   <none>
    Copy to Clipboard Toggle word wrap

    1
    acm-klusterlet は RHACM 環境にのみ固有です。

15.3.3. Lifecycle Agent を使用したイメージベースアップグレードの Rollback ステージへの移行
リンクのコピー

再起動後、initMonitorTimeoutSeconds フィールドに指定された時間枠内にアップグレードが完了しない場合は、自動ロールバックが開始されます。

ImageBasedUpgrade CR の例

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle
  seedImageRef:
    version: 4.15.2
    image: <seed_container_image>
  autoRollbackOnFailure: {}
#    initMonitorTimeoutSeconds: 1800
1 

[...]
Copy to Clipboard Toggle word wrap

1
(オプション) 最初の再起動後、指定された時間枠内にアップグレードが完了しない場合にロールバックする時間枠を秒単位で指定します。定義されていないか 0 に設定されている場合は、デフォルト値の 1800 秒 (30 分) が使用されます。

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

前提条件

  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • 元の stateroot 上のコントロールプレーン証明書が有効である。証明書の有効期限が切れている場合は、「コントロールプレーン証明書の期限切れの状態からのリカバリー」を参照してください。

手順

  1. Rollback ステージに移行するには、次のコマンドを実行して、ImageBasedUpgrade CR の stage フィールドの値を Rollback にパッチします。 

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Rollback"}}' --type=merge
    Copy to Clipboard Toggle word wrap

    Lifecycle Agent は、以前にインストールされたバージョンの OpenShift Container Platform を使用してクラスターを再起動し、アプリケーションを復元します。

  2. 正常に変更されたら、次のコマンドを実行して、ImageBasedUpgrade CR の stage フィールドの値を Idle にパッチして、ロールバックを終了します。 

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge -n openshift-lifecycle-agent
    Copy to Clipboard Toggle word wrap
    警告

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

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

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

重要

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

15.3.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
    Copy to Clipboard Toggle word wrap
    1
    (オプション) OADP Operator からさらに情報を収集する必要がある場合は、このオプションを追加できます。
    2
    (オプション) SR-IOV Operator からさらに情報を収集する必要がある場合は、このオプションを追加できます。

15.3.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
Copy to Clipboard Toggle word wrap

解決方法
  1. ログを調べて、失敗が発生した理由を特定します。

  2. Lifecycle Agent にクリーンアップを再試行するように指示するには、ImageBasedUpgrade CR に lca.openshift.io/manual-cleanup-done アノテーションを追加します。

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

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

15.3.4.2.1. 手動での stateroot のクリーンアップ
リンクのコピー
問題
Lifecycle Agent は Prep ステージで停止し、新しい stateroot をクリーンアップします。アップグレードまたはロールバックが成功した後に終了すると、Lifecycle Agent は古い stateroot をクリーンアップします。この手順が失敗した場合は、ログを調べて失敗の原因を特定することを推奨します。
解決方法

  1. 次のコマンドを実行して、stateroot に既存のデプロイメントがあるか確認します。 

    $ ostree admin status
    Copy to Clipboard Toggle word wrap

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

    $ ostree admin undeploy <index_of_deployment>
    Copy to Clipboard Toggle word wrap

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

    警告

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

    $ stateroot="<stateroot_to_delete>"
    Copy to Clipboard Toggle word wrap 
    $ unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
    Copy to Clipboard Toggle word wrap
15.3.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
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                          PHASE       LAST VALIDATED   AGE   DEFAULT
dataprotectionapplication-1   Available   33s              8d    true
    Copy to Clipboard Toggle word wrap

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

15.3.4.3. LVM Storage ボリュームの内容が復元されない
リンクのコピー

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

15.3.4.3.1. Backup CR に LVM Storage 関連のフィールドがない
リンクのコピー
問題

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

$ oc describe pod <your_app_name>
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

解決方法

アプリケーション 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
Copy to Clipboard Toggle word wrap

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

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

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

    $ oc get pv,pvc,logicalvolumes.topolvm.io -A
    Copy to Clipboard Toggle word wrap

    ピボット前の出力例

    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
    Copy to Clipboard Toggle word wrap

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

    $ oc get pv,pvc,logicalvolumes.topolvm.io -A
    Copy to Clipboard Toggle word wrap

    ピボット後の出力例

    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
    Copy to Clipboard Toggle word wrap

解決方法

この問題は、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
Copy to Clipboard Toggle word wrap

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

15.3.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
    Copy to Clipboard Toggle word wrap

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

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat