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 オブジェクトの作成」セクションを参照してください。
前提条件
- クラスターをバックアップおよび復元するためのリソースを作成している。
手順
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
- 1
- ターゲットプラットフォームのバージョンを指定します。値はシードイメージのバージョンと一致する必要があります。
- 2
- ターゲットクラスターがシードイメージをプルできるリポジトリーを指定します。
- 3
- イメージがプライベートレジストリー内にある場合は、コンテナーイメージをプルするための認証情報を含むシークレットへの参照を指定します。
- 4
- (オプション) 最初の再起動後、指定された時間枠内にアップグレードが完了しない場合にロールバックする時間枠を秒単位で指定します。定義されていないか
0
に設定されている場合は、デフォルト値の1800
秒 (30 分) が使用されます。 - 5
- (オプション) アップグレード後に保持するカスタムカタログソースと、シードイメージの一部ではないターゲットクラスターに適用する追加のマニフェストを含む
ConfigMap
リソースのリストを指定します。 - 6
- OADP
ConfigMap
情報を含むoadpContent
セクションを追加します。
Prep
ステージを開始するには、次のコマンドを実行して、ImageBasedUpgrade
CR のstage
フィールドの値をPrep
に変更します。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agent
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: '...' [...]
ただし、
MachineConfig
または Operator マニフェストを追加マニフェストに追加するなどの検証エラーが発生すると、Prep
ステージが失敗し、Upgrade
ステージがブロックされます。検証に合格すると、クラスターは新しい
ostree
stateroot を作成します。これには、シードイメージのプルと展開、およびホストレベルのコマンドの実行が含まれます。最後に、必要なすべてのイメージがターゲットクラスターに事前キャッシュされます。-
Lifecycle Agent が
検証
次のコマンドを実行して、
ImageBasedUpgrade
CR のステータスを確認します。$ oc get ibu -o yaml
出力例
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
15.3.2. Lifecycle Agent を使用したイメージベースアップグレードの Upgrade ステージへの移行
シードイメージを生成し、Prep
ステージを完了したら、ターゲットクラスターをアップグレードできます。アップグレードプロセス中に、OADP Operator は OADP カスタムリソース (CR) で指定されたアーティファクトのバックアップを作成し、その後、Lifecycle Agent がクラスターをアップグレードします。
アップグレードが失敗または停止した場合は、自動ロールバックが開始されます。アップグレード後に問題が発生した場合は、手動でロールバックを開始できます。手動ロールバックの詳細は、「Lifecycle Agent を使用したイメージベースアップグレードの Rollback ステージへの移行」を参照してください。
前提条件
-
Prep
ステージを完了している。
手順
Upgrade
ステージに移動するには、次のコマンドを実行して、ImageBasedUpgrade
CR のstage
フィールドの値をUpgrade
に変更します。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Upgrade"}}' --type=merge
次のコマンドを実行して、
ImageBasedUpgrade
CR のステータスを確認します。$ oc get ibu -o yaml
出力例
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
OADP Operator は、OADP
Backup
およびRestore
CR で指定されたデータのバックアップを作成し、ターゲットクラスターが再起動します。次のコマンドを実行して、CR のステータスを監視します。
$ oc get ibu -o yaml
正常にアップグレードされたら、次のコマンドを実行して、
ImageBasedUpgrade
CR のstage
フィールドの値をIdle
にパッチして、変更を終了します。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge
重要アップグレード後に
Idle
ステージに移行すると、変更をロールバックすることはできません。Lifecycle Agent は、アップグレードプロセス中に作成されたすべてのリソースを削除します。
- アップグレードが成功したら、OADP Operator とその設定ファイルを削除できます。詳細は、「クラスターからの Operator の削除」を参照してください。
検証
次のコマンドを実行して、
ImageBasedUpgrade
CR のステータスを確認します。$ oc get ibu -o yaml
出力例
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
次のコマンドを実行して、クラスターの復元ステータスを確認します。
$ oc get restores -n openshift-adp -o custom-columns=NAME:.metadata.name,Status:.status.phase,Reason:.status.failureReason
出力例
NAME Status Reason acm-klusterlet Completed <none> 1 apache-app Completed <none> localvolume Completed <none>
- 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
[...]
- 1
- (オプション) 最初の再起動後、指定された時間枠内にアップグレードが完了しない場合にロールバックする時間枠を秒単位で指定します。定義されていないか
0
に設定されている場合は、デフォルト値の1800
秒 (30 分) が使用されます。
アップグレード後に解決できない問題が発生した場合は、変更を手動でロールバックできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - 元の stateroot 上のコントロールプレーン証明書が有効である。証明書の有効期限が切れている場合は、「コントロールプレーン証明書の期限切れの状態からのリカバリー」を参照してください。
手順
Rollback ステージに移行するには、次のコマンドを実行して、
ImageBasedUpgrade
CR のstage
フィールドの値をRollback
にパッチします。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Rollback"}}' --type=merge
Lifecycle Agent は、以前にインストールされたバージョンの OpenShift Container Platform を使用してクラスターを再起動し、アプリケーションを復元します。
正常に変更されたら、次のコマンドを実行して、
ImageBasedUpgrade
CR のstage
フィールドの値をIdle
にパッチして、ロールバックを終了します。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge -n openshift-lifecycle-agent
警告ロールバック後に
Idle
ステージに移行すると、Lifecycle Agent は失敗したアップグレードのトラブルシューティングに使用できるリソースをクリーンアップします。
15.3.4. Lifecycle Agent を使用したイメージベースアップグレードのトラブルシューティング
イメージベースアップグレード中に問題が発生する可能性があります。
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
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
- 解決方法
- ログを調べて、失敗が発生した理由を特定します。
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 をクリーンアップします。この手順が失敗した場合は、ログを調べて失敗の原因を特定することを推奨します。 - 解決方法
次のコマンドを実行して、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.3.4.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.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>
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.3.4.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.3.4.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