15.4. GitOps ZTP を使用したシングルノード OpenShift クラスターのイメージベースアップグレードの実行
ハブクラスター上の 1 つのリソース、ImageBasedGroupUpgrade
カスタムリソース (CR) を使用して、すべてのステージを通じて、選択したマネージドクラスターのグループでイメージベースのアップグレードを管理できます。Topology Aware Lifecycle Manager (TALM) は、ImageBasedGroupUpgrade
CR を調整し、手動制御のアップグレードフローまたは完全に自動のアップグレードフローにより、定められたステージ遷移を完了するための基盤リソースを作成します。
イメージベースのアップグレードの詳細は、「シングルノード OpenShift クラスターのイメージベースのアップグレードについて」を参照してください。
15.4.1. ハブ上の ImageBasedGroupUpgrade
CR を使用してイメージベースのアップグレードを大規模に管理する
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.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
15.4.1.1. サポートされているアクションの組み合わせ
アクションは、選択されたクラスターグループのアップグレードプランの各ステップで TALM が実行する一連のステージ遷移です。ImageBasedGroupUpgrade
CR 内の action
エントリーは、それぞれ個別のステップです。1 つのステップに、同じロールアウトストラテジーを共有する 1 つ以上のアクションを含めます。アクションをステップに分けることで、各アクションのロールアウトストラテジーをより細かく制御できます。
これらのアクションは、アップグレードプラン内でさまざまな方法で組み合わせることができます。後続のステップは、後で追加することができます。プランにステップを追加する前に、前のステップが完了するか失敗するまで待機します。前のステップで失敗したクラスターに対して追加するステップの最初のアクションは、Abort
または Rollback
のどちらかである必要があります。
進行中のプランからアクションまたはステップを削除することはできません。
次の表にプランの例を示します。それぞれの例で、ロールアウトストラテジーに対する制御レベルが異なります。
プランの例 | 説明 |
---|---|
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 をインストールした。
手順
ハブクラスターで、
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
ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
$ oc apply -f <filename>.yaml
ハブクラスターで次のコマンドを実行して、ステータスの更新を監視します。
$ 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
ステージに戻されます。選択されたクラスターのアップグレードに関連するリソースがすべて削除されます。オプション: 次のコマンドを実行して、既存の
ImageBasedGroupUpgrade
CR にAbortOnFailure
アクションを追加します。$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
次のコマンドを実行して、ステータスの更新の監視を継続します。
$ oc get ibgu -o yaml
次のコマンドを実行して、既存の
ImageBasedGroupUpgrade
CR にアクションを追加します。$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
オプション: 次のコマンドを実行して、既存の
ImageBasedGroupUpgrade
CR にAbortOnFailure
アクションを追加します。$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
次のコマンドを実行して、ステータスの更新の監視を継続します。
$ oc get ibgu -o yaml
次のコマンドを実行して、既存の
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 をインストールした。
手順
ハブクラスターで、
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
ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
$ 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
権限を持つユーザーとしてハブクラスターにログインしている。
手順
ハブクラスターで、
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
ステージに戻ります。ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
$ 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
権限を持つユーザーとしてハブクラスターにログインしている。
手順
ハブクラスターで、
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
ハブクラスターで次のコマンドを実行して、作成したファイルを適用します。
$ 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
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
- 解決方法
- ログを調べて、失敗が発生した理由を特定します。
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 をクリーンアップします。この手順が失敗した場合は、ログを調べて失敗の原因を特定することを推奨します。 - 解決方法
次のコマンドを実行して、stateroot に既存のデプロイメントがあるか確認します。
$ ostree admin status
ある場合は、次のコマンドを実行して既存のデプロイメントをクリーンアップします。
$ ostree admin undeploy <index_of_deployment>
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 はバックアップリソースを正常にクリーンアップできます。 - 解決方法
次のコマンドを実行して、バックエンドの接続を確認します。
$ oc get backupstoragelocations.velero.io -n openshift-adp
出力例
NAME PHASE LAST VALIDATED AGE DEFAULT dataprotectionapplication-1 Available 33s 8d true
-
すべてのバックアップリソースを削除してから、
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 関連のフィールドがない
- 問題
アプリケーションの予想されるリソースは復元されますが、アップグレード後に永続ボリュームの内容は保持されません。
ピボット前に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。
$ 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
ピボット後に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。
$ 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
15.4.6.4. 失敗した Backup CR および Restore CR のデバッグ
- 問題
- アーティファクトのバックアップまたは復元に失敗しました。
- 解決方法
Velero CLI ツールを使用して、
Backup
およびRestore
CR をデバッグし、ログを取得できます。Velero CLI ツールは、OpenShift CLI ツールよりも詳細な情報を提供します。次のコマンドを実行して、エラーを含む
Backup
CR を説明します。$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
次のコマンドを実行して、エラーを含む
Restore
CR を説明します。$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
次のコマンドを実行して、バックアップされたリソースをローカルディレクトリーにダウンロードします。
$ 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