3. etcd 备份与恢复:快照备份、数据恢复与定时策略
etcd 是 Kubernetes 控制平面的核心数据存储,所有集群状态(Pod、Service、ConfigMap、Secret 等)均以键值对形式持久化在 etcd 中。一旦 etcd 数据损坏或丢失,整个集群将无法正常调度、服务发现和状态同步。因此,etcd 的备份与恢复是云原生灾备体系的第一道防线。
3.1 etcd 快照备份
etcd 内置 etcdctl snapshot save 命令,可生成一致性快照文件。快照包含 etcd 在某一时刻的完整数据视图,不依赖外部存储引擎。
3.1.1 手动快照备份
在任意一个 etcd 节点上执行以下命令(需配置正确的端点与证书):
# 设置 etcdctl API 版本
export ETCDCTL_API=3
# 创建快照
etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /backup/etcd-snapshot-$(date +%Y%m%d%H%M%S).db
# 验证快照文件
etcdctl --write-out=table snapshot status /backup/etcd-snapshot-20250321143000.db
3.1.2 快照文件结构
| 字段 | 说明 | 典型值 |
|---|---|---|
| Hash | 快照内容的 SHA256 校验值 | 0x9a8b7c6d |
| Revision | 快照创建时的 etcd 全局修订版本号 | 1234567 |
| Total Key | 快照中包含的键值对总数 | 8923 |
| Total Size | 快照文件在磁盘上的大小 | 128 MB |
最佳实践:快照文件应至少保留最近 7 天的版本,并异地存储(如对象存储 S3、NFS 或远程备份服务器)。单次快照大小通常为 etcd 数据目录的 60%–80%,请预留足够磁盘空间。
3.2 etcd 数据恢复
当 etcd 集群出现数据损坏、节点故障或误删除关键资源时,可通过快照文件执行恢复操作。恢复流程分为“停止 etcd → 恢复数据 → 启动 etcd → 验证集群”四个阶段。
3.2.1 单节点恢复(测试/开发环境)
# 1. 停止 etcd 服务
systemctl stop etcd
# 2. 备份当前数据目录(可选)
mv /var/lib/etcd /var/lib/etcd.bak
# 3. 使用快照恢复数据
etcdctl snapshot restore /backup/etcd-snapshot-20250321143000.db \
--data-dir=/var/lib/etcd \
--name=etcd-0 \
--initial-cluster=etcd-0=http://127.0.0.1:2380 \
--initial-cluster-=etcd-cluster-1 \
--initial-advertise-peer-urls=http://127.0.0.1:2380
# 4. 启动 etcd 服务
systemctl start etcd
# 5. 验证集群健康
etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health
3.2.2 多节点集群恢复
对于生产环境的多节点 etcd 集群,恢复时需为每个节点分别执行 snapshot restore,并确保 --initial-cluster 参数包含所有成员地址。
| 节点 | --name | --initial-cluster | --data-dir |
|---|---|---|---|
| etcd-0 | etcd-0 | etcd-0=http://10.0.0.1:2380,etcd-1=http://10.0.0.2:2380 | /var/lib/etcd |
| etcd-1 | etcd-1 | etcd-0=http://10.0.0.1:2380,etcd-1=http://10.0.0.2:2380 | /var/lib/etcd |
恢复注意事项:
- 恢复后的 etcd 集群会丢失快照时间点之后的所有数据变更,请确认恢复时机。
- 恢复操作会重置集群成员 ID 和集群 ,原集群其他节点必须全部替换为新恢复的节点。
- 恢复完成后,需重启 kube-apiserver、kube-controller-manager、kube-scheduler 等控制面组件以重新连接 etcd。
3.3 定时备份策略
手动备份无法满足生产环境的 RPO(恢复点目标)要求,必须建立自动化定时备份机制。推荐使用 CronJob + 脚本或专用工具(如 etcd-backup-operator、Velero)实现。
3.3.1 基于 CronJob 的定时备份
以下 YAML 定义了一个 Kubernetes CronJob,每 6 小时执行一次 etcd 快照备份,并保留最近 4 份快照:
apiVersion: batch/v1
kind: CronJob
metadata:
name: etcd-snapshot-backup
namespace: kube-system
spec:
schedule: "0 */6 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: etcd-backup
image: bitnami/etcd:3.5.12
command:
- /bin/sh
- -c
- |
ETCDCTL_API=3
SNAPSHOT_FILE="/backup/etcd-snapshot-$(date +%Y%m%d%H%M%S).db"
etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/etcd/pki/ca.crt \
--cert=/etc/etcd/pki/server.crt \
--key=/etc/etcd/pki/server.key \
snapshot save $SNAPSHOT_FILE
# 保留最近 4 份,删除更早的快照
ls -t /backup/etcd-snapshot-*.db | tail -n +5 | xargs rm -f
volumeMounts:
- name: etcd-certs
mountPath: /etc/etcd/pki
- name: backup-storage
mountPath: /backup
volumes:
- name: etcd-certs
secret:
secretName: etcd-certs
- name: backup-storage
persistentVolumeClaim:
claimName: etcd-backup-pvc
restartPolicy: OnFailure
3.3.2 备份策略参数对比
| 策略维度 | 推荐值 | 说明 |
|---|---|---|
| 备份频率 | 每 4–6 小时 | 根据数据变更量调整,变更频繁可缩短至 1 小时 |
| 保留份数 | 7–14 份 | 覆盖最近 2–3 天的恢复窗口 |
| 存储位置 | 本地 + 远程对象存储 | 本地用于快速恢复,远程用于灾难级恢复 |
| 备份验证 | 每次备份后执行 snapshot status | 确保快照文件可读且 revision 正常递增 |
3.4 etcd 备份与恢复流程总览
下图展示了从定时备份到故障恢复的完整数据流:
关键指标:
- RPO(恢复点目标):取决于备份频率,每 6 小时备份一次则最多丢失 6 小时数据。
- RTO(恢复时间目标):从故障发生到集群恢复可用,通常为 5–15 分钟(取决于数据量和节点数)。
- 备份验证:每次备份后自动执行
snapshot status校验,确保快照文件完整可用。
3.5 备份策略决策树
根据集群规模和业务重要性,选择不同的备份策略组合:
生产环境推荐:使用 Velero 或 etcd-backup-operator 管理备份生命周期,支持自动加密、增量备份和跨区域复制。同时配置监控告警,当备份失败或快照校验不通过时立即通知运维人员。