15.4. 使用 GitOps ZTP 为单节点 OpenShift 集群执行基于镜像的升级
您可以通过 GitOps Zero Touch Provisioning (ZTP) 使用基于镜像的升级来升级受管单节点 OpenShift 集群。
当您在集群中部署生命周期代理时,会自动创建 ImageBasedUpgrade
CR。您可以更新此 CR,以指定 seed 镜像的镜像存储库,并通过不同的阶段移动。
15.4.1. 使用 Lifecycle Agent 和 GitOps ZTP 移到基于镜像的升级的 Prep 阶段
当您在集群中部署生命周期代理时,会自动创建 ImageBasedUpgrade
CR。您可以更新此 CR,以指定 seed 镜像的镜像存储库,并通过不同的阶段移动。
ztp-site-generate 容器中的 ImageBasedUpgrade CR
apiVersion: lca.openshift.io/v1 kind: ImageBasedUpgrade metadata: name: upgrade spec: stage: Idle
先决条件
-
为基于镜像升级中使用的资源创建策略和
ConfigMap
对象。如需更多信息,请参阅"使用 GitOps ZTP 基于镜像升级创建 ConfigMap 对象。
流程
将
Prep
、Upgrade
和Idle
阶段的策略添加到名为ibu-upgrade-ranGen.yaml
的现有组PolicyGenTemplate
中: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 中对应的 policy-binding 标签更新为目标平台。apiVersion: ran.openshift.io/v1 kind: SiteConfig [...] spec: [...] clusterLabels: du-profile: "4.15.0"
重要将标签更新至目标平台版本,取消绑定现有策略集。
-
提交更新的
SiteConfig
CR 并将其推送到 Git 存储库。 当您准备好进入
Prep
阶段时,使用Prep
和 OADPConfigMap
策略在目标 hub 集群上创建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、命名空间或空运行失败)更新Prep
阶段中的status.conditions
,和ImageBasedUpgrade
CR 中的annotation
字段,其中包含有关警告的详情。验证警告示例
[...] metadata: annotations: extra-manifest.lca.openshift.io/validation-warning: '...' [...]
但是,验证错误,如将
MachineConfig
或 Operator 清单添加到额外清单中,从而导致Prep
阶段失败并阻止Upgrade
阶段。当验证通过时,集群会创建一个新的
ostree
stateroot,它涉及拉取和解包 seed 镜像,并运行主机级别命令。最后,目标集群中会包括所有必需的镜像。-
如果 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 和 GitOps ZTP 启动回滚。
先决条件
-
完成
Prep
阶段。
流程
当您准备好进入
Upgrade
阶段时,请在引用Upgrade
策略的目标 hub 集群中创建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
当您对更改满意并准备好完成升级时,请在目标 hub 集群上创建一个
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 命名空间、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 命名空间、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 应用程序对 hub 集群同步更改。
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 命名空间、Operator 组和订阅 CR。 - 将更改与自定义站点存储库合并,并等待 ArgoCD 应用程序对 hub 集群同步更改。策略保持合规。
15.4.3. 使用 Lifecycle Agent 和 GitOps ZTP 移到基于镜像的升级的 Rollback 阶段
如果在升级后遇到问题,您可以启动手动回滚。
先决条件
- 确保原始 stateroot 上的 control plane 证书有效。如果证书已过期,请参阅"恢复过期的 control plane 证书"。
流程
将
du-profile
或对应的 policy-binding 标签恢复到SiteConfig
CR 中的原始平台版本:apiVersion: ran.openshift.io/v1 kind: SiteConfig [...] spec: [...] clusterLabels: du-profile: "4.14.x"
当您准备好启动回滚时,将
Rollback
策略添加到现有组PolicyGenTemplate
CR 中:[...] - fileName: ibu/ImageBasedUpgrade.yaml policyName: "rollback-stage-policy" spec: stage: Rollback status: conditions: - message: Rollback completed reason: Completed status: "True" type: RollbackCompleted
在目标 hub 集群上创建一个
ClusterGroupUpgrade
CR,以引用Rollback
策略: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
当您对更改满意且准备好完成回滚时,请在目标 hub 集群上创建一个
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. 使用生命周期代理对基于镜像的升级进行故障排除
在基于镜像的升级过程中可能会遇到问题。
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
阶段时,生命周期代理会清理以下资源:- 不再需要的 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
- 解决方案
- 检查日志,以确定发生失败的原因。
要提示生命周期代理重试清理,请将
lca.openshift.io/manual-cleanup-done
注解添加到ImageBasedUpgrade
CR。观察此注解后,生命周期代理会重试清理,如果成功,
ImageBasedUpgrade
阶段会过渡到Idle
。如果清理再次失败,您可以手动清理资源。
15.4.4.2.1. 手动清理 stateroot
- 问题
-
在
Prep
阶段停止,生命周期代理会清理新的 stateroot。在成功升级或回滚后最终调整时,生命周期代理会清理旧的 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 资源
- 问题
-
由于生命周期代理和 S3 后端之间的连接问题,自动清理 OADP 资源可能会失败。通过恢复连接并添加
lca.openshift.io/manual-cleanup-done
注解,生命周期代理可以成功清理备份资源。 - 解决方案
运行以下命令检查后端连接:
$ 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 存储卷内容没有恢复
当使用 LVM 存储来提供动态持久性卷存储时,如果配置不正确,LVM 存储可能无法恢复持久性卷内容。
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
在 pivot 后无法正确恢复。备份 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 相关的字段
- 问题
应用程序的预期资源会被恢复,但升级后持久性卷内容不会被保留。
在 pivot 前运行以下命令来列出应用程序的持久性卷:
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
pivot 前的输出示例
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
在 pivot 后运行以下命令来列出应用程序的持久性卷:
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
pivot 后的输出示例
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 需要引用 pivoting 后必须保留的卷。您必须在应用程序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. 调试失败的备份和恢复 CR
- 问题
- 工件的备份或恢复失败。
- 解决方案
您可以调试
Backup
和Restore
CR,并使用 Velero CLI 工具检索日志。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