4.2. OADP 发行注记
4.2.1. OADP 1.4 发行注记
OpenShift API for Data Protection (OADP) 的发行注记介绍了新的功能和增强功能、已弃用的功能、产品建议、已知问题和解决问题。
有关 OADP 的更多信息,请参阅 OpenShift API for Data Protection (OADP) FAQ
4.2.1.1. OADP 1.4.1 发行注记
OpenShift API for Data Protection (OADP) 1.4.1 发行注记列出了新功能、解决的问题和程序错误,以及已知的问题。
4.2.1.1.1. 新功能
新的 DPA 字段以更新客户端 qps 和 burst
现在,您可以使用新的数据保护应用程序 (DPA) 字段更改 Velero Server Kubernetes API 查询每秒(qps)和突发(burst)值。新的 DPA 字段是 spec.configuration.velero.client-qps
和 spec.configuration.velero.client-burst
,它们都默认为 100。OADP-4076
使用 Kopia 启用非默认算法
在这个版本中,您可以在 Kopia 中配置哈希、加密和分割程序算法来选择非默认选项来优化不同备份工作负载的性能。
要配置这些算法,在 DataProtectionApplication (DPA) 配置的 podConfig
部分中设置 velero
pod 的 env
变量。如果没有设置此变量,或者选择了一个不被支持的算法,Kopia 将默认为其标准算法。OADP-4640
4.2.1.1.2. 已解决的问题
现在可以成功恢复没有 pod 的备份
在以前的版本中,恢复没有 pod 的备份,并将 StorageClass VolumeBindingMode
设置为 WaitForFirstConsumer
会导致 PartiallyFailed
状态出现错误:fail to patch dynamic PV, err: context deadline exceeded
。在这个版本中,会跳过对动态 PV 进行补丁,并可以成功恢复备份,不再会出现 PartiallyFailed
状态。OADP-4231
PodVolumeBackup CR 现在显示正确的消息
在以前的版本中,PodVolumeBackup
自定义资源 (CR) 会生成不正确的消息:get a podvolumebackup with status "InProgress" during the server starting, mark it as "Failed"
。在这个版本中,生成的消息是:
found a podvolumebackup with status "InProgress" during the server starting, mark it as "Failed".
现在,可以使用 DPA 覆盖 imagePullPolicy
在以前的版本中,OADP 将所有镜像的 imagePullPolicy
参数都设置为 Always
。在这个版本中,OADP 会检查每个镜像是否包含了 sha256
或 sha512
摘要,然后将 imagePullPolicy
设置为 IfNotPresent
; 否则 imagePullPolicy
被设置为 Always
。现在,您可以使用新的 spec.containerImagePullPolicy
DPA 字段覆盖此策略。OADP-4172
现在,如果初始更新失败,OADP Velero 现在可以重试更新恢复状态
在以前的版本中,OADP Velero 无法更新恢复的 CR 状态。这会无限期保留 InProgress
状态。依赖于备份和恢复 CR 状态以确定完成会失败的组件。在这个版本中,恢复的恢复 CR 状态可以正确地进入 Completed
或 Failed
状态。OADP-3227
从不同的集群恢复 BuildConfig 构建会成功,且没有任何错误
在以前的版本中,当从其他集群执行 BuildConfig
Build 资源恢复时,应用程序会在内部镜像 registry 的 TLS 验证过程中生成一个错误。错误信息 failed to verify certificate: x509: certificate signed by unknown authority
。在这个版本中,BuildConfig
构建资源恢复到不同的集群可以成功进行,而不会生成 failed to verify certificate
错误。OADP-4692
恢复空的 PVC 可以成功
在以前的版本中,在恢复空的持久性卷声明 (PVC) 时,下载数据会失败。这个失败带有以下错误:
data path restore failed: Failed to run kopia restore: Unable to load snapshot : snapshot not found
在这个版本中,在恢复空 PVC 时,下载数据的过程会正确处理,不会生成错误信息。OADP-3106
CSI 和 DataMover 插件中没有 Velero 内存泄漏的问题
在以前的版本中,使用 CSI 和 DataMover 插件会导致 Velero 内存泄漏。当备份结束时,Velero 插件实例不会被删除,在 Velero pod 中生成 内存不足(OOM
)条件前,内存泄漏会消耗内存。在这个版本中,当使用 CSI 和 DataMover 插件时,不会出现 Velero 内存泄漏的问题。OADP-4448
在相关 PV 被释放前,post-hook 操作不会启动
在以前的版本中,由于 Data Mover 操作的异步性,在 Data Mover 持久性卷声明 (PVC) 释放相关 pod 的持久性卷 (PV) 前,可能会尝试进行 post-hook 操作。此问题会导致备份失败,并显示 PartiallyFailed
状态。在这个版本中,在 Data Mover PVC 发布相关的 PV 前,才会启动 post-hook 操作,从而避免出现 PartiallyFailed
备份状态。OADP-3140
在带有超过 37 个字符的命名空间中部署 DPA 可以正常工作
当您在带有超过 37 个字符的命名空间中安装 OADP Operator 来创建新的 DPA 时,标记 "cloud-credentials" Secret 会失败,DPA 报告以下错误:
The generated label name is too long.
在这个版本中,在名称中有超过 37 个字符的命名空间中创建 DPA 不会失败。OADP-3960
恢复可以通过覆盖超时错误成功完成
在以前的版本中,在大规模环境中,恢复操作会导致 Partiallyfailed
状态并带有错误:fail to patch dynamic PV, err: context deadline exceeded
。在这个版本中,可以使用 resourceTimeout
Velero 服务器参数覆盖这个超时错误,从而使恢复可以成功完成。OADP-4344
有关本发行版本中解决的所有问题的完整列表,请参阅 JIRA 中的 OADP 1.4.1 解决的问题列表。
4.2.1.1.3. 已知问题
恢复 OADP 后,Cassandra 应用程序 pod 进入 CrashLoopBackoff
状态
在 OADP 恢复后,Cassandra 应用程序 pod 可能会进入 CrashLoopBackoff
状态。要临时解决这个问题,删除在恢复 OADP 后返回错误 CrashLoopBackoff
状态的 StatefulSet
pod。然后,StatefulSet
控制器会重新创建这些 pod 并正常运行。OADP-4407
引用 ImageStream 的部署不会被正确恢复,并导致 pod 和卷内容被破坏
在文件系统备份(FSB)恢复操作中,引用 ImageStream
的 Deployment
资源没有被正确恢复。恢复运行 FSB 的 pod,postHook
会被提前终止。
在恢复操作过程中,OpenShift Container Platform 控制器会使用一个更新的 ImageStreamTag
哈希更新 Deployment
资源中的 spec.template.spec.containers[0].image
字段。更新会触发推出新的 pod,终止 velero
运行 FSB 和 post-hook 的 pod。有关镜像流触发器的更多信息,请参阅触发镜像流更新。
这个行为的临时解决方案分为两个步骤:
执行排除了
Deployment
资源的恢复,例如:$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --exclude-resources=deployment.apps
第一次恢复成功后,通过包含这些资源来执行第二次恢复,例如:
$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --include-resources=deployment.apps
4.2.1.2. OADP 1.4.0 发行注记
OpenShift API for Data Protection (OADP) 1.4.0 发行注记列出了已解决的问题和已知问题。
4.2.1.2.1. 已解决的问题
恢复在 OpenShift Container Platform 4.16 中可以正常工作
在以前的版本中,当恢复已删除的应用程序命名空间时,恢复操作部分失败,在 OpenShift Container Platform 4.16 中会出现 resource name may not be empty
错误。在这个版本中,恢复在 OpenShift Container Platform 4.16 中可以正常工作。OADP-4075
Data Mover backups 在 OpenShift Container Platform 4.16 集群中可以正常工作
在以前的版本中,Velero 使用早期版本的 SDK,其中 Spec.SourceVolumeMode
字段不存在。因此,在带有 v4.2 版本的外部快照器上的 OpenShift Container Platform 4.16 集群中,Data Mover backups 会失败。在这个版本中,外部快照升级到 v7.0 及更新版本。因此,在 OpenShift Container Platform 4.16 集群中备份不会失败。OADP-3922
有关本发行版本中解决的所有问题的完整列表,请参阅 JIRA 中的 OADP 1.4.0 解决的问题列表。
4.2.1.2.2. 已知问题
在没有为 MCG 设置 checksumAlgorithm 时,备份会失败
在对任何使用 Noobaa 作为备份位置的应用程序进行备份时,如果未设置 checksumAlgorithm
配置参数,备份会失败。要解决这个问题,如果您在 Backup Storage Location (BSL) 配置中没有为 checksumAlgorithm
提供值,则会添加一个空值。空值只为使用数据保护应用程序 (DPA) 自定义资源 (CR) 创建的 BSLs 添加,如果使用任何其他方法创建 BSL,则不会添加这个值。OADP-4274
有关本发行版本中所有已知问题的完整列表,请参阅 JIRA 中的 OADP 1.4.0 已知问题 列表。
4.2.1.2.3. 升级备注
始终升级到下一个次版本。不要 跳过版本。要升级到更新的版本,请一次只升级一个频道。例如,若要从 OpenShift API for Data Protection (OADP) 1.1 升级到 1.3,首先升级到 1.2,然后再升级到 1.3。
4.2.1.2.3.1. 从 OADP 1.3 更改为 1.4
Velero 服务器已从 1.12 版本更新至 1.14。请注意,数据保护应用程序 (DPA) 没有改变。
这会更改以下内容:
-
velero-plugin-for-csi
代码现在包括在 Velero 代码中,这意味着插件不再需要init
容器。 - Velero 将客户端 Burst 和 QPS 默认值分别从 30 和 20 改为 100 和 100。
velero-plugin-for-aws
插件更新了BackupStorageLocation
对象(BSLs)中的spec.config.checksumAlgorithm
字段的默认值,从""
(不计算 checksum) 改为CRC32
算法。知道 checksum 算法类型只能用于 AWS。几个 S3 供应商要求通过将 checksum 算法设置为""
来禁用md5sum
。使用您的存储供应商确认md5sum
算法支持和配置。在 OADP 1.4 中,为此配置在 DPA 中创建 BSL 的默认值为
""
。这个默认值表示没有检查md5sum
,它与 OADP 1.3 一致。对于在 DPA 中创建的 BSL,使用 DPA 中的spec.backupLocations[].velero.config.checksumAlgorithm
字段更新它。如果您的 BSLs 在 DPA 之外创建,您可以使用 BSLs 中的spec.config.checksumAlgorithm
来更新此配置。
4.2.1.2.3.2. 备份 DPA 配置
您必须备份当前的 DataProtectionApplication
(DPA) 配置。
流程
运行以下命令来保存您当前的 DPA 配置:
示例命令
$ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
4.2.1.2.3.3. 升级 OADP Operator
在升级 OpenShift API for Data Protection (OADP) Operator 时,请使用以下步骤。
流程
-
将 OADP Operator 的订阅频道从
stable-1.3
改为stable-1.4
。 - 等待 Operator 和容器更新并重启。
其他资源
4.2.1.2.4. 将 DPA 转换为新版本
要从 OADP 1.3 升级到 1.4,则不需要数据保护应用程序 (DPA) 更改。
4.2.1.2.5. 验证升级
使用以下步骤验证升级。
流程
运行以下命令,查看 OpenShift API for Data Protection (OADP) 资源来验证安装:
$ oc get all -n openshift-adp
输出示例
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
运行以下命令,验证
DataProtectionApplication
(DPA) 是否已协调:$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
输出示例
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
验证
type
被设置为Reconciled
。 运行以下命令,验证备份存储位置并确认
PHASE
为Available
:$ oc get backupStorageLocation -n openshift-adp
输出示例
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true