K8s集群备份策略：etcd物理备份与Velero逻辑备份实操指南

Kubernetes（K8s）已成为主流的容器平台，越来越多的公司将核心业务部署在 K8s 集群中。然而，集群一旦投入生产运行，就意味着我们必须直面各种运维风险：集群异常、误操作、etcd 数据损坏，甚至整套集群不可用。一旦发生这些问题，轻则导致业务中断，重则造成数据丢失，将直接影响线上服务的稳定性和业务连续性。

为了有效管理这些风险，K8s 的备份与恢复成为一项“必须提前准备”的基础能力。通过定期备份集群的关键数据和业务资源，在故障发生时我们才能拥有可靠的回退和兜底方案，快速恢复系统状态，避免长时间的停机。

K8s 备份方案选择

在生产环境中，主要有两种备份思路，它们各有侧重，适用于不同的故障场景。

备份类型	适用场景	优点	缺点
etcd物理备份	应对集群级故障，例如 etcd 崩溃、K8s 集群异常。	备份/恢复非常快（分钟级），适合紧急恢复。	只能恢复整个集群，不能恢复单个应用。
velero逻辑备份	应对业务级故障，例如误删某个命名空间、应用故障。	可精准备份、恢复指定命名空间或资源，备份文件可修改。	备份/恢复速度相对慢，不能恢复 etcd 层面的集群配置。

最佳实践：两者结合使用。将 etcd 备份作为“底线保护”（例如每小时一次），用于应对灾难性故障；同时利用 velero 进行“精细保护”（例如每天一次），用于应对应用层面的问题。这种组合策略可以全面覆盖不同层级的故障场景。

Etcd 物理备份

Etcd 是 Kubernetes 集群的大脑，存储着所有资源对象的状态数据。对其进行物理快照备份，是应对集群级灾难的最后防线。

适用场景

• 集群巡检时必须进行的操作。
• 在集群升级或修改核心组件（如 kube-apiserver）前，手动触发备份，防止操作失误导致集群不可用。

操作步骤

1. 创建备份脚本
自动化是运维的好帮手。我们可以编写一个 Bash 脚本，自动执行备份并管理备份文件的周期，避免磁盘被旧备份占满。

#!/usr/bin/env bash
set -e  # 脚本遇到错误立即退出

# 配置路径（根据实际环境调整）
ETCD_CA_CERT="/etc/kubernetes/pki/etcd/ca.crt"
ETCD_CERT="/etc/kubernetes/pki/etcd/server.crt"
ETCD_KEY="/etc/kubernetes/pki/etcd/server.key"
BACKUP_DIR="/opt/etcd_backup"  # 备份文件存储路径

# 创建备份目录
[ ! -d "${BACKUP_DIR}" ] && mkdir -p ${BACKUP_DIR}

# 删除7天前的备份文件
find ${BACKUP_DIR} -name "*.db" -mtime +7 -exec rm -f {} \;

# 执行etcd快照备份
ETCDCTL_API=3 /usr/local/bin/etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert="${ETCD_CA_CERT}" --cert="${ETCD_CERT}" --key="${ETCD_KEY}" \
  snapshot save "${BACKUP_DIR}/etcd-snapshot-$(date +%Y%m%d.%H%M%S).db"

2. 设置定时任务
通过 Linux 的 crontab 设置定时任务，让备份自动执行。

# 设置定时任务
crontab -e
# 在crontab中添加：每小时执行一次备份脚本
0 */1 * * * /bin/bash /opt/etcd_backup.sh >> /opt/etcd_backup.log 2>&1

Etcd 恢复

当 etcd 数据损坏或集群完全不可用时，就需要用到我们备份的快照文件了。

适用场景

• etcd 数据损坏、集群完全不可用。
• 注意：恢复操作会覆盖当前 etcd 中的所有数据，请确保你选择的恢复点是你需要的。

操作步骤

1. 准备恢复
在恢复之前，需要停止相关服务并清空旧数据目录。

# 停止 kube-apiserver 和 etcd 服务（以 systemd 为例）
systemctl stop kube-apiserver
systemctl stop etcd

# 清空 etcd 数据目录（谨慎操作！确认路径）
rm -rf /var/lib/etcd/*

2. 执行恢复
使用 etcdctl snapshot restore 命令从备份文件恢复数据。你需要根据集群的初始配置调整参数。

ETCDCTL_API=3 /usr/local/bin/etcdctl snapshot restore /tmp/etcd-snapshot-xxx.db \
  --name etcd1 \
  --initial-cluster “etcd1=https://<ip>:2380,etcd2=https://<ip>:2380,etcd3=https://<ip>:2380" \
  --data-dir=/var/lib/etcd

3. 验证恢复
恢复完成后，重启 etcd 和 kube-apiserver 服务，并检查集群健康状态。

systemctl start etcd
systemctl start kube-apiserver
ETCDCTL_API=3 /usr/local/bin/etcdctl endpoint health

Velero 逻辑备份

Velero 是一个强大的 Kubernetes 集群备份、恢复和迁移工具。它工作在资源层面，可以备份几乎任何 Kubernetes 资源，并支持存储卷的快照。

适用场景

• 误删了业务命名空间（如 prod），导致业务配置丢失。
• 业务版本发布前，备份当前稳定环境，方便发布失败时快速回滚。
• 跨集群迁移业务（如从测试集群迁移到生产集群）。

操作步骤

1. 安装 Velero
首先在安装了 kubectl 并能访问目标集群的机器上安装 Velero 客户端。

wget https://github.com/vmware-tanzu/velero/releases/download/v1.8.1/velero-v1.8.1-linux-amd64.tar.gz
tar -xvf velero-v1.8.1-linux-amd64.tar.gz
cp velero-v1.8.1-linux-amd64/velero /usr/bin/
chmod +x /usr/bin/velero
velero version

（请注意：还需要在集群中安装 Velero 服务端，这通常需要配置对象存储如 AWS S3、MinIO 等作为备份存储位置，具体安装步骤请参考官方文档。）

2. 创建定时备份任务
安装配置好后，可以创建定时备份计划。

# 创建备份计划，例如备份 prod 命名空间
velero create schedule prod-daily-backup \
  --schedule="0 1 * * *" \  # 每天凌晨1点执行
  --include-namespaces=prod \  # 备份指定命名空间
  --ttl=168h   # 保留7天

Velero 恢复

当应用或命名空间出现问题时，Velero 的恢复功能就派上了用场。

适用场景

• 误删 prod 命名空间、改坏了应用配置。
• 业务发布失败后，需要回滚到备份时的稳定状态。

操作步骤

1. 恢复整个命名空间（最常用）

velero restore create --from-backup prod-daily-backup-xxx

2. 恢复特定资源（例如只恢复某个 Deployment）

velero restore create \
  --from-backup prod-daily-backup-xxx \
  --include-resources=deployments \
  --include-namespaces=prod

总结与思考

K8s 集群的备份与恢复，远不止是系统维护清单上的一项任务，它是保障业务持续运行、应对突发故障的“生命线”。通过本文介绍的 etcd 物理备份与 Velero 逻辑备份相结合的策略，我们能够为云原生环境构建起立体的防护网。

etcd 备份确保了集群元数据的整体安全，是灾难恢复的基石；而 Velero 则提供了面向应用的、灵活精准的恢复能力，极大提升了日常运维的效率与容错空间。

当然，任何完善的方案都离不开持续的验证。定期演练恢复流程、测试备份文件的可用性，与制定备份策略本身同等重要。只有经过实战检验的备份，才能在真正故障来临时，让我们做到胸有成竹，快速响应。

希望这份结合了具体命令与实践思路的指南，能帮助你构建起更稳健的 Kubernetes 运维体系。如果你在实践中遇到其他问题或心得，欢迎在云栈社区与其他开发者交流探讨。