1. Velero 概述：项目背景、核心功能与 Kubernetes 原生资源的关系
1.1 项目背景：为什么需要 Velero？
Kubernetes 已成为容器编排的事实标准，但其有状态应用的数据持久化、集群级灾难恢复以及跨集群迁移等需求，原生并未提供完善的解决方案。Velero（原 Heptio Ark）由 Heptio 团队于 2017 年开源，后由 VMware 持续维护，旨在为 Kubernetes 集群提供一套开源、可扩展的备份、恢复与迁移工具。
Velero 的出现解决了以下核心痛点：
- 集群级灾备缺失：Kubernetes 原生缺乏对整个集群资源（Deployment、Service、ConfigMap、PVC 等）的原子性备份与恢复能力。
- 有状态应用保护：StatefulSet、PVC 等有状态资源的数据卷备份需要与云存储或文件系统深度集成。
- 跨集群迁移复杂：从开发/测试集群迁移到生产集群，或在不同云厂商间迁移，需要保持资源依赖关系和数据一致性。
- 合规与审计需求：企业级灾备要求定期备份、保留策略、加密传输以及操作审计日志。
关键里程碑：Velero 1.0 于 2019 年发布，标志着 API 稳定；1.9+ 版本引入 BackupRepository 和 DataMover 架构，大幅提升卷备份性能；当前最新稳定版已支持 CSI 快照、Restic/Kopia 双引擎以及细粒度资源过滤。
1.2 核心功能：备份 / 恢复 / 迁移
Velero 围绕三个核心操作构建其功能体系，下表总结了每个功能的关键特性与适用场景：
| 功能 | 核心能力 | 关键特性 | 典型场景 |
|---|---|---|---|
| 备份 (Backup) | 将 Kubernetes 资源对象及其关联的持久卷数据快照保存到目标存储 | 资源过滤（label/namespace/resource）、定时调度（Schedule）、卷快照（CSI/Restic/Kopia）、加密传输 | 每日全量备份、变更前快照、合规归档 |
| 恢复 (Restore) | 从备份存储中还原资源对象与卷数据到原集群或目标集群 | 选择性恢复（仅恢复部分资源）、命名空间映射、冲突策略（跳过/覆盖）、Hook 执行 | 误删除恢复、集群故障重建、数据回滚 |
| 迁移 (Migration) | 将资源与数据从一个集群完整复制到另一个集群 | 跨集群备份/恢复组合、存储类映射、节点亲和性调整、网络策略适配 | 集群升级、云迁移、多环境同步 |
1.3 与 Kubernetes 原生资源的关系
Velero 深度依赖 Kubernetes 原生 API 资源，其工作流程围绕以下核心资源构建：
- CustomResourceDefinition (CRD)：Velero 自身通过 CRD 扩展 Kubernetes API，定义了
Backup、Restore、Schedule、BackupStorageLocation、VolumeSnapshotLocation等自定义资源。用户通过创建这些 CR 对象来触发操作。 - PersistentVolumeClaim (PVC) / PersistentVolume (PV)：备份有状态应用时，Velero 通过 CSI 快照或文件系统级备份（Restic/Kopia）捕获 PVC 绑定的 PV 数据。
- Namespace / Deployment / StatefulSet / ConfigMap / Secret：Velero 备份时会递归获取指定命名空间或集群范围内的所有 Kubernetes 原生资源，并保持其依赖关系（如 Service 与 EndpointSlice 的关联）。
- VolumeSnapshot / VolumeSnapshotContent (CSI)：当使用 CSI 快照引擎时，Velero 调用 CSI 驱动创建 VolumeSnapshot 对象，由存储后端完成数据快照。
- BackupRepository：Velero 1.9+ 引入的 CRD，用于管理卷备份数据的存储仓库（如对象存储桶中的目录结构），实现增量备份与数据去重。
架构要点：Velero 本身不存储数据，它作为 Kubernetes 集群内的控制器，协调备份/恢复操作，并将数据持久化到外部存储（如 AWS S3、GCS、Azure Blob、MinIO）。所有操作记录均以 CRD 对象形式保存在集群 etcd 中，便于审计与重试。
1.4 Velero 核心架构组件
下图展示了 Velero 在 Kubernetes 集群中的核心组件及其与原生资源的交互关系：
1.5 备份与恢复的原子性保证
Velero 通过以下机制确保备份与恢复操作的原子性和一致性：
- 资源快照顺序：备份时先记录所有 Kubernetes 资源对象的 YAML 清单，再执行卷快照；恢复时先恢复卷数据，再恢复资源对象，确保 Pod 启动时 PVC 已就绪。
- Hook 机制：支持 Pre/Post Hook，可在备份前冻结应用（如 Flush 数据库）、恢复后执行数据校验，保证应用级一致性。
- 标签与注解继承：备份操作会保留原始资源的标签和注解，恢复时可通过
--labels参数过滤，避免恢复无关资源。 - 冲突策略：恢复时默认跳过已存在的资源（
--existing-resource-policy=none），也可强制覆盖（--existing-resource-policy=update），需谨慎使用。
常见误区：Velero 的备份是“尽力一致性”而非“严格事务性”。如果备份过程中有资源被删除或更新，备份集可能包含不一致的状态。建议在备份前暂停对目标命名空间的写操作，或使用 Schedule 的
--ttl 参数保留多个历史版本。
1.6 典型部署模式对比
| 部署模式 | 适用场景 | 优势 | 限制 |
|---|---|---|---|
| 单集群本地备份 | 开发/测试环境、小型生产 | 部署简单，直接使用集群内存储类 | 无法应对集群级故障，存储单点 |
| 单集群远程备份 | 生产环境灾备 | 数据存储于外部对象存储，集群故障不影响备份数据 | 需配置网络出口带宽，依赖外部存储可用性 |
| 跨集群备份/迁移 | 集群升级、云迁移、多活 | 支持异构集群（不同 K8s 版本、不同云厂商） | 需手动处理存储类映射、网络策略、Ingress 域名等差异 |
| 联邦/多集群备份 | 大规模多集群管理 | 通过 Velero 结合 Karmada/Cluster API 实现统一备份策略 | 架构复杂，需额外编排层 |