15.4. 使用 GitOps ZTP 为单节点 OpenShift 集群执行基于镜像的升级


您可以使用 hub 集群中的单个资源 ImageBasedGroupUpgrade 自定义资源(CR)通过所有阶段在所选受管集群组上管理基于镜像的升级。Topology Aware Lifecycle Manager (TALM)协调 ImageBasedGroupUpgrade CR,并创建底层资源来完成定义的阶段转换,可以在手动控制或完全自动化升级流程中。

有关基于镜像的升级的更多信息,请参阅"为单节点 OpenShift 集群使用基于镜像的升级"。

15.4.1. 在 hub 上使用 ImageBasedGroupUpgrade CR 大规模管理基于镜像的升级

ImageBasedGroupUpgrade CR 结合了 ImageBasedUpgradeClusterGroupUpgrade 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

1
要升级的集群。
2
目标平台版本、要使用的 seed 镜像以及访问镜像所需的 secret。
3
可选:将不在 seed 镜像中的额外清单应用到目标集群。另外,为自定义目录源应用 ConfigMap 对象。
4
包含 OADP BackupRestore CR 的 ConfigMap 资源列表。
5
升级计划详情。
6
批处理中要更新的集群数量。
7
完成操作的超时限制(以分钟为单位)。

15.4.1.1. 支持的操作组合

操作是 TALM 在所选集群组的升级计划步骤中完成的阶段转换列表。ImageBasedGroupUpgrade CR 中的每个 action 条目都是一个单独的步骤,一个步骤包含一个或几个共享同一 rollout 策略的操作。您可以通过将操作分成多个步骤来对每个操作的 rollout 策略进行更多控制。

这些操作可以在升级计划中以不同的方式合并,您可以稍后添加后续步骤。在向计划中添加步骤前,等待前面的步骤完成或失败。为在前面失步骤中失败的集群添加的添加步骤的第一个操作必须是 AbortRollback

重要

您无法从持续计划中删除操作或步骤。

下表显示了针对 rollout 策略的不同控制级别的计划:

表 15.5. 升级计划示例
计划示例描述
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 阶段,在所选集群上取消升级失败 PrepUpgrade 操作。
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。

流程

  1. 在 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
    1
    要升级的集群。
    2
    目标平台版本、要使用的 seed 镜像以及访问镜像所需的 secret。
    3
    可选:将不在 seed 镜像中的额外清单应用到目标集群。另外,为自定义目录源应用 ConfigMap 对象。
    4
    包含 OADP BackupRestore CR 的 ConfigMap 资源列表。
    5
    升级计划详情。
  2. 在 hub 集群中运行以下命令来应用创建的文件:

    $ oc apply -f <filename>.yaml
  3. 在 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 阶段。与所选集群中升级相关的资源都会被删除。

  4. 可选:通过运行以下命令,将 AbortOnFailure 操作添加到现有的 ImageBasedGroupUpgrade CR 中:

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
    1. 运行以下命令继续监控状态更新:

      $ oc get ibgu -o yaml
  5. 运行以下命令,将操作添加到现有的 ImageBasedGroupUpgrade CR 中:

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
  6. 可选:通过运行以下命令,将 AbortOnFailure 操作添加到现有的 ImageBasedGroupUpgrade CR 中:

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
    1. 运行以下命令继续监控状态更新:

      $ oc get ibgu -o yaml
  7. 运行以下命令,将操作添加到现有的 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。

流程

  1. 在 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
    1
    要升级的集群。
    2
    目标平台版本、要使用的 seed 镜像以及访问镜像所需的 secret。
    3
    可选:将不在 seed 镜像中的额外清单应用到目标集群。另外,为自定义目录源应用 ConfigMap 对象。
    4
    包含 OADP BackupRestore CR 的 ConfigMap 资源列表。
    5
    升级计划详情。
    6
    批处理中要更新的集群数量。
    7
    完成操作的超时限制(以分钟为单位)。
  2. 在 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 集群。

流程

  1. 在 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 阶段。

  2. 在 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 集群。

流程

  1. 在 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
  2. 在 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
    1
    可选:如果您需要从 OADP Operator 收集更多信息,请添加这个选项。
    2
    可选:如果您需要从 SR-IOV Operator 收集更多信息,请添加这个选项。

15.4.6.2. AbortFailed 或 FinalizeFailed 错误

问题

在完成阶段或停止 Prep 阶段时,生命周期代理会清理以下资源:

  • 不再需要的 Stateroot
  • 预缓存资源
  • OADP CR
  • ImageBasedUpgrade CR

如果 Lifecycle Agent 无法执行上述步骤,它将过渡到 AbortFailedFinalizeFailed 状态。条件消息和日志显示哪些步骤失败。

错误信息示例

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

解决方案
  1. 检查日志,以确定发生失败的原因。
  2. 要提示生命周期代理重试清理,请将 lca.openshift.io/manual-cleanup-done 注解添加到 ImageBasedUpgrade CR。

    观察此注解后,生命周期代理会重试清理,如果成功,ImageBasedUpgrade 阶段会过渡到 Idle

    如果清理再次失败,您可以手动清理资源。

15.4.6.2.1. 手动清理 stateroot
问题
Prep 阶段停止,生命周期代理会清理新的 stateroot。在成功升级或回滚后最终调整时,生命周期代理会清理旧的 stateroot。如果此步骤失败,建议您检查日志以确定失败的原因。
解决方案
  1. 运行以下命令,检查 stateroot 中是否有现有部署:

    $ ostree admin status
  2. 如果存在,请运行以下命令清理现有部署:

    $ ostree admin undeploy <index_of_deployment>
  3. 清理 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 注解,生命周期代理可以成功清理备份资源。
解决方案
  1. 运行以下命令检查后端连接:

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    输出示例

    NAME                          PHASE       LAST VALIDATED   AGE   DEFAULT
    dataprotectionapplication-1   Available   33s              8d    true

  2. 删除所有备份资源,然后将 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 相关的字段
问题

应用程序的预期资源会被恢复,但升级后持久性卷内容不会被保留。

  1. 在 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

  2. 在 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

1
要保留应用程序的持久性卷,您必须将 restorePV 设置为 true
2
要为应用程序保留持久性卷,您必须配置本节,如下所示。

15.4.6.4. 调试失败的备份和恢复 CR

问题
工件的备份或恢复失败。
解决方案

您可以调试 BackupRestore CR,并使用 Velero CLI 工具检索日志。Velero CLI 工具比 OpenShift CLI 工具提供更详细的信息。

  1. 运行以下命令描述包含错误的 Backup CR:

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
  2. 运行以下命令描述包含错误的 Restore CR:

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
  3. 运行以下命令,将备份的资源下载到本地目录:

    $ 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
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.