Velero 发布前手工测试体系解析从安装、备份恢复到多 Provider 场景的验证清单【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero 在拥有完善的单元测试与端到端自动化测试之外每个发布版本仍需执行人工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 与基础功能安装InstallCRD 与 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 为AWSGCPMicrosoft AzureVMware vSphere四个核心验证点如下基于 Volume Snapshots 的备份与恢复创建使用卷快照CSI/Snapshotter 插件路径的备份再执行恢复验证快照数据完整还原。基于 File System Backup 的备份与恢复创建使用文件系统备份--default-volumes-to-fs-backup或 Pod Volume Backup 路径的备份并恢复验证块级别之外的文件系统级数据路径。跨集群恢复在集群 A 中对某工作负载执行备份在新集群 B 上恢复验证 Velero 的核心使用场景——迁移。向后兼容恢复最新版安装必须能恢复最近 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 在与多个云厂商同时交互时的行为文档列出三条同一 Provider、多个 BackupStorageLocation、独立凭据例如两个都指向 AWS S3 但使用不同 AWS 凭据/桶的 BSL验证备份能正确落到指定 BSL且凭据隔离生效。不同 Provider、多个 BackupStorageLocation、独立凭据例如一个 BSL 指 AWS S3、另一个指 Azure Blob验证对象存储插件按 BSL 的 Provider 字段路由。快照与对象存储来自不同 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.gogcReconciler默认每 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 MaintenanceKopia 统一仓库的 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 specspec.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 定义把钩子容器注入 initContainersExec 钩子则在恢复完成后对 Pod 执行命令两种声明方式注解 vs spec应在效果上等效。资源过滤Resource filtering新旧两套过滤参数的兼容边界原文档最后一节也是 v1.11 版本特性最强的一节要求验证备份与恢复正确应用以下资源过滤器--include-namespaces--include-resources--include-cluster-resources--exclude-namespaces--exclude-resourcesvelero.io/exclude-from-backuptrue标签并要求特别验证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 its not in Active phase的日志分支资源级过滤则依据 GroupResource 与velero.io/exclude-from-backup标签在收集时丢弃不匹配项。理解了这一层手工验证过滤是否生效就有了明确的检查点备份后列出归档内资源清单velero backup describe name或下载归档查看确认被排除的 GroupResource/命名空间确实缺席。自动化的过滤测试矩阵手工用例中列举的每一类过滤器在当前仓库的 test/e2e/resource-filtering/ 目录都有对应自动化用例过滤维度自动化用例文件include-namespacesinclude_namespaces.goexclude-namespacesexclude_namespaces.goinclude-resourcesinclude_resources.goexclude-resourcesexclude_resources.govelero.io/exclude-from-backup标签exclude_label.go标签选择器label_selector.go命名空间通配符wildcard_namespaces.go以 exclude_resources.go 为例用例在多个测试命名空间中创建资源然后执行velero backup create ... --include-namespaces list --exclude-resources secrets --default-volumes-to-fs-backup --wait恢复后断言被排除的资源不出现、其余资源完整。这为手工测试者提供了可直接复刻的命令行范式。如何把这份清单转化为可执行的发布验证方案综合原文档与仓库现状执行一次发布手工验证可以按如下顺序展开每一步都能在仓库中找到对应的自动化用例作为标准答案参照安装验证在文档指定版本区间的首/末两个 Kubernetes 版本上安装 Velero确认 CRD 与应用正常启动升级验证严格按升级文档从上一版本升级确认数据与服务不中断基础功能矩阵在每个维护的 ProviderAWS/GCP/Azure/vSphere上分别执行卷快照备份恢复、文件系统备份恢复、跨集群恢复、旧版本最近 3 个备份的恢复多 BSL/多 Provider 组合覆盖同 Provider 多 BSL、多 Provider 多 BSL、快照与对象存储异源三类组合回归清单按未来测试用例一节逐项核对——调度触发频率、备份删除含对象存储清理与快照清理、TTL 过期、BSL 同步、仓库维护间隔、四类备份钩子、五类恢复钩子资源过滤矩阵新旧两套参数分别验证不可混用标签排除与命名空间/资源级过滤全部过一遍检查方法参考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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考