K8s崩了也不怕：用Velero快速恢复环境

集群在新环境里被完整拉起来，所有服务陆续恢复，对外接口能正常访问，数据库数据也回来了。

下面把这套从备份到恢复的实操流程把来龙去脉讲清楚，都是能在真机上跑通的步骤，不是纸上谈兵。先说最直接的“把旧集群掏空、在新环境里挽回”的操作路径：当旧集群彻底不能用了，我们把备份挂到新集群上，执行一次恢复，等服务回到线上。这过程大体分几步，细节掌握住就不容易出岔子。

先说恢复怎么做。前提是你得在新集群里把 Velero 安装好，并且让它能访问之前备份放的对象存储（列如阿里云 OSS、AWS S3 或兼容 S3 的 MinIO）。安装好后，用一条恢复命令把某个备份还原过来。执行后你会看到 Velero 在重建各种 Kubernetes 对象：Deployment、Service、ConfigMap、CRD、Namespace 等，还会把持久卷的数据从对象存储或是快照那里拉回来。时间长短看数据量和网络，几分钟到几十分钟不等。恢复结束后要重点检查：关键服务的 Pod 是否都跑起来了，对应的 PVC 是否绑定正常，应用对外的端口和负载均衡（LoadBalancer）是否恢复访问。如果这些东西都有了，说明恢复基本成功。

说回备份这头。要做一个能用的备份，得把关键的资源和持久卷都打包进去。常见做法是同时保留一次全量备份和若干次按命名空间分的备份。缘由也简单：全量备份能保证“万一所有东西都挂掉还能全部拉回来”，命名空间级备份能在局部问题时做到快恢复。操作上可以用 velero backup create 来做——全量备份把所有命名空间包括进去，针对生产环境的命名空间单独再建一个备份以便快速回滚。备份创建后，要用 velero backup get 列出清单，确认状态是 Completed，并看清创建时间、过期时间、存放位置。别忘了也要有保留策略，设个到期自动清理，避免对象存储被老备份填满。

安装和配置 Velero 要注意的点不少。需要先把 Velero CLI 放到 PATH，然后准备对象存储的凭证文件。部署时会指定提供商、镜像、插件、备份桶名和凭证路径，另一种常见设置是如果不使用云厂商的 Volume Snapshot，就把基于云快照的功能关掉（列如 –use-volume-snapshots=false）。安装完成后，用 kubectl get pods -n velero 看控制器和相关 Pod 是否都处于 Running 状态。以阿里云 OSS 为例，安装命令里会带上 –provider alibabacloud、对应插件镜像和 –backup-location-config region=cn-hangzhou 之类的配置，凭证由 –secret-file 指定。实操的时候把每一步的日志看清楚，别心存侥幸。

讲讲 Velero 到底能干啥。它不仅把 Kubernetes 对象导出来，还能把持久卷的数据一并备份和恢复；能做定时备份，还能把应用从一个集群搬到另一个集群。具体能处理的资源包括 Deployment、Service、Ingress、ConfigMap、Secret、PV/PVC、StorageClass、CRD、RBAC、Namespace 等。把这些功能组合起来，就能在发生灾难时把“死掉”的集群在新环境里重建成可用状态。这个工具的工作机制也很直白：集群里跑着服务端组件负责接收备份和恢复请求，CLI 用来下命令，备份文件最终落在对象存储里；如果备卷用云快照，Velero 会调用云商的 Volume Snapshot API，否则把卷数据处理后上传到对象存储。恢复时会按备份里的元数据顺序把资源重建起来，再把卷数据恢复回 PVC。

说点为什么必须做灾备的事。潜在能把集群“归零”的情形有好几种：etcd 被误删或损坏，控制面失去关键状态；机房级别故障或节点集体失联；PV 的数据丢失；关键对象（列如 Helm release、CRD、Service）被误删；或者云厂商自身出现故障影响到整个服务。碰到这些情况，靠手动用 kubectl 一个个配回去太慢也容易出错，有备份就等于是把重建当成一次有章可循的“恢复剧本”。

实操中常被忽视的细枝末节不止一项。第一，对象存储的权限和凭证要管好，备份桶的访问策略和密钥保管都很重大；第二，版本兼容性不能忽视，Velero 的插件、镜像版本要和目标集群环境搭配好，别换了个集群把版本差异当成问题；第三，带宽和备份窗口要规划好，数据量大的备份会占网速，最好安排在低峰时段；第四，CRD 的恢复顺序很关键，先恢复 CRD，再恢复对应自定义资源，否则会报错。

给几条常用命令和操作顺序，方便实操参考：

– 下载并安装 Velero CLI，把可执行文件放到系统 PATH。

– 把对象存储的 AccessKey/Secret 写成凭证文件或设置到环境变量里。

– 在集群里运行 velero install，指定提供商、镜像、插件、桶名和凭证路径；若不使用云快照，传入相应参数关闭快照功能。

– 创建备份：可以做全量备份，也可以只对某个命名空间备份；创建后用 velero backup get 查看状态。

– 恢复：在新集群安装好 Velero 并能访问一样对象存储后，执行 velero restore create –from-backup <备份名> –wait，跟着看恢复过程。

– 定时与清理：用 velero schedule 创建周期任务，带上 TTL（生存时间）参数实现自动过期删除，列如每天凌晨做备份并在十天后自动过期。

别忘了有个常见特例是阿里云 OSS 的插件安装，参数里用 –provider alibabacloud，并带上插件镜像和 region 配置，凭证文件通过 –secret-file 指定。部署完后用 kubectl get pods -n velero 来确认控制器和插件都起来了。

在生产环境里，这套流程最好自动化，不只是手工触发就完事。备份触发、备份成功的监控、失败告警、以及定期的恢复演练都应该放进 CI/CD 或运维流水线里。把备份文件的生命周期管理、访问审计、恢复演练纳入日常流程，会比到了出事才手忙脚乱靠谱得多。

实操提议别少了这些：先做一次小规模恢复演练，确认备份里包含了所有必需资源；备份策略里把重大命名空间和 PV 单独标记；定期检查对象存储可访问性和凭证有效期；把恢复流程写成脚本并接入告警，减少单点人工失误。平时可以用 kubectl get pods -n velero、velero backup get、velero restore get 来跟踪状态，出问题时看 Velero 控制器日志找堆栈信息定位缘由。