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 备份与恢复流程总览

下图展示了从定时备份到故障恢复的完整数据流:

etcd 备份与恢复流程 etcd 备份与恢复流程总览 CronJob 定时触发 etcd snapshot save 本地 + 远程存储 etcd 故障 / 数据损坏 停止 etcd 服务 snapshot restore 启动 etcd 服务 验证集群健康 恢复完成 RPO = 备份间隔时间 RTO ≈ 5–15 分钟
关键指标:
  • RPO(恢复点目标):取决于备份频率,每 6 小时备份一次则最多丢失 6 小时数据。
  • RTO(恢复时间目标):从故障发生到集群恢复可用,通常为 5–15 分钟(取决于数据量和节点数)。
  • 备份验证:每次备份后自动执行 snapshot status 校验,确保快照文件完整可用。

3.5 备份策略决策树

根据集群规模和业务重要性,选择不同的备份策略组合:

etcd 备份策略决策树 etcd 备份策略决策树 集群规模与重要性 小规模 / 测试集群 大规模 / 生产集群 频率:每 12 小时 保留:5 份本地快照 频率:每 4 小时 保留:14 份 + 远程存储
生产环境推荐:使用 Velero 或 etcd-backup-operator 管理备份生命周期,支持自动加密、增量备份和跨区域复制。同时配置监控告警,当备份失败或快照校验不通过时立即通知运维人员。