15.4. GitOps ZTP を使用したシングルノード OpenShift クラスターのイメージベースアップグレードの実行
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 オブジェクトの作成」を参照してください。
手順
ibu-upgrade-ranGen.yaml
という既存のPolicyGenTemplate
グループに、Prep
、Upgrade
、Idle
の各ステージのポリシーを追加します。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
次のコマンドを実行して、イメージベースアップグレードに必要なポリシーが作成されていることを確認します。
$ 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
du-profile
クラスターラベルを、ターゲットプラットフォームバージョンまたはSiteConfig
CR 内の対応するポリシーバインディングラベルに更新します。apiVersion: ran.openshift.io/v1 kind: SiteConfig [...] spec: [...] clusterLabels: du-profile: "4.15.0"
重要ラベルをターゲットプラットフォームバージョンに更新すると、既存のポリシーセットがバインド解除されます。
-
更新された
SiteConfig
CR をコミットして Git リポジトリーにプッシュします。 Prep
ステージに移行する準備ができたら、Prep
および OADPConfigMap
ポリシーを使用して、ターゲットハブクラスターに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
以下のコマンドを実行して
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.conditions
とImageBasedUpgrade
CR のannotation
フィールドを更新します。検証警告の例
[...] metadata: annotations: extra-manifest.lca.openshift.io/validation-warning: '...' [...]
ただし、
MachineConfig
または Operator マニフェストを追加マニフェストに追加するなどの検証エラーが発生すると、Prep
ステージが失敗し、Upgrade
ステージがブロックされます。検証に合格すると、クラスターは新しい
ostree
stateroot を作成します。これには、シードイメージのプルと展開、およびホストレベルのコマンドの実行が含まれます。最後に、必要なすべてのイメージがターゲットクラスターに事前キャッシュされます。-
Lifecycle Agent が
次のコマンドを実行して、ステータスを監視し、
cgu-ibu-prep
ClusterGroupUpgrade
がCompleted
を報告するまで待ちます。$ 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
ステージを完了している。
手順
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
次のコマンドを実行して
Upgrade
ポリシーを適用します。$ oc apply -f cgu-ibu-upgrade.yml
次のコマンドを実行してステータスを監視し、
cgu-ibu-upgrade
ClusterGroupUpgrade
がCompleted
を報告するまで待ちます。$ 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
正常に変更され、アップグレードを終了する準備ができたら、アップグレードを終了するポリシーを参照するターゲットハブクラスターに
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 を削除します。以下のコマンドを実行してポリシーを適用します。
$ oc apply -f cgu-ibu-finalize.yaml
次のコマンドを実行して、ステータスを監視し、
cgu-ibu-finalize
ClusterGroupUpgrade
がCompleted
になるまで待ちます。$ 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
アップグレードが成功したら、OADP Operator とその設定ファイルを削除できます。
common-ranGen.yaml
ファイル内の OADP Operator namespace、Operator グループ、およびサブスクリプションのcomplianceType
をmustnothave
に変更します。[...] - 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 [...]
サイトの
PolicyGenTemplate
ファイルで、OADP Operator namespace、Operator グループ、およびサブスクリプションのcomplianceType
をmustnothave
に変更します。- fileName: OadpSecret.yaml policyName: "config-policy" complianceType: mustnothave - fileName: OadpBackupStorageLocationStatus.yaml policyName: "config-policy" complianceType: mustnothave - fileName: DataProtectionApplication.yaml policyName: "config-policy" complianceType: mustnothave
-
変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。
common-subscriptions-policy
ポリシーとexample-cnf-config-policy
ポリシーのステータスがNon-Compliant
に変わります。 - Topology Aware Lifecycle Manager を使用して、ターゲットクラスターに変更を適用します。設定変更のロールアウトの詳細は、「マネージドクラスターでのポリシーの更新」を参照してください。
プロセスを監視します。ターゲットクラスターの
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
-
common-ranGen.yaml
およびサイトPolicyGenTemplate
ファイルのspec.sourceFiles
から、OADP Operator namespace、Operator グループとサブスクリプション、および設定 CR を削除します。 - 変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。ポリシーは準拠したままです。
15.4.3. Lifecycle Agent と GitOps ZTP を使用したイメージベースアップグレードの Rollback ステージへの移行
アップグレード後に問題が発生した場合は、手動でロールバックを開始できます。
前提条件
- 元の stateroot 上のコントロールプレーン証明書が有効である。証明書の有効期限が切れている場合は、「コントロールプレーン証明書の期限切れの状態からのリカバリー」を参照してください。
手順
du-profile
または対応するポリシーバインディングラベルを、SiteConfig
CR の元のプラットフォームバージョンに戻します。apiVersion: ran.openshift.io/v1 kind: SiteConfig [...] spec: [...] clusterLabels: du-profile: "4.14.x"
ロールバックを開始する準備ができたら、既存の
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
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
次のコマンドを実行して、
Rollback
ポリシーを適用します。$ oc apply -f cgu-ibu-rollback.yml
正常に変更され、ロールバックを終了する準備ができたら、ロールバックを終了するポリシーを参照するターゲットハブクラスターに
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
以下のコマンドを実行してポリシーを適用します。
$ 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
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
- 解決方法
- ログを調べて、失敗が発生した理由を特定します。
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 をクリーンアップします。この手順が失敗した場合は、ログを調べて失敗の原因を特定することを推奨します。 - 解決方法
次のコマンドを実行して、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.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.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 関連のフィールドがない
- 問題
アプリケーションの予想されるリソースは復元されますが、アップグレード後に永続ボリュームの内容は保持されません。
ピボット前に次のコマンドを実行して、アプリケーションの永続ボリュームをリスト表示します。
$ 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.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