2. Velero 架构解析：组件、数据流与 Restic/Kopia 集成

在生产环境中实施灾备准入，首先需要深入理解 Velero 的架构设计。本章将拆解 Velero 的核心组件（Server / CLI / Plugin）、控制面与数据面的数据流，以及 Restic 和 Kopia 两种备份引擎的集成原理。掌握这些底层机制，是后续进行架构选型与故障排查的基础。

2.1 核心组件：Server、CLI 与 Plugin

Velero 采用 “客户端-服务端-插件” 三层架构。CLI 负责触发操作，Server 负责调度与协调，Plugin 负责与具体存储后端及 Kubernetes 资源交互。

组件 部署形态 核心职责 关键说明
Velero CLI 客户端二进制（本地或 CI/CD） 发起备份/恢复/调度命令；解析 YAML 参数；调用 API Server 不直接操作数据，仅作为控制面入口
Velero Server Kubernetes Deployment（velero namespace） 监听 CRD（Backup/Schedule/Restore）；协调工作流；调用插件 核心控制器，负责状态机转换与重试逻辑
Plugin Sidecar 容器或独立二进制 对接对象存储（AWS S3 / Azure Blob / GCS）；执行 Volume 快照 分为 Object Store Plugin 与 Volume Snapshotter Plugin
架构要点： Velero Server 本身不存储任何备份数据，所有备份产物（JSON 描述文件 + Volume 数据）均通过 Plugin 写入外部对象存储。这种设计使得 Velero 天然具备无状态特性，便于灾备场景下的快速重建。

2.2 数据流：控制面与数据面分离

Velero 严格遵循 控制面（Control Plane） 与 数据面（Data Plane） 分离的架构模式。控制面负责编排与状态管理，数据面负责实际的数据传输与存储。

Velero 控制面与数据面分离架构 Velero 控制面与数据面分离架构 控制面（Control Plane） Velero CLI K8s API Server Velero Server （控制器 + CRD 监听） 数据面（Data Plane） Object Store Plugin （S3 / Azure / GCS） Volume Snapshotter （CSI / Restic / Kopia） 对象存储 （备份目标） gRPC 调用 数据流关键路径 1. CLI → API Server → Velero Server 2. Server 通过 gRPC 调用 Plugin 3. Plugin 直接读写对象存储（数据面）
数据流关键路径：
  1. 控制面触发： 用户通过 velero backup create CLI 命令向 Kubernetes API Server 提交 Backup CRD 对象。
  2. 控制面协调： Velero Server 的 Backup Controller 监听到新 CRD，开始解析备份范围（Namespace、Label Selector、Volume 列表）。
  3. 数据面执行： Server 通过 gRPC 调用 Object Store Plugin 将 Kubernetes 资源清单（JSON/YAML）上传至对象存储；同时调用 Volume Snapshotter Plugin 对 PVC 进行快照或文件级备份。
  4. 状态回写： 备份完成后，Plugin 将结果（存储路径、校验和、快照 ID）返回给 Server，Server 更新 Backup CRD 的状态为 Completed。

2.3 Restic 与 Kopia 集成原理

Velero 支持两种文件级备份引擎：Restic（传统方案）和 Kopia（新一代方案）。两者均以 DaemonSet 或 Sidecar 形式运行在数据面，负责将 Pod 的 Volume 数据备份到对象存储。

2.3.1 两种引擎的架构对比

特性 Restic Kopia
集成方式 Velero 内置 Restic 作为默认文件备份器 通过 Velero Plugin for Kopia 集成（v1.12+）
数据去重 基于内容分块（CDC）去重 基于内容分块（CDC）+ 可变分块大小，去重效率更高
增量备份 支持，但需扫描全部文件 支持，使用索引加速增量扫描
备份速度 中等，大量小文件场景性能下降 较快，针对小文件场景有优化
存储格式 Restic Repository（.restic 目录） Kopia Repository（.kopia 目录）
推荐场景 传统环境、已有 Restic 经验 新部署、追求性能与存储效率
Restic / Kopia 集成数据流 Restic / Kopia 集成数据流 目标 Pod Volume: /data PVC: my-pvc Velero Backup Pod Restic / Kopia Sidecar （文件级备份引擎） 对象存储 Bucket: velero-backup Path: /backups/ 读取 Volume 上传分块 Restic / Kopia 备份流程 1. Velero Server 创建 Backup CRD，指定使用文件级备份（--use-volume-snapshots=false）。 2. Velero 在目标 Pod 所在节点启动 Backup Pod，挂载相同的 PVC Volume。 3. Restic/Kopia 引擎扫描 Volume 文件，进行内容分块（CDC）与去重。 4. 去重后的数据分块上传至对象存储，元数据（Manifest）单独存储。 5. 备份完成后，Backup Pod 退出，Server 更新 CRD 状态。
关键区别： Restic 和 Kopia 均不依赖 CSI 快照，而是通过直接读取文件系统进行备份。这意味着它们可以备份任何类型的 Volume（包括 hostPath、NFS 等 CSI 不支持的存储），但备份期间 Volume 必须处于只读或一致状态。在生产环境中，建议结合 fsfreeze 或应用侧停写来保证一致性。

2.3.2 引擎选择建议

  • 新项目选 Kopia： 如果集群版本 ≥ v1.12，且对备份速度、存储效率有较高要求，优先选择 Kopia。其索引机制在增量备份场景下优势明显。
  • 存量环境保留 Restic： 如果已有大量基于 Restic 的备份仓库，或团队对 Restic 运维经验丰富，无需强制迁移。Velero 会长期同时支持两种引擎。
  • 混合使用： 同一集群内可以同时部署 Restic 和 Kopia，通过 Backup 的 Annotation（velero.io/backup-engine）指定使用哪种引擎。
故障排查提示： 当文件级备份失败时，首先检查 Backup Pod 的日志：
# 查看 Restic 备份 Pod 日志
kubectl logs -n velero -l app.kubernetes.io/name=restic --tail=50

# 查看 Kopia 备份 Pod 日志
kubectl logs -n velero -l app.kubernetes.io/name=kopia --tail=50
常见错误包括：Volume 挂载超时、对象存储认证失败、磁盘空间不足导致分块缓存溢出。
← 上一章 📖 返回目录 下一章 →