Velero原理及限制

Velero 如何实现备份与恢复？

Velero（原 Heptio Ark）通过 快照 + 对象存储 + Kubernetes 对象导出 的方式实现集群的备份与恢复。

Velero 的工作原理可以概括为：以声明式的方式，通过操作自定义资源（CRD）来驱动备份和恢复流程，并将集群资源和持久卷数据安全地存入对象存储或通过其进行恢复。

---

Velero 整体架构

• Velero CLI：命令行客户端，用于发起备份/恢复操作。
• Velero Server：运行在目标 Kubernetes 集群中的控制器（Deployment），负责监听自定义资源（如 Backup、Restore）并执行实际操作。
• 插件系统：
  • 对象存储插件（如 AWS S3、Azure Blob、MinIO）
  • 卷快照插件（如 AWS EBS、GCP PD、CSI 快照）
  • Restic 插件（用于文件级 PV 备份）

sequenceDiagram
    participant U as 用户 (velero CLI)
    participant K as Kubernetes API Server
    participant B as BackupController
    participant R as RestoreController
    participant S as 对象存储 (如 MinIO)

    rect rgba(0, 100, 0, 0.1)
        note right of U: 备份流程
        U->>K: 创建 Backup 对象
        K->>B: 通知有新的 Backup 对象
        B->>K: 查询需要备份的资源
        K->>B: 返回资源列表 (YAML/JSON)
        B->>S: 将资源数据打包上传
        S->>B: 返回上传成功
        B->>K: 更新 Backup 状态为 Completed
    end

    rect rgba(0, 0, 100, 0.1)
        note right of U: 恢复流程
        U->>K: 创建 Restore 对象
        K->>R: 通知有新的 Restore 对象
        R->>S: 获取指定的备份文件
        S->>R: 返回备份数据
        R->>R: 预处理资源 (如命名空间映射)
        R->>K: 依次创建备份中的资源
        K->>R: 返回创建结果
        R->>K: 更新 Restore 状态为 Completed
    end

下面按流程说明。

---

Velero 备份原理（Backup）

Velero 的 Backup 控制器工作流程：

扫描 Kubernetes API，收集集群对象

Velero 会根据 Backup CR（包括 selector、namespace、label 等）筛选要备份的资源：

• Deployments / StatefulSets / DaemonSets
• Services
• Ingress
• ConfigMaps / Secrets
• CRD 对象
• ServiceAccounts / RBAC
• PVC / PV 引用关系

Velero 将资源序列化为 JSON/YAML 保存到对象存储（S3/GCS/OSS）中。

---

PVC 对应的实际数据如何备份？

Velero 支持两种模式：

A. Snapshot 模式（VolumeSnapshot）— 推荐

使用 storage provider 提供的 VolumeSnapshotter，比如：

• AWS/GCP/Azure 的原生 snapshot
• Velero Plugin for CSI
• vSphere snapshot

流程：

1. Velero 调用 VolumeSnapshotter 创建 snapshot
2. Snapshot 由云厂商管理
3. Velero 在对象存储中存快照的 metadata

✔ 优点：速度快，性能好
✖ 缺点：不能跨云恢复（除非支持跨区域复制）

---

B. Restic / Kopia 文件备份（非快照）

适用于 本地存储 / 不支持 snapshot 的环境。

流程：

1. Velero 在节点运行一个 restic/kopia daemonset
2. 对 Pod 挂载的 PVC 做文件级备份（tar 形式）
3. 文件数据存到对象存储

---

Velero 恢复原理（Restore）

从对象存储下载备份的 YAML 资源

Velero 逐条在 Kubernetes 中应用：

• 先恢复 Namespace、CRD
• 再恢复 RBAC、ServiceAccount
• 再恢复普通资源（deployments、svc 等）

Velero 会处理：

• API 版本差异（部分支持）
• OwnerReference 关系
• 镜像拉取策略

---

PVC / 数据 Volume 恢复

如果使用 Snapshot：

• 在云厂商创建 VolumeSnapshot → 恢复成 PV
• 按 PV/PVC 绑定规则绑定回 Pod

如果使用 Restic/Kopia：

• 先创建 PVC（空卷）
• Pod 启动前 hook 注入 init container，由 restic/kopia 还原文件
• 再启动 workload

---

资源冲突、重名处理

Velero 提供策略：

• Existing：遇到已有资源跳过
• Update：覆盖已有资源
• Merge：与已有资源合并（部分资源支持）

---

Velero Backup/Restore 过程时序图（简版）

Backup:
Velero Controller → 列出资源 → 保存 YAML → 保存 PV snapshot/restic → 上传到对象存储

Restore:
Velero Controller → 下载 YAML → 创建资源 → 恢复 PV → 绑定 → Pod 恢复

---

Velero 的常见限制与坑（非常关键）

1. 不同集群间恢复可能失败（API 版本差异）

例如：

• K8s 1.15 → 1.25 期间大量 API 移除（Ingress v1beta1 → networking.k8s.io/v1）
• CRD schema 版本不兼容

Velero 不会自动转换 schema，需要手动处理。

---

2. Service 类型 LoadBalancer 的 IP 不会被恢复

因为 LB 是云厂商资源：

• 不会恢复外部 IP
• 重新创建 LB 会产生新 IP → 应用可能需要重新配置

---

3. NodePort / ClusterIP 有一定概率被重新分配

导致：

• 依赖固定 NodePort 的服务不稳定
• 依赖 ClusterIP 的配置需要更新

---

4. CSI Snapshot 插件不通用，不能跨存储/跨云恢复

如：

• AWS EBS snapshot → 不能恢复到 GCP
• Ceph RBD snapshot → 不能恢复到 local storage

---

5. Restic 模式性能较差

缺点：

• 文件级备份很慢
• 节点 CPU / IO 消耗大
• 首次备份非常耗时（全量备份）

---

6. 不备份以下内容

velero 默认不备份：

• Kubelet 管理的资源（/var/lib/kubelet/…）
• EmptyDir 数据
• Node 本身信息
• 运行时层面数据（container runtime）
• etcd 备份（Velero 不直接备份 etcd）

---

7. 备份跨 Namespace 的资源关联可能失败

例如：

• 一个 deployment 引用另一个 ns 的 configmap
• Velero 不会自动处理引用依赖，恢复顺序可能错乱

---

8. 动态 Admission Webhook 可能阻断 restore

恢复过程中：

• Admission webhook 可能拒绝创建资源
• 典型场景：校验字段不符合当前 schema

解决：

kubectl delete -A ValidatingWebhookConfiguration <name>
kubectl delete -A MutatingWebhookConfiguration <name>

---

总结：是否适合生产？

场景	是否适合
公有云 + 支持 snapshot	✔ 强烈推荐
本地存储 + Restic	✔ 中小规模可以
跨云备份恢复	✖ 不推荐
恢复整个集群	✔ 可行，但需要处理 webhook & CRD
多租户大规模集群	✔ 需要优化备份策略

---