3. Velero 基础架构:组件架构图、备份与恢复核心流程、存储后端对接原理

Velero 是专为 Kubernetes 环境设计的开源灾备工具,其核心价值在于将集群资源对象与持久卷数据统一封装为可移植的备份文件,并支持通过回滚策略实现蓝绿发布场景下的快速恢复。理解 Velero 的基础架构是掌握后续灾备部署实践的基石。

3.1 Velero 组件架构图

Velero 采用典型的 客户端-服务端 架构,由两个核心组件构成:命令行客户端 velero 和集群内运行的控制器 Velero Server。服务端又进一步拆分为 Velero Deployment 和 Node Agent DaemonSet(原名为 restic 或 kopia),分别负责编排调度与数据移动。

架构要点: Velero 不依赖任何外部数据库,所有备份/恢复任务的状态均以 Kubernetes CRD(Custom Resource Definition)形式存储在集群 etcd 中,保证了声明式管理的纯粹性。
Velero 组件架构图 velero CLI Kubernetes API Server Velero Deployment 控制器 + 调度器 Node Agent DaemonSet 数据移动器 (Kopia/Restic) 对象存储 S3 / GCS / Azure Blob 说明: Velero Deployment 负责备份/恢复任务的编排与 CRD 状态管理;Node Agent 运行在每个工作节点上,负责将 PV 数据上传至对象存储。

3.2 备份与恢复核心流程

Velero 的备份与恢复流程遵循 先编排、后执行、再持久化 的三阶段模型。以下表格对比了两种核心操作的关键差异:

操作类型 触发方式 数据捕获范围 存储格式 原子性
备份 (Backup) API 请求 / 定时调度 资源对象 YAML + PV 快照/文件级数据 tar + gzip 压缩包 非严格原子(最终一致)
恢复 (Restore) API 请求 / 自动触发 从备份包全量还原 解压后 Apply 到集群 尽力而为(冲突跳过)

3.2.1 备份核心流程

  1. 创建 Backup CRD: 用户通过 velero backup create 或定时调度创建 Backup 自定义资源对象。
  2. 资源发现与过滤: Velero 控制器根据 Backup CR 中指定的命名空间、标签选择器、资源类型等规则,通过 API Server 查询待备份的资源列表。
  3. 资源序列化: 将查询到的 Kubernetes 资源对象(Deployment、Service、ConfigMap 等)序列化为 JSON/YAML 格式,并写入内存缓冲区。
  4. PV 数据备份: 对于挂载了持久卷的 Pod,Node Agent 通过文件系统快照或直接读取的方式,将 PV 数据上传至对象存储。默认使用 Kopia 作为数据移动引擎,支持增量备份与去重。
  5. 打包上传: 将资源对象清单与 PV 数据合并为一个 .tar.gz 文件,上传至配置的对象存储桶,并更新 Backup CR 的状态为 Completed。
最佳实践: 在生产环境中,建议为备份设置 --ttl 参数(如 720h),并配合 --snapshot-move-data 选项将卷快照直接移至对象存储,避免依赖集群本地存储。

3.2.2 恢复核心流程

  1. 创建 Restore CRD: 用户通过 velero restore create --from-backup <backup-name> 创建 Restore 自定义资源对象。
  2. 备份包解析: Velero 控制器从对象存储下载对应的备份包,解压后解析资源清单与 PV 数据索引。
  3. 资源冲突检测: 控制器检查目标集群中是否已存在同名资源。默认策略为 跳过已存在资源(可通过 --existing-resource-policy 调整为 update 或 none)。
  4. 资源创建: 按依赖顺序(先创建 Namespace、StorageClass,再创建 Workload)将资源对象 Apply 到集群。
  5. PV 数据恢复: Node Agent 从对象存储下载 PV 数据,并写入新创建的持久卷中。恢复完成后,更新 Restore CR 状态为 Completed。
备份与恢复核心流程对比 备份流程 ① 创建 Backup CRD ② 资源发现与序列化 ③ PV 数据上传 (Kopia) ④ 打包上传至对象存储 恢复流程 ① 创建 Restore CRD ② 下载并解析备份包 ③ 冲突检测与资源创建 ④ PV 数据写入与状态更新 关键差异: 备份流程先序列化资源再上传数据;恢复流程先下载解析再创建资源。两者均通过 CRD 状态机驱动,支持异步执行与重试。

3.3 存储后端对接原理

Velero 通过 插件机制 对接不同的对象存储后端,实现了存储层与业务逻辑的解耦。每个存储后端对应一个 Volume Snapshotter(卷快照插件)和 Object Store(对象存储插件)。

3.3.1 存储后端对接架构

存储后端 对象存储插件 卷快照插件 认证方式 适用场景
AWS S3 velero-plugin-for-aws velero-plugin-for-aws IAM Role / Access Key 公有云原生环境
GCP GCS velero-plugin-for-gcp velero-plugin-for-gcp Service Account GKE 集群
Azure Blob velero-plugin-for-microsoft-azure velero-plugin-for-microsoft-azure Service Principal AKS 集群
MinIO (S3 兼容) velero-plugin-for-aws 不支持(需配合 CSI) Access Key + Secret 私有云 / 边缘环境

3.3.2 对接配置示例

以下为使用 MinIO 作为存储后端的典型配置步骤:

# 1. 创建 Secret 存储访问凭证
kubectl create secret generic cloud-credentials \
  --namespace velero \
  --from-literal=aws_access_key_id=minioadmin \
  --from-literal=aws_secret_access_key=minioadmin

# 2. 安装 Velero 并指定存储后端
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --bucket velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config region=minio,s3ForcePathStyle=true,s3Url=http://minio.velero.svc:9000 \
  --snapshot-location-config region=minio

# 3. 验证存储位置状态
velero backup-location get
注意: 当使用 S3 兼容存储(如 MinIO)时,必须设置 s3ForcePathStyle=true,否则 Velero 会使用虚拟主机风格路径导致连接失败。同时,region 参数可任意填写,但不可为空。

3.3.3 数据流与存储结构

Velero 在对象存储桶中的目录结构遵循固定约定,便于多集群管理与增量恢复:

velero-backups/                          # 存储桶根目录
├── backups/                             # 备份包目录
│   ├── <backup-name-1>/                 # 单个备份
│   │   ├── velero-backup.json           # 备份元数据
│   │   ├── <resource-list>.tar.gz       # 资源对象清单
│   │   └── <volume-id>.tar.gz           # PV 数据文件
│   └── <backup-name-2>/
├── restores/                            # 恢复记录目录
│   └── <restore-name>/
│       └── restore-results.yaml
└── snapshots/                           # 卷快照目录(可选)
    └── <volume-id>/
        └── snapshot.json

该存储结构使得 Velero 在恢复时能够快速定位备份包,并支持 部分恢复(仅恢复指定资源或卷),极大提升了蓝绿发布场景下的回滚效率。