K8s 集群不是不需要备份，只是你还没被教育过：Velero / Kasten 在大规模集群里的真实落地

“K8s 集群不是不需要备份，只是你还没被教育过：Velero / Kasten 在大规模集群里的真实落地”

我先抛一句可能有点扎心的话：

你觉得 Kubernetes 不需要备份，
多半是因为你还没遇到过“删库跑路级别”的事故。

我见过的真实场景包括但不限于：

• 运维同学 kubectl delete ns 手滑
• Helm 回滚失败，把 CRD 一锅端
• 存储插件升级，PV 还能看到，数据没了
• 集群升级失败，只能重建，业务问：数据呢？

每次事故之后，大家都会突然统一口径一句话：

“我们是不是该把备份这事儿认真搞一搞了？”

这篇文章，我不讲“备份很重要”这种废话，
我只讲：在大规模 K8s 集群里，Velero / Kasten 到底怎么用，才不翻车。

一、先泼冷水：Kubernetes 的“备份”到底在备什么？

很多人一上来就问：

“Velero 和 Kasten 哪个好？”

这个问题 80% 的时候是问错的。

你得先搞清楚一件事：
K8s 的备份 ≠ 数据库备份

在 Kubernetes 世界里，你真正要备的有三层：

1️⃣ 集群元数据（最容易被忽略）

• Namespace
• Deployment / StatefulSet
• ConfigMap / Secret
• CRD（重点！）

这些东西没了，
数据就算还在 PV 里，你也不知道怎么用。

2️⃣ 持久化数据（最容易被误解）

• PV / PVC

• 底层可能是：

  • Ceph
  • NFS
  • 云厂商 Block / File Storage

这里的关键不是“能不能备”，
而是：

能不能和应用状态对齐

3️⃣ 应用一致性（最容易被忽略但最致命）

• 数据库 flush 了吗？
• 应用有没有 quiesce？
• 分布式组件是不是“半写入状态”？

说白了：
不是你把文件拷走就叫备份。

二、Velero：K8s 世界的“基础款救生衣”

我先说结论：

Velero 非常适合做“集群级兜底备份”，
但你指望它解决所有数据一致性问题，那是为难它。

Velero 擅长什么？

一句话：

备 Kubernetes 对象 + 简单 PV 快照

一个典型 Velero 备份命令

velero backup create prod-backup-202501 \
  --include-namespaces prod \
  --snapshot-volumes \
  --ttl 168h

这条命令背后干了几件事：

1. 把 K8s 资源 YAML 打包
2. 调用 CSI / 云厂商接口做快照
3. 元数据存到对象存储（S3 / OBS / OSS）

优点非常明显：

• 简单
• 社区成熟
• 出事时真能救命

但 Velero 的坑，你一定要提前知道

❌ 1. 大规模集群下，备份时间不可控

• 几千个 Namespace
• 几万个 PVC
• 一个备份跑几小时是常态

解决方式：

• 按 Namespace / Label 拆分备份
• 不要全量一锅端

❌ 2. 应用一致性靠“自觉”

Velero 本身并不知道：

• MySQL 有没有 FLUSH TABLES
• Kafka 有没有停写
• ES 有没有 sync

你得自己加 Hook。

annotations:
  pre.hook.backup.velero.io/command: '["/bin/sh","-c","mysqladmin flush-tables"]'

说实话，这一步在大规模环境里，很难靠人工维护。

三、Kasten：不是更高级，而是更“工程化”

我一般会这么形容：

Velero 是“工具”，
Kasten 是“平台”。

Kasten 解决的核心问题只有一个：

“备份这件事，能不能不靠运维记忆力？”

在大规模集群里，最怕的不是技术不行，
而是：

• 谁该被备？
• 备到哪？
• 多久备一次？
• 出事谁能恢复？

一个 Kasten 的真实优势点

1️⃣ 策略驱动，而不是命令驱动

apiVersion: config.kio.kasten.io/v1alpha1
kind: Policy
spec:
  frequency: "@daily"
  retention:
    daily: 7
    weekly: 4

你不用天天 velero backup create，
而是：

“符合条件的工作负载，自动进入备份轨道。”

2️⃣ 天然理解应用 + 存储关系

Kasten 会把这些事儿帮你理清楚：

• 哪些 Pod 绑定了哪些 PVC
• 这个 PVC 背后是什么存储
• 恢复时，资源顺序怎么排

这点在 Stateful 应用里非常值钱。

3️⃣ 跨集群恢复是“一等公民”

Velero 也能做，但你要手动处理很多坑。

Kasten 的设计目标之一就是：

“这个集群炸了，我能不能在另一个集群拉起来？”

四、大规模集群的真实落地经验（重点）

下面这部分，是我觉得最值钱的。

经验一：别想着“一个方案覆盖所有业务”

我们最后的做法是：

不要迷信工具，工具只是兜底手段。

经验二：备份成功 ≠ 能恢复

这是很多团队踩过的大坑。

我们后来强制规定：

每个月，必须做一次“假装集群炸了”的恢复演练

恢复命令没人会用？
权限不够？
恢复后应用起不来？

这些问题，
只有真恢复一次，才会暴露。

经验三：把“备份状态”暴露给业务

我们做了一个很简单但很有效的事：

• 每个 Namespace 标一个：

  • backup: enabled / disabled

• 不在备份范围的，业务负责人签字

从那以后，
“数据没了找运维”的事少了一大半。

五、我个人的一点“不太政治正确”的观点

说点可能不好听的：

很多团队不是不懂备份，
是不愿意为“低概率灾难”买单。

但运维这个岗位，本来就是：

• 平时没人记得你
• 出事全世界找你

Velero、Kasten 这些工具，
不是让你显得多专业，
而是让你在凌晨三点出事时：

至少手里有一张牌。

写在最后

如果你现在的 K8s 集群：

• 没有任何备份策略
• 或者“有，但没人验证能不能恢复”

那我建议你认真问自己一句：

“要是真全没了，我敢不敢扛？”

工具可以慢慢选，
但备份这件事，越晚越贵。