企业官网建设流程全解析

Velero 发布前手工测试体系解析：从安装、备份恢复到多 Provider 场景的验证清单

【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero

Velero 在拥有完善的单元测试与端到端自动化测试之外，每个发布版本仍需执行人工（Manual）测试，以覆盖自动化难以模拟的真实环境差异。本文基于 Velero v1.11 发布周期中的手工测试要求文档（site/content/docs/v1.11/manual-testing.md），完整梳理发布就绪（release-ready）所必须验证的测试用例清单，并结合当前仓库中的 CLI 参数实现、控制器源码与test/e2e自动化用例，深入解释每一项手工测试背后的功能原理与验证方法，帮助你在执行发布验证或设计自测方案时有据可依。

为什么 Velero 发布仍需手工测试

文档开篇即说明了手工测试存在的根本原因：

Although we have automated unit and end-to-end tests, there is still a need for Velero to undergo manual tests during a release.（尽管已有自动化单元与端到端测试，发布期间 Velero 仍需要手工测试。）

原因可以从仓库结构中得到印证。当前仓库的test/e2e目录覆盖了资源过滤、调度、备份生命周期、节点代理、迁移等大量场景（见 test/e2e/README.md），但这些用例依赖本地或 CI 环境中的特定 Provider 配置。而 Velero 的备份链路强依赖外部云能力——对象存储（BackupStorageLocation）与卷快照（VolumeSnapshotLocation）——不同云厂商的组合、凭据、权限、API 行为差异很难被一套自动化脚本穷举。因此，manual-testing.md把发布前必须由人执行的测试用例划分为两大块：当前必须执行的测试用例与计划在未来版本覆盖的测试用例。

当前测试用例：Install、Upgrade 与基础功能

安装（Install）：CRD 与 Kubernetes 版本兼容性验证

第一类用例关注安装环节。文档要求验证Velero CRD 与其支持的 Kubernetes 最早、最新版本均兼容，v1.11 发布周期对应的版本区间是：

• Kubernetes v1.12（支持范围内最早版本）
• Kubernetes v1.20（支持范围内最新版本）

也就是说，手工验证者需要在 v1.12 与 v1.20 两个集群上分别安装 Velero，确认 config/crd 下的各资源定义（如 Backup、Restore、BackupStorageLocation、VolumeSnapshotLocation、Schedule 等 CRD）能被对应版本 API Server 正确接受，且核心资源创建/删除流程不报错。注意这一点是 v1.11 文档的历史口径，实际支持矩阵请以你所发布版本对应的发布说明为准。

升级（Upgrade）：验证升级文档本身可用

第二类用例只有一条，却非常关键：验证 Velero 升级步骤文档（upgrade instructions）确实可行。这意味着手工测试不只是测试代码，而是把发布说明当作可执行手册逐步执行：从旧版本安装 Velero → 执行备份 → 按文档步骤升级到新版本 → 验证旧备份仍可被新版本读取。

基础功能（Basic functionality）

基础功能用例要求"Backup and Restore"系列测试在 Velero 维护官方插件的所有 Provider 上全部跑通，v1.11 文档列出的 Provider 为：

• AWS
• GCP
• Microsoft Azure
• VMware vSphere

四个核心验证点如下：

1. 基于 Volume Snapshots 的备份与恢复：创建使用卷快照（CSI/Snapshotter 插件路径）的备份，再执行恢复，验证快照数据完整还原。
2. 基于 File System Backup 的备份与恢复：创建使用文件系统备份（--default-volumes-to-fs-backup或 Pod Volume Backup 路径）的备份并恢复，验证块级别之外的文件系统级数据路径。
3. 跨集群恢复：在集群 A 中对某工作负载执行备份，在新集群 B 上恢复，验证 Velero 的核心使用场景——迁移。
4. 向后兼容恢复：最新版安装必须能恢复最近 3 个版本创建的备份。文档给出的示例是：安装 Velero 1.6 后，用它恢复 v1.3、v1.4、v1.5 创建的备份。这条用例保证备份归档格式（tar 内各版本化的 JSON + 数据块）在版本演进中保持向后可读。

从源码结构看，备份项的收集与分组由 pkg/backup/item_collector.go 负责，归档的解析与提取由 pkg/archive/ 包提供（parser.go、extractor.go、filesystem.go）。跨集群恢复之所以可行，正是因为归档是自包含的：资源清单存于归档文件，卷数据由快照或文件系统备份独立管理，恢复端只需凭据与目标 BSL/快照位置可用。

多 Provider 协作场景（Working with Multiple Providers）

多 Provider 用例专门验证 Velero 在与多个云厂商同时交互时的行为，文档列出三条：

1. 同一 Provider、多个 BackupStorageLocation、独立凭据：例如两个都指向 AWS S3 但使用不同 AWS 凭据/桶的 BSL，验证备份能正确落到指定 BSL，且凭据隔离生效。
2. 不同 Provider、多个 BackupStorageLocation、独立凭据：例如一个 BSL 指 AWS S3、另一个指 Azure Blob，验证对象存储插件按 BSL 的 Provider 字段路由。
3. 快照与对象存储来自不同 Provider：这是最容易踩坑的组合场景。文档示例是——用 AWS 作为 VolumeSnapshotLocation（卷快照留在 AWS EBS），同时用 Azure Blob Storage 作为 BackupStorageLocation（对象存储与文件数据存 Azure）。验证点在于两条链路的凭据与插件互不干扰、恢复时也能跨源取回数据。

这个场景在 v1.11 及以后的演进中部分被仓库内的新测试覆盖：test/e2e/migration/migration.go 覆盖了跨集群备份迁移（backup migration），而test/util/providers下的 Provider 抽象（test/util/ 中 AWS/Azure/GCP/vSphere 实现）使得同一套用例可以在不同云环境复用，这正是手工用例向自动化收敛的产物。

未来测试用例：文档中的规划清单

文档把"当前发布不执行、但未来希望覆盖"的用例分为若干小节。这些条目是理解 Velero 质量关注面的重要索引——下面逐节给出原文要求，并对照当前仓库标注其现状与源码依据。

调度（Schedules）

原文要求：验证 Schedule 在创建时立即触发一次备份（schedule-skip-immediately之前的默认行为），并且按正确的频率持续创建 Backup 资源。

现状：该用例在当前仓库已有自动化实现，位于 test/e2e/schedule/ 目录：periodical.go验证周期性备份触发，in_progress.go验证调度行为，另有ordered_resources.go覆盖资源排序。调度本身的执行逻辑在 pkg/controller/schedule_controller.go。

资源管理（Resource management）

原文列了五条资源管理用例：

• 已删除的备份能从对象存储中被成功移除；
• 对象存储中已被外部移除的备份，仍可通过velero delete backup删除其 CR 记录；
• 已删除备份关联的 Volume Snapshots 被一并清理；
• 超过 TTL 的备份被自动删除；
• 对象存储中已存在但集群中不存在的备份能被同步回 Velero（即 BSL 与 Backup CR 对账）。

这些用例在当前仓库中均已落地为 e2e 测试：

• TTL 自动过期删除：test/e2e/backups/ttl.go。测试将备份ttl设为 10 分钟，并把 Velero 的 GC 频率GCFrequency设为 4 分钟（"Make sure GCFrequency is shorter than backup TTL"），随后验证备份被自动清理。
• BSL 备份同步：test/e2e/backups/sync_backups.go，对应文档注释中引用的 issue #4253（备份存在于 BSL 但集群中无 CR 时的一致性）。
• 备份删除链路：test/e2e/backups/deletion.go 覆盖DeleteBackupRequest流程。

底层实现上，TTL 过期的判定发生在 pkg/controller/gc_controller.go：gcReconciler默认每 60 分钟（defaultGCFrequency）巡检一次 Backup，为过期备份创建DeleteBackupRequest资源。删除请求的异步处理由 pkg/controller/backup_deletion_controller.go 与 pkg/controller/backup_finalizer_controller.go 协作完成——先删对象存储与快照，再摘除 finalizer 删除 Backup CR。理解这条链路后，手工测试时就能定位"备份删了但对象存储里还在"这类问题出在哪个控制器。

备份仓库维护（Backup repository test cases）

原文要求：验证备份仓库（backup repository）维护按指定间隔执行。对应手动验证的是 Repository Maintenance（Kopia 统一仓库的 compaction/snapshot maintenance）是否按RepositoryMaintenanceConfig中的 interval 触发维护 Job。当前仓库中该功能的 e2e 用例位于 test/e2e/repomaintenance/repo_maintenance_config.go，控制器与 Job 配置逻辑位于 pkg/repository/maintenance/ 与 pkg/repository/config/。

Backup Hooks

原文要求验证四类备份钩子：

• Pod 注解（annotation）方式声明的 pre-backup 钩子；
• Backup spec（spec.hooks）方式声明的 pre-backup 钩子；
• Pod 注解方式声明的 post-backup 钩子；
• Backup spec 方式声明的 post-backup 钩子。

验证点是钩子在备份执行的正确时机被触发（pre 在快照/采集前，post 在备份完成后）。实现侧，钩子状态跟踪位于 pkg/hook/：hook_tracker.go 维护钩子状态机，item_hook_handler.go 在备份/恢复项处理中调用钩子，wait_exec_hook_handler.go 负责exec钩子的容器内执行与等待。手工测试时，可创建带pre.hook.velero.io/pre-backup注解的 Pod 或带spec.hooks.backup的 Backup 资源，执行备份后检查日志中钩子输出，确认注解与 spec 两条声明路径等效。

Restore Hooks

原文要求验证五类恢复钩子：

• Pod 注解声明的 InitContainer 恢复钩子；
• Restore spec 声明的 InitContainer 钩子；
• Restore spec 声明的 InitContainer 钩子且恢复中包含 File System Backup 卷（验证钩子与 restic 类文件恢复的交互）；
• Pod 注解声明的 Exec 恢复钩子；
• Restore spec 声明的 Exec 钩子。

仓库中已有对应的自动化用例 test/e2e/basic/restore_exec_hooks.go 覆盖 exec 恢复钩子场景。恢复钩子的执行入口在 pkg/restore/ 包的钩子处理逻辑中（与备份钩子共享 pkg/hook/ 的框架）。手工验证的关键观察点是：InitContainer 钩子会修改恢复出的 Pod 定义（把钩子容器注入 initContainers），Exec 钩子则在恢复完成后对 Pod 执行命令；两种声明方式（注解 vs spec）应在效果上等效。

资源过滤（Resource filtering）：新旧两套过滤参数的兼容边界

原文档最后一节，也是 v1.11 版本特性最强的一节，要求验证备份与恢复正确应用以下资源过滤器：

• --include-namespaces
• --include-resources
• --include-cluster-resources
• --exclude-namespaces
• --exclude-resources
• velero.io/exclude-from-backup=true标签

并要求特别验证v1.11 新增的四项过滤器：

• --exclude-cluster-scoped-resources
• --include-cluster-scoped-resources
• --exclude-namespace-scoped-resources
• --include-namespace-scoped-resources

文档明确强调：新过滤器只对备份（backup）生效，且不能与旧过滤器（--include-resources、--exclude-resources、--include-cluster-resources）混用。

CLI 参数实现与互斥校验

在 pkg/cmd/cli/backup/create.go 中可以看到四个新参数在velero backup create上的注册，帮助文本本身就写明了互斥关系：

• --include-cluster-scoped-resources：纳入备份的集群级资源，格式resource.group（如storageclasses.storage.k8s.io），*表示全部；与include-resources、exclude-resources、include-cluster-resources互斥；
• --exclude-cluster-scoped-resources：排除集群级资源，语义对称；
• --include-namespace-scoped-resources/--exclude-namespace-scoped-resources：对命名空间级资源（如deployments.apps）做包含/排除，同样与上述旧参数互斥。

同一文件中（create.go 附近）还有参数校验逻辑：一旦同时使用了新旧两套过滤参数，命令会报错并提示新参数与旧参数不可共存。参数行为测试见 pkg/cmd/cli/backup/create_test.go。

过滤逻辑的底层实现

从源码结构看，过滤最终落在备份项收集阶段。pkg/backup/item_collector.go 中的nsTracker维护"哪些命名空间被跟踪"的集合：它综合 Backup 的 namespace include/exclude 过滤、labelSelector与orLabelSelector选中的命名空间，取并集后只跟踪 Active 阶段的命名空间（代码中可见Skip namespace %s because it's not in Active phase的日志分支）；资源级过滤则依据 GroupResource 与velero.io/exclude-from-backup标签在收集时丢弃不匹配项。理解了这一层，手工验证"过滤是否生效"就有了明确的检查点：备份后列出归档内资源清单（velero backup describe <name>或下载归档查看），确认被排除的 GroupResource/命名空间确实缺席。

自动化的过滤测试矩阵

手工用例中列举的每一类过滤器，在当前仓库的 test/e2e/resource-filtering/ 目录都有对应自动化用例：

以 exclude_resources.go 为例，用例在多个测试命名空间中创建资源，然后执行velero backup create ... --include-namespaces <list> --exclude-resources secrets --default-volumes-to-fs-backup --wait，恢复后断言"被排除的资源不出现、其余资源完整"。这为手工测试者提供了可直接复刻的命令行范式。

如何把这份清单转化为可执行的发布验证方案

综合原文档与仓库现状，执行一次发布手工验证可以按如下顺序展开，每一步都能在仓库中找到对应的自动化用例作为"标准答案"参照：

1. 安装验证：在文档指定版本区间的首/末两个 Kubernetes 版本上安装 Velero，确认 CRD 与应用正常启动；
2. 升级验证：严格按升级文档从上一版本升级，确认数据与服务不中断；
3. 基础功能矩阵：在每个维护的 Provider（AWS/GCP/Azure/vSphere）上，分别执行卷快照备份恢复、文件系统备份恢复、跨集群恢复、旧版本（最近 3 个）备份的恢复；
4. 多 BSL/多 Provider 组合：覆盖同 Provider 多 BSL、多 Provider 多 BSL、快照与对象存储异源三类组合；
5. 回归清单：按"未来测试用例"一节逐项核对——调度触发频率、备份删除（含对象存储清理与快照清理）、TTL 过期、BSL 同步、仓库维护间隔、四类备份钩子、五类恢复钩子；
6. 资源过滤矩阵：新旧两套参数分别验证（不可混用），标签排除与命名空间/资源级过滤全部过一遍，检查方法参考test/e2e/resource-filtering各用例的断言逻辑。

小结

这份 v1.11 手工测试文档虽然篇幅不长，但精确勾勒了 Velero 的质量关注面：版本兼容性（CRD × Kubernetes 版本矩阵）、数据路径双轨（Volume Snapshot 与 File System Backup）、跨集群恢复能力、跨版本备份格式兼容、多 Provider 组合，以及资源过滤这类用户最直接的 CLI 行为。值得注意的是，文档中"未来测试用例"里的绝大多数条目如今都已在test/e2e中以自动化形式落地——从 test/e2e/backups/ 的 TTL/同步/删除用例，到 test/e2e/resource-filtering/ 的完整过滤矩阵，再到 test/e2e/schedule/ 与 test/e2e/repomaintenance/——阅读这些用例，既可以直接获得手工测试的脚本化参考，也能顺藤摸瓜理解 pkg/controller/ 中各控制器的真实行为边界。

【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero