2. Velero 架构解析：组件、数据流与工作流程
Velero 采用 客户端-服务端（Client-Server） 架构，由三个核心组件构成：Velero Server（运行在集群内的控制器）、Velero CLI（命令行客户端）以及 Plugin（存储与卷快照插件）。理解这三者的职责、协作关系以及数据流，是掌握 Velero 备份与恢复机制的基础。
2.1 核心组件概览
| 组件 | 部署位置 | 核心职责 |
|---|---|---|
| Velero Server | Kubernetes 集群内（Deployment） | 监听 Backup / Restore / Schedule CRD，协调备份与恢复流程 |
| Velero CLI | 用户本地或 CI/CD 环境 | 创建备份/恢复请求、管理调度、查看状态 |
| Plugin | 集群内（DaemonSet 或 Sidecar） | 对接对象存储（AWS S3 / Azure Blob / GCS）与卷快照（CSI / Restic / Kopia） |
关键设计原则： Velero Server 本身不直接操作存储或卷快照，所有与外部系统的交互均通过 Plugin 完成。这种插件化架构使得 Velero 可以灵活适配不同的云平台与存储后端。
2.2 Velero 组件详解
2.2.1 Velero Server
- 控制器模式： 基于 Kubernetes 控制器模式运行，监听
Backup、Restore、Schedule、DownloadRequest等 CRD 资源。 - 核心流程： 当用户通过 CLI 创建
Backup对象后，Server 中的backup-controller会触发备份流程：调用 API Server 获取资源清单、调用 Plugin 上传数据、更新备份状态。 - 状态管理： 备份/恢复的每个阶段（New、InProgress、Completed、Failed）都会实时更新到 CRD 的
status字段中。
2.2.2 Velero CLI
- 命令式操作： 提供
velero backup create、velero restore create、velero schedule create等命令。 - 与 Server 通信： CLI 通过 Kubernetes API 直接创建/更新/删除 CRD 对象，Server 控制器监听这些对象的变化并执行实际工作。
- 辅助功能： 支持
velero backup logs、velero restore describe等调试命令，方便审计与排错。
2.2.3 Plugin
- 对象存储插件： 负责将备份数据（资源清单 YAML + 卷快照文件）上传到远端对象存储。常见实现：
velero-plugin-for-aws、velero-plugin-for-gcp、velero-plugin-for-microsoft-azure。 - 卷快照插件： 负责创建/删除持久卷的快照。支持 CSI 快照、Restic/Kopia 文件级备份、以及云平台原生快照（如 EBS Snapshot）。
- 自定义插件： 用户可基于 Velero Plugin SDK 开发自定义存储后端或快照逻辑，满足私有云或特殊合规需求。
2.3 数据流与工作流程
以下 SVG 图展示了 Velero 一次完整备份操作的数据流与组件协作关系：
2.4 工作流程分步解析
2.4.1 备份流程
- 用户发起： 执行
velero backup create my-backup --include-namespaces default，CLI 在集群中创建BackupCRD 对象。 - Server 感知： Velero Server 的
backup-controller通过 Informer 机制发现新的 Backup 对象，状态变为InProgress。 - 资源收集： Server 调用 Kubernetes API 获取指定命名空间下的所有资源（Deployment、Service、PVC、ConfigMap 等），序列化为 JSON/YAML 清单。
- 数据上传： Server 调用 对象存储 Plugin，将资源清单上传到远端对象存储（如 S3 Bucket），路径格式为
backups/<backup-name>/<resource-type>.json。 - 卷快照： 如果备份包含 PVC，Server 调用 卷快照 Plugin 创建持久卷的快照（CSI 快照或 Restic/Kopia 文件级备份）。
- 状态更新： 所有数据上传完成后，Server 将 Backup 对象状态更新为
Completed，并记录备份大小、快照数量等元数据。
2.4.2 恢复流程
- 用户发起： 执行
velero restore create --from-backup my-backup，CLI 创建RestoreCRD 对象。 - Server 感知：
restore-controller发现 Restore 对象，状态变为InProgress。 - 数据下载： Server 调用对象存储 Plugin 从远端下载资源清单。
- 资源重建： Server 通过 Kubernetes API 依次创建资源（先创建 PVC，再创建 Pod 等），确保依赖顺序正确。
- 卷恢复： 如果备份包含卷快照，Server 调用卷快照 Plugin 从快照恢复数据到新创建的 PVC。
- 状态更新： 所有资源创建完成后，Server 将 Restore 对象状态更新为
Completed。
审计要点： 每次备份/恢复操作都会在 Velero Server 的日志中留下详细记录，包括操作时间、涉及的资源列表、调用的 Plugin 版本、以及任何错误信息。这些日志是门禁权限审计的重要数据源。
2.5 组件通信与安全边界
| 通信路径 | 协议 | 安全控制 |
|---|---|---|
| CLI → API Server | HTTPS (K8s API) | RBAC 权限、ServiceAccount |
| Velero Server → API Server | HTTPS (K8s API) | ServiceAccount 绑定 ClusterRole |
| Velero Server → Plugin | gRPC (Unix Socket) | 本地通信，依赖 Pod 安全上下文 |
| Plugin → 对象存储 | HTTPS (S3/GCS/Blob API) | 云平台 IAM 密钥 / 托管身份 |
| Plugin → 卷快照 | CSI API / Restic REST | CSI 驱动 RBAC / 加密密钥 |
安全审计提醒： Velero Server 的 ServiceAccount 通常需要较高的集群权限（如
cluster-admin），因为备份需要读取所有命名空间的资源。在生产环境中，建议通过 --restic-daemon 或 --kopia-daemon 模式限制卷快照的权限范围，并定期审计 Velero 的 RBAC 绑定。
2.6 架构设计总结
- 解耦设计： Velero 将备份编排（Server）与存储操作（Plugin）完全分离，使得更换存储后端或快照方案时无需修改核心代码。
- CRD 驱动： 所有操作均通过 Kubernetes CRD 表达，天然支持声明式管理与 GitOps 工作流。
- 可扩展性： Plugin 机制允许社区或企业开发自定义存储后端、快照引擎、甚至数据加密/脱敏插件。
- 审计友好： 备份/恢复的每个阶段都记录在 CRD 状态与 Server 日志中，配合 Kubernetes 审计日志，可以构建完整的操作审计链。