OpenShift 文档正在迁移，不久后将仅在 docs.redhat.com（所有 Red Hat 产品文档的所在地）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

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

您可以使用集线器集群上的单个资源，即ImageBasedGroupUpgrade自定义资源 (CR)，通过所有阶段来管理所选托管集群组上的基于镜像的升级。拓扑感知生命周期管理器 (TALM) 会协调ImageBasedGroupUpgrade CR 并创建底层资源以完成定义的阶段转换，无论是在手动控制的升级流程中还是在完全自动化的升级流程中。

有关基于镜像的升级的更多信息，请参阅“了解单节点 OpenShift 集群的基于镜像的升级”。

其他资源

使用集线器上的 ImageBasedGroupUpgrade CR 大规模管理基于镜像的升级

ImageBasedGroupUpgrade CR 结合了ImageBasedUpgrade和ClusterGroupUpgrade API。例如，您可以使用ImageBasedGroupUpgrade API 定义集群选择和部署策略，方法与ClusterGroupUpgrade API 相同。阶段转换与ImageBasedUpgrade API 不同。ImageBasedGroupUpgrade API 允许您将多个阶段转换（也称为操作）组合到一个步骤中，这些步骤共享一个部署策略。

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 目标平台版本、要使用的种子镜像以及访问镜像所需的密钥。
3 可选：将种子镜像中不存在的其他清单应用于目标集群。还为自定义目录源应用ConfigMap对象。
4 包含 OADP Backup 和 Restore CR 的ConfigMap资源。
5 升级计划详情。
6 批量更新的集群数量。
7 完成操作的超时限制（以分钟为单位）。

支持的操作组合

操作是指 TALM 在所选集群组的升级计划步骤中完成的一系列阶段转换。ImageBasedGroupUpgrade CR 中的每个action条目都是一个单独的步骤，一个步骤包含一个或多个共享相同部署策略的操作。通过将操作分成步骤，您可以更好地控制每个操作的部署策略。

这些操作可以在您的升级计划中以不同的方式组合，您以后可以添加后续步骤。在向计划中添加步骤之前，请等待之前的步骤完成或失败。对于在先前步骤中失败的集群，添加步骤的第一个操作必须是Abort或Rollback。

您无法从正在进行的计划中删除操作或步骤。

下表显示了不同级别部署策略控制的示例计划。

表 1. 示例升级计划
示例计划 描述 
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"]

集群选择标签

使用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操作。

成功取消或完成升级后，将删除集群标签。

状态监控

ImageBasedGroupUpgrade CR 通过对所有集群的全面状态报告（在一个地方汇总）来确保更好的监控体验。您可以监控以下操作：

status.clusters.completedActions

显示plan部分中定义的所有已完成操作。

status.clusters.currentAction

显示当前正在进行的所有操作。

status.clusters.failedActions

显示所有失败的操作以及详细的错误消息。

分步骤大规模执行托管集群的基于镜像的升级

对于需要更好地控制升级何时中断您的服务的情况，您可以使用ImageBasedGroupUpgrade CR 升级一组托管集群，并在上一步完成后添加操作。评估上一步的结果后，您可以进入下一个升级阶段，或在整个过程中排查任何失败的步骤。

仅支持支持的操作组合中列出的某些操作组合。
先决条件

  • 您已以具有cluster-admin权限的用户身份登录到 hub 集群。

  • 您已为基于镜像的升级中使用的资源创建了策略和ConfigMap对象。

  • 您已通过 hub 集群在所有托管集群上安装了 Lifecycle Agent 和 OADP Operators。

流程

  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 目标平台版本、要使用的种子镜像以及访问镜像所需的密钥。
    3 可选：将种子镜像中不存在的其他清单应用于目标集群。还为自定义目录源应用ConfigMap对象。
    4 包含 OADP Backup 和 Restore 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. 可选：通过运行以下命令向您现有的ImageBasedGroupUpgrade CR 添加AbortOnFailure操作。

    $ 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. 可选：通过运行以下命令向您现有的ImageBasedGroupUpgrade CR 添加AbortOnFailure操作。

    $ 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
# ...
其他资源

一步完成托管集群的基于镜像的升级

对于服务中断不是问题的情况，您可以使用 `ImageBasedGroupUpgrade` CR 升级一组托管集群，该 CR 将多个操作组合在一个步骤中，并采用一种部署策略。使用单一部署策略可以缩短升级时间，但您只能在升级计划完成后才能排查集群故障。

先决条件

  • 您已以具有cluster-admin权限的用户身份登录到 hub 集群。

  • 您已为基于镜像的升级中使用的资源创建了策略和ConfigMap对象。

  • 您已通过 hub 集群在所有托管集群上安装了 Lifecycle Agent 和 OADP Operators。

流程

  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 目标平台版本、要使用的种子镜像以及访问镜像所需的密钥。
    3 可选：将种子镜像中不存在的其他清单应用于目标集群。还为自定义目录源应用ConfigMap对象。
    4 包含 OADP Backup 和 Restore 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
# ...

取消大规模托管集群上的基于镜像的升级

您可以取消已完成 `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
# ...
其他资源

回滚大规模托管集群上的基于镜像的升级

如果在成功升级后遇到无法解决的问题，请回滚一组托管集群上的更改。您需要创建一个单独的 `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
# ...
其他资源

使用 Lifecycle Agent 排查基于镜像的升级问题

对受问题影响的托管集群执行故障排除步骤。

如果您正在使用ImageBasedGroupUpgrade CR 来升级您的集群，请确保在对托管集群执行故障排除或恢复步骤后，lcm.openshift.io/ibgu-<stage>-completed或lcm.openshift.io/ibgu-<stage>-failed集群标签已正确更新。这确保 TALM 继续管理集群的基于镜像的升级。

收集日志

您可以使用 `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 收集更多信息，请添加此选项。

`AbortFailed` 或 `FinalizeFailed` 错误

问题

在完成阶段或在 `Prep` 阶段停止进程时，Lifecycle Agent 会清理以下资源：

  • 不再需要的 Stateroot

  • 预缓存资源

  • OADP CRs

  • `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
解决方案

  1. 检查日志以确定失败的原因。

  2. 要提示 Lifecycle Agent 重试清理，请将 `lca.openshift.io/manual-cleanup-done` 注解添加到 `ImageBasedUpgrade` CR。

    观察到此注释后，Lifecycle Agent 将重试清理，如果成功，`ImageBasedUpgrade` 阶段将转换到 `Idle`。

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

手动清理 stateroot

问题

在 `Prep` 阶段停止时，Lifecycle Agent 会清理新的 stateroot。成功升级或回滚后完成时，Lifecycle Agent 会清理旧的 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}"

手动清理 OADP 资源

问题

由于 Lifecycle Agent 和 S3 后端之间的连接问题，OADP 资源的自动清理可能会失败。通过恢复连接并添加 `lca.openshift.io/manual-cleanup-done` 注解，Lifecycle Agent 可以成功清理备份资源。

解决方案

  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。

LVM 存储卷内容未恢复

当使用 LVM 存储提供动态持久卷存储时，如果配置不正确，LVM 存储可能无法恢复持久卷内容。

Backup CR 中缺少与 LVM 存储相关的字段

问题

您的 `Backup` CR 可能缺少恢复持久卷所需的字段。您可以检查应用程序 pod 中的事件以确定您是否遇到此问题，方法是运行以下命令：

$ oc describe pod <your_app_name>
显示 Backup CR 中缺少与 LVM 存储相关的字段的示例输出
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 要恢复应用程序的持久卷，必须按所示配置此部分。

Restore CR 中缺少与 LVM 存储相关的字段

问题

应用程序的预期资源已恢复，但升级后未保留持久卷内容。

  1. 枢轴前运行以下命令列出应用程序的持久卷：

    $ 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

  2. 枢轴后运行以下命令列出应用程序的持久卷：

    $ 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
1 要保留应用程序的持久卷，必须将 `restorePVs` 设置为 `true`。
2 要保留应用程序的持久卷，必须按所示配置此部分。

调试失败的 Backup 和 Restore CRs

问题

工件的备份或恢复失败。

解决方案

您可以使用 Velero CLI 工具调试 `Backup` 和 `Restore` CR 并检索日志。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