📚 课程目录第3章 Velero核心原理

3. Velero 核心原理：架构与备份工作流

Velero 这东西，说白了就是 Kubernetes 世界的「时光机」。我最早接触它的时候，还在手动写 shell 脚本备份 etcd，那叫一个痛苦。后来上了 Velero，才真正体会到什么叫「云原生时代的备份就该这么干」。

这一节，咱们把 Velero 的骨架拆开看看。你理解了它的架构，后面配置、排错都会顺手很多。

3.1 Velero 整体架构

Velero 的架构其实不复杂。它由三个核心组件构成：Server、Plugin 和 Schedule。我习惯把它们比作「大脑」、「翻译官」和「闹钟」。

一句话总结：Velero Server 负责调度和执行备份任务，Plugin 负责跟不同的存储后端和 Kubernetes 资源打交道，Schedule 则帮你把备份变成自动化定时任务。

3.1.1 Velero Server

Server 是 Velero 的主进程。它运行在 Kubernetes 集群内，监听自定义资源（CRD）的变化。你创建一个 Backup 对象，Server 就立刻开始干活。

Server 内部有几个关键模块：

Controller：核心调度器，负责监听 Backup、Restore、Schedule 等 CRD 事件。
Backend Handler：处理与存储后端的交互，比如上传快照、下载元数据。
Volume Snapshotter：调用云厂商 API 创建持久卷的快照。

我记得有一次，生产环境上 Velero Server 突然不响应了。排查了半天，发现是 CRD 版本冲突。嗯，从那以后我升级 Velero 都会先检查 CRD 兼容性。

3.1.2 Plugin 机制

Plugin 是 Velero 的「翻译官」。它让 Velero 能跟各种存储后端和云平台对话。你想想看，AWS 的 S3、Azure 的 Blob Storage、GCP 的 GCS，甚至本地 MinIO，Velero 都能支持——全靠 Plugin。

Plugin 分两类：

类型	作用	常见例子
Object Store Plugin	管理备份文件的存储位置	aws-plugin, azure-plugin, gcp-plugin
Volume Snapshotter Plugin	创建和删除云盘快照	aws-ebs-plugin, csi-plugin

我的建议：如果你用自建的 MinIO 或 Ceph，选 Object Store Plugin 就够了。Volume Snapshotter 通常只在云上需要，本地环境用 restic 或 kopia 更省事。

3.1.3 Schedule

Schedule 就是 Velero 的「闹钟」。它基于 Cron 表达式，帮你自动触发备份。我个人习惯用 @daily 做全量备份，@hourly 做增量备份。

举个例子：

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
      - production
    ttl: 720h

这个 Schedule 每天凌晨 2 点备份 production 命名空间，保留 30 天。注意 ttl 字段，我吃过亏——默认是 720h，但如果你不设置，备份会永远保留，把存储撑爆。

3.2 备份工作流：In-Cluster vs Out-of-Cluster

Velero 支持两种备份模式：In-Cluster 和 Out-of-Cluster。这两种模式的区别，说白了就是「谁在干活」。

3.2.1 In-Cluster 模式

这是最常用的模式。Velero Server 以 Deployment 形式运行在集群内，备份任务由集群内的 Pod 执行。

工作流是这样的：

用户创建 Backup CRD 对象（或 Schedule 自动触发）。
Velero Controller 监听到事件，启动一个备份 Pod。
备份 Pod 调用 Kubernetes API 获取资源清单。
同时调用 Volume Snapshotter Plugin 创建 PV 快照。
将资源清单和快照元数据上传到对象存储。

我遇到过一个问题：In-Cluster 模式下，如果集群本身挂了（比如 etcd 损坏），Velero Server 也起不来。这时候备份数据还在对象存储里，但没法恢复。怎么办？

避坑指南：我曾经因为集群完全宕机，In-Cluster 模式的 Velero 无法启动，导致恢复流程卡住。后来我养成了习惯：在集群外至少保留一份 Velero CLI 的安装包和配置文件，用于 Out-of-Cluster 恢复。

3.2.2 Out-of-Cluster 模式

Out-of-Cluster 模式，就是 Velero 以 CLI 方式运行在集群外。它不依赖集群内的 Pod，直接通过 kubeconfig 访问集群 API。

工作流：

你在本地或跳板机上执行 velero backup create 命令。
Velero CLI 直接调用 Kubernetes API 获取资源。
同时调用云厂商 API 创建快照。
数据上传到对象存储。

这种模式适合紧急恢复场景。比如集群挂了，你可以在另一台机器上配好 kubeconfig，直接跑 Velero CLI 恢复。

3.2.3 两种模式对比

维度	In-Cluster	Out-of-Cluster
部署方式	Deployment + CRD	CLI 二进制
依赖	集群正常运行	仅需 kubeconfig
自动化	支持 Schedule	需外部 cron
恢复场景	集群正常时	集群故障时
我推荐	日常备份	灾难恢复

3.3 核心流程图

下面这张图，把 Velero 的备份工作流画清楚了。你盯着看 30 秒，就能明白数据是怎么从集群流到对象存储的。

3.4 备份数据流向

你可能会问：Velero 备份的数据到底长什么样？我打开一个备份目录给你看看：

backups/
└── my-backup/
    ├── velero-backup.json          # 备份元数据
    ├── resources/
    │   ├── namespaces/
    │   │   └── production.json
    │   ├── deployments/
    │   │   └── production-app.json
    │   └── persistentvolumeclaims/
    │       └── pvc-data.json
    └── snapshots/
        └── snap-abc123.json        # 快照引用信息

资源清单是 JSON 格式，记录了每个 Kubernetes 对象的完整状态。快照文件里存的是云盘快照 ID，不是真正的数据块。真正的数据块在云厂商那边。

小技巧：你可以用 velero backup describe my-backup --details 查看备份内容。如果发现某个资源没备份成功，先检查 RBAC 权限——这是最常见的翻车原因。

3.5 备份策略选择

最后聊聊策略。我个人习惯这样搭配：

日常备份：In-Cluster + Schedule，全量备份每天一次，增量备份每小时一次。
灾难恢复：Out-of-Cluster + 手动触发，备份文件保留在异地对象存储。
迁移场景：In-Cluster 模式，用 --include-namespaces 精确控制迁移范围。

嗯，Velero 的架构和工作流就这些。你只要记住：Server 是大脑，Plugin 是翻译官，Schedule 是闹钟。In-Cluster 日常用，Out-of-Cluster 救急用。下次咱们聊聊怎么选存储后端，那又是一个坑多的地方。