1. ETCD在Kubernetes中的核心作用

作为Kubernetes集群的大脑，ETCD存储着整个集群的所有关键数据：节点信息、Pod状态、服务发现配置、Secret内容等。这个分布式键值数据库一旦发生数据损坏或丢失，将直接导致集群瘫痪。2017年某知名云服务商就曾因ETCD故障导致大规模服务中断，影响数千个线上业务。

重要提示：生产环境中ETCD数据必须定期备份，备份文件需要加密存储并测试恢复流程。我见过太多团队只做备份不验证恢复，真到用时发现备份文件损坏的情况。

2. 完整备份方案设计与实施

2.1 备份策略制定原则

根据金融级灾备要求，我通常采用"3-2-1"备份原则：

• 3份拷贝（本地+异地+离线）
• 2种介质（SSD+对象存储）
• 1份离线存储（如磁带库）

具体到ETCD备份，推荐以下配置组合：

# 每日全量备份（保留7天）
0 2 * * * /usr/local/bin/etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db

# 每小时增量备份（保留24小时）
0 */1 * * * /usr/local/bin/etcdctl snapshot save /backup/etcd-incr-$(date +%Y%m%d%H).db

2.2 关键备份参数解析

执行备份时需要特别注意这些参数：

etcdctl snapshot save \
  --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 \
  /backup/etcd-snapshot.db

各参数作用：

• --endpoints : 指定ETCD服务地址（生产环境建议用VIP）
• --cacert : CA证书路径（验证服务端身份）
• --cert/client-key : 客户端证书密钥对（双向TLS认证）
• 最后参数为备份文件存储路径

2.3 备份文件安全处理

备份完成后需要立即进行以下操作：

1. 校验备份完整性

   etcdctl snapshot status /backup/etcd-snapshot.db -w table
   

   输出应包含正确的哈希值和键值数量

2. 加密备份文件（使用AES-256）

   openssl enc -aes-256-cbc -salt -in etcd-snapshot.db -out etcd-snapshot.db.enc -k pass:YourStrongPassword
   

3. 同步到异地存储

   aws s3 cp etcd-snapshot.db.enc s3://your-bucket/etcd/$(date +%Y%m%d)/
   

3. 灾难恢复实战演练

3.1 单节点恢复流程

当单个ETCD节点故障时，按此步骤恢复：

1. 停止故障节点服务

   systemctl stop etcd
   

2. 恢复数据目录

   etcdctl snapshot restore /backup/etcd-snapshot.db \
     --data-dir /var/lib/etcd-restore \
     --name infra1 \
     --initial-cluster infra1=https://192.168.1.1:2380 \
     --initial-cluster-token etcd-cluster-1 \
     --initial-advertise-peer-urls https://192.168.1.1:2380
   

3. 修改systemd服务文件

   [Service]
   Environment="ETCD_DATA_DIR=/var/lib/etcd-restore"
   

4. 启动服务并验证

   systemctl daemon-reload
   systemctl start etcd
   etcdctl endpoint health
   

3.2 全集群灾难恢复

当整个ETCD集群崩溃时，需要：

1. 在所有节点停止服务

   for node in {node1,node2,node3}; do
     ssh $node "systemctl stop etcd"
   done
   

2. 选择最新备份文件，在所有节点执行：

   etcdctl snapshot restore snapshot.db \
     --data-dir /var/lib/etcd-new \
     --name $NODE_NAME \
     --initial-cluster "infra1=https://192.168.1.1:2380,infra2=https://192.168.1.2:2380" \
     --initial-cluster-token new-etcd-cluster \
     --initial-advertise-peer-urls https://$CURRENT_NODE_IP:2380
   

3. 统一更新所有节点的服务配置后启动

4. 生产环境经验总结

4.1 性能优化技巧

• 备份时添加 --lease 参数可以保留租约信息
• 使用 --max-snapshots 限制本地保留的快照数量
• 对于超过10GB的大集群，建议在业务低峰期执行备份

4.2 常见故障处理

问题1 ：恢复时报错"snapshot file integrity check failed"

• 原因：备份文件传输过程中损坏
• 解决：重新从源存储获取备份，添加校验步骤

问题2 ：集群节点无法加入新集群

• 原因：旧集群数据未清理干净
• 解决：彻底删除 /var/lib/etcd 目录后重试

问题3 ：恢复后API Server连接失败

• 检查项：
  1. ETCD服务端口(2379)是否监听
  2. 证书配置是否正确
  3. 防火墙规则是否放行

4.3 监控与告警配置

建议部署以下监控指标：

• etcd_backup_last_success_timestamp
• etcd_backup_size_bytes
• etcd_restore_duration_seconds

Prometheus告警规则示例：

- alert: EtcdBackupFailed
  expr: time() - etcd_backup_last_success_timestamp > 86400
  for: 1h
  labels:
    severity: critical
  annotations:
    summary: "ETCD备份失败超过24小时"

5. 高级备份方案

对于大规模生产集群，可以考虑：

5.1 增量备份方案

结合etcd的MVCC特性，通过定期获取修订版本号实现增量备份：

LAST_REV=$(etcdctl endpoint status --write-out=json | jq -r '.[0].Status.header.revision')
etcdctl snapshot save --rev=$LAST_REV incremental.db

5.2 跨云容灾方案

1. 在主集群部署etcd-backup-operator
2. 配置自动同步到备用云厂商的对象存储
3. 定期在备用环境验证备份可用性

5.3 备份验证自动化

使用Kubernetes Job定期测试恢复：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: etcd-backup-verify
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: verify
            image: etcdctl
            command: ["/bin/sh", "-c"]
            args:
              - etcdctl snapshot restore /backup/etcd-latest.db --data-dir=/tmp/etcd-verify &&
                etcdctl get / --prefix --keys-only | wc -l > /tmp/keycount &&
                [ $(cat /tmp/keycount) -gt 1000 ] || exit 1
          restartPolicy: OnFailure

这套方案在我管理的多个生产集群中稳定运行超过两年，成功帮助客户在几次重大故障中快速恢复业务。记住，备份的真正价值不在于创建了多少备份文件，而在于能否在需要时快速可靠地恢复。