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'
前提条件
- クラスターをバックアップおよび復元するためのリソースを作成している。
手順
ImageBasedUpgradeCR にパッチが適用されていることを確認します。apiVersion: lca.openshift.io/v1 kind: ImageBasedUpgrade metadata: name: upgrade spec: stage: Idle seedImageRef: version: 4.15.21 image: <seed_container_image>2 pullSecretRef: <seed_pull_secret>3 autoRollbackOnFailure: {} # initMonitorTimeoutSeconds: 18004 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ステージを開始するには、次のコマンドを実行して、ImageBasedUpgradeCR のstageフィールドの値をPrepに変更します。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agentOADP リソースと追加のマニフェストの
ConfigMapオブジェクトを指定すると、Lifecycle Agent はPrepステージで指定されたConfigMapオブジェクトを検証します。以下の問題が発生する可能性があります。-
Lifecycle Agent が
extraManifestsパラメーターに問題を検出した場合の検証警告またはエラー。 -
Lifecycle Agent が
oadpContentパラメーターに問題を検出した場合の検証エラー。
検証警告は
Upgradeステージをブロックしませんが、アップグレードを続行しても安全かどうかを判断する必要があります。これらの警告 (CRD の欠落、namespace の欠落、またはドライランの失敗など) は、警告に関する詳細でPrepステージのstatus.conditionsとImageBasedUpgradeCR のannotationフィールドを更新します。検証警告の例
[...] metadata: annotations: extra-manifest.lca.openshift.io/validation-warning: '...' [...]ただし、
MachineConfigまたは Operator マニフェストを追加マニフェストに追加するなどの検証エラーが発生すると、Prepステージが失敗し、Upgradeステージがブロックされます。検証に合格すると、クラスターは新しい
ostreestateroot を作成します。これには、シードイメージのプルと展開、およびホストレベルのコマンドの実行が含まれます。最後に、必要なすべてのイメージがターゲットクラスターに事前キャッシュされます。-
Lifecycle Agent が
検証
次のコマンドを実行して、
ImageBasedUpgradeCR のステータスを確認します。$ 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ステージに移動するには、次のコマンドを実行して、ImageBasedUpgradeCR のstageフィールドの値をUpgradeに変更します。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Upgrade"}}' --type=merge次のコマンドを実行して、
ImageBasedUpgradeCR のステータスを確認します。$ 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: - RollbackOADP Operator は、OADP
BackupおよびRestoreCR で指定されたデータのバックアップを作成し、ターゲットクラスターが再起動します。次のコマンドを実行して、CR のステータスを監視します。
$ oc get ibu -o yaml正常にアップグレードされたら、次のコマンドを実行して、
ImageBasedUpgradeCR のstageフィールドの値をIdleにパッチして、変更を終了します。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge重要アップグレード後に
Idleステージに移行すると、変更をロールバックすることはできません。Lifecycle Agent は、アップグレードプロセス中に作成されたすべてのリソースを削除します。
- アップグレードが成功したら、OADP Operator とその設定ファイルを削除できます。詳細は、「クラスターからの Operator の削除」を参照してください。
検証
次のコマンドを実行して、
ImageBasedUpgradeCR のステータスを確認します。$ 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
- (オプション) 最初の再起動後、指定された時間枠内にアップグレードが完了しない場合にロールバックする時間枠を秒単位で指定します。定義されていないか
0に設定されている場合は、デフォルト値の1800秒 (30 分) が使用されます。
アップグレード後に解決できない問題が発生した場合は、変更を手動でロールバックできます。
前提条件
-
cluster-admin権限を持つユーザーとしてハブクラスターにログインしている。 - 元の stateroot 上のコントロールプレーン証明書が有効である。証明書の有効期限が切れている場合は、「コントロールプレーン証明書の期限切れの状態からのリカバリー」を参照してください。
手順
Rollback ステージに移行するには、次のコマンドを実行して、
ImageBasedUpgradeCR のstageフィールドの値をRollbackにパッチします。$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Rollback"}}' --type=mergeLifecycle Agent は、以前にインストールされたバージョンの OpenShift Container Platform を使用してクラスターを再起動し、アプリケーションを復元します。
正常に変更されたら、次のコマンドを実行して、
ImageBasedUpgradeCR の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 を使用したイメージベースアップグレードのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
問題の影響を受けるマネージドクラスターでトラブルシューティング手順を実行します。
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:latest2
15.3.4.2. AbortFailed または FinalizeFailed エラー リンクのコピーリンクがクリップボードにコピーされました!
- 問題
最終ステージの間、または
Prepステージでプロセスを停止すると、Lifecycle Agent は次のリソースをクリーンアップします。- 不要になった stateroot
- リソースの事前キャッシュ
- OADP CR
-
ImageBasedUpgradeCR
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 にクリーンアップを再試行するように指示するには、
ImageBasedUpgradeCR に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アノテーションをImageBasedUpgradeCR に追加します。
15.3.4.3. LVM Storage ボリュームの内容が復元されない リンクのコピーリンクがクリップボードにコピーされました!
LVM Storage を使用して動的永続ボリュームストレージを提供する場合、LVM Storage が正しく設定されていないと、永続ボリュームの内容が復元されない可能性があります。
15.3.4.3.1. Backup CR に LVM Storage 関連のフィールドがない リンクのコピーリンクがクリップボードにコピーされました!
- 問題
BackupCR に、永続ボリュームを復元するために必要なフィールドが欠落している可能性があります。以下を実行すると、アプリケーション 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- 解決方法
アプリケーション
BackupCR に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ステータスがRestoreCR に保存されないことが原因となっています。このステータスは、Velero がピボット後に保持する必要があるボリュームを参照する必要があるため重要です。アプリケーションのRestoreCR には、次のフィールドを含める必要があります。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: true1 restoreStatus:2 includedResources: - logicalvolumes
15.3.4.4. 失敗した Backup CR および Restore CR のデバッグ リンクのコピーリンクがクリップボードにコピーされました!
- 問題
- アーティファクトのバックアップまたは復元に失敗しました。
- 解決方法
Velero CLI ツールを使用して、
BackupおよびRestoreCR をデバッグし、ログを取得できます。Velero CLI ツールは、OpenShift CLI ツールよりも詳細な情報を提供します。次のコマンドを実行して、エラーを含む
BackupCR を説明します。$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details次のコマンドを実行して、エラーを含む
RestoreCR を説明します。$ 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