15.4. 使用 GitOps ZTP 为单节点 OpenShift 集群执行基于镜像的升级
您可以使用 hub 集群中的单个资源 ImageBasedGroupUpgrade
自定义资源(CR)通过所有阶段在所选受管集群组上管理基于镜像的升级。Topology Aware Lifecycle Manager (TALM)协调 ImageBasedGroupUpgrade
CR,并创建底层资源来完成定义的阶段转换,可以在手动控制或完全自动化升级流程中。
有关基于镜像的升级的更多信息,请参阅"为单节点 OpenShift 集群使用基于镜像的升级"。
15.4.1. 在 hub 上使用 ImageBasedGroupUpgrade
CR 大规模管理基于镜像的升级
ImageBasedGroupUpgrade
CR 结合了 ImageBasedUpgrade
和 ClusterGroupUpgrade
API。例如,您可以使用 ImageBasedGroupUpgrade
API 定义集群选择和推出部署策略,方式与 ClusterGroupUpgrade
API 相同。阶段转换与 ImageBasedUpgrade
API 不同。ImageBasedGroupUpgrade
API 允许您将几个阶段转换(也称为操作)组合成一个 rollout 策略的一个步骤。
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
条目都是一个单独的步骤,一个步骤包含一个或几个共享同一 rollout 策略的操作。您可以通过将操作分成多个步骤来对每个操作的 rollout 策略进行更多控制。
这些操作可以在升级计划中以不同的方式合并,您可以稍后添加后续步骤。在向计划中添加步骤前,等待前面的步骤完成或失败。为在前面失步骤中失败的集群添加的添加步骤的第一个操作必须是 Abort
或 Rollback
。
您无法从持续计划中删除操作或步骤。
下表显示了针对 rollout 策略的不同控制级别的计划:
计划示例 | 描述 |
---|---|
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
部分中,包括在一对括号中的是一个步骤:
-
["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 确保更好的监控体验,并为在一个位置聚合的所有集群提供全面的状态报告。您可以监控以下操作:
status.clusters.completedActions
-
显示
plan
部分中定义的所有完成操作。 status.clusters.currentAction
- 显示当前正在进行的所有操作。
status.clusters.failedActions
- 显示所有失败的操作以及详细错误消息。
15.4.2. 在受管集群中执行基于镜像的升级,以几个步骤扩展
对于在升级中断时更好地控制升级中断,您可以使用 ImageBasedGroupUpgrade
CR 在上一步完成后添加操作来升级一组受管集群。在评估了前面的步骤的结果后,您可以移至下一个升级阶段,或者对整个流程中的任何失败步骤进行故障排除。
只支持某些操作组合,并在支持的操作组合中列出。
先决条件
-
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 -
您已为基于镜像升级中使用的资源创建了策略和
ConfigMap
对象。 - 您已通过 hub 集群在所有受管集群中安装了 Lifecycle Agent 和 OADP Operator。
流程
在 hub 集群上创建一个包含
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
在 hub 集群中运行以下命令来应用创建的文件:
$ oc apply -f <filename>.yaml
在 hub 集群中运行以下命令来监控状态更新:
$ oc get ibgu -o yaml
输出示例
# ... status: clusters: - completedActions: - action: Prep name: spoke1 - completedActions: - action: Prep name: spoke4 - failedActions: - action: Prep name: spoke6 # ...
示例计划前面的输出仅以
Prep
阶段开始,您可以根据上一步的结果向计划添加操作。如果升级成功或失败,TALM 会在集群中添加标签来标记集群。例如,lcm.openshift.io/ibgu-prep-failed
应用到Prep
阶段失败的集群。调查失败后,您可以在升级计划中添加
AbortOnFailure
步骤。它将带有lcm.openshift.io/ibgu-<action>-failed
标记的集群移到Idle
阶段。与所选集群中升级相关的资源都会被删除。可选:通过运行以下命令,将
AbortOnFailure
操作添加到现有的ImageBasedGroupUpgrade
CR 中:$ 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}}}]'
可选:通过运行以下命令,将
AbortOnFailure
操作添加到现有的ImageBasedGroupUpgrade
CR 中:$ 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. 在一个步骤中,在受管集群中执行基于镜像的升级
对于服务中断不是关注的用例,您可以使用 ImageBasedGroupUpgrade
CR,使用带有一个 rollout 策略的一个步骤来升级一组受管集群。使用一个 rollout 策略,可以减少升级时间,但只能在升级计划完成后对失败的集群进行故障排除。
先决条件
-
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 -
您已为基于镜像升级中使用的资源创建了策略和
ConfigMap
对象。 - 您已通过 hub 集群在所有受管集群中安装了 Lifecycle Agent 和 OADP Operator。
流程
在 hub 集群上创建一个包含
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
在 hub 集群中运行以下命令来应用创建的文件:
$ 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
权限的用户身份登录到 hub 集群。
流程
在 hub 集群上创建一个包含
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
阶段。在 hub 集群中运行以下命令来应用创建的文件:
$ 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
权限的用户身份登录到 hub 集群。
流程
在 hub 集群上创建一个包含
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
在 hub 集群中运行以下命令来应用创建的文件:
$ oc apply -f <filename>.yaml
所有与定义的标签匹配的受管集群都会移到
Rollback
中,然后进入Idle
阶段来完成回滚。
验证
运行以下命令监控状态更新:
$ oc get ibgu -o yaml
输出示例
# ... status: clusters: - completedActions: - action: Rollback - action: FinalizeRollback name: spoke4 # ...
15.4.6. 使用生命周期代理对基于镜像的升级进行故障排除
对受问题影响的受管集群执行故障排除步骤。
如果您使用 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
阶段时,生命周期代理会清理以下资源:- 不再需要的 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.6.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.6.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.6.3. LVM 存储卷内容没有恢复
当使用 LVM 存储来提供动态持久性卷存储时,如果配置不正确,LVM 存储可能无法恢复持久性卷内容。
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
在 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.6.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.6.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