当 Kubernetes 集群崩溃时如何保持冷静，或者为什么你需要 Velero
想象一下：周五晚上，你正打算放松一下，突然 Slack 弹出一条通知——你的某个生产 Kubernetes 集群彻底崩溃了。配置错误、云服务商故障，或者就是简单的人为失误——原因已经不重要了。重要的是你能多快让一切恢复正常。如果你的 Git 仓库里只有 YAML 文件，那祝你好运去恢复有状态应用及其数据。
这就是 Velero 的用武之地。它是 VMware（最初由 Heptio 创建）的一个项目，已成为 K8s 备份领域的事实标准。
它是什么，以及为什么单靠 GitOps 是不够的
许多开发者认为，如果他们的整个基础设施都在代码中定义（IaC），并通过 ArgoCD 或 Flux 部署，就不需要备份了。这是一个危险的误解。Git 存储的是清单文件，但它对 Persistent Volumes（PV）的状态、动态颁发的证书，或者从未提交到仓库的 secrets 一无所知。
Velero 做两件事：保存 Kubernetes API 对象（deployments、configmaps、secrets），以及对磁盘进行快照并保存数据。它可以在公有云（AWS、GCP、Azure）中使用，也可以在本地数据中心和裸机环境中运行。
Velero 救命的三个场景
我经常看到 Velero 的使用场景不仅仅是灾难恢复。以下是主要用例：
- 经典灾难恢复。这个很简单：集群挂了，你启动一个新的，然后用一条命令从 S3 存储中恢复所有内容。
- 跨云迁移。从 AWS 迁移到 Google Cloud，或者从一个区域迁移到另一个区域，变成了一项 trivial 的任务。Velero 打包资源并部署到新位置。
- 环境克隆。需要快速创建一个生产环境的精确副本用于测试？你做一个生产备份，然后恢复到 namespace
staging。数据库数据是最新的，而不是一个月前的 dump。
底层工作原理
这个项目的架构非常透明。有一个服务端组件以 operator 的形式运行在集群内部，还有一个 CLI 客户端用于管理整个过程。
当你触发备份时，流程如下：
- 客户端向 Velero API 发送请求。
- Backup controller 找到你指定的所有对象（你可以按标签或 namespace 过滤）。
- Velero 向 Kubernetes API 发起请求，收集资源的 JSON 描述。
- 同时调用磁盘管理的插件（如 AWS 中的 EBS 或 CSI drivers）来创建数据快照。
- 所有这些内容被打包归档并发送到对象存储（S3 兼容）。
顺便说一句，Velero 支持 Restic 和 Kopia。这意味着即使在没有云快照的环境中，你也可以进行增量文件系统备份。
实践示例
假设我们需要备份 namespace app-production 中的整个应用。终端命令大概是这样的：
velero backup create production-backup --include-namespaces app-production
如果一周后有人不小心删除了那个 namespace，恢复只需要几分钟：
velero restore create --from-backup production-backup
有趣的是，Velero 可以在恢复过程中动态修改资源参数。例如，如果旧的 StorageClass 在新集群中不可用，你可以更改磁盘的 StorageClass。
兼容性细节
Velero 的开发者维护着相当严格的兼容性矩阵。当前，版本 1.18 已针对最新的 Kubernetes 版本（最高 1.35）进行了测试。这很重要，因为 Kubernetes API 变化很快，旧工具在集群升级时经常会出问题。
该项目隶属于云原生计算基金会（CNCF），这提供了一定的保障：它不会明天就消失，而且其安全性正在被持续关注。
值得投入吗
如果你在生产环境中运行 Kubernetes，并且磁盘上有任何数据（数据库、队列、配置存储），Velero 是必备工具。
谁一定会从中受益：
- 需要高枕无忧的 SRE 工程师。
- 经常在集群之间迁移的团队。
- 需要用真实的最新生产数据来调试复杂 bug 的开发者。
从 velero.io 的官方文档开始。它相当详细，虽然有时看起来信息量很大。需要记住的最重要的事情是：只有当你至少成功从备份恢复过一次，这个备份才算真正存在。在将真实数据托付给这个工具之前，先在测试集群中尝试一下。
相关项目