一、为什么备份必须从etcd的一致性逻辑出发

很多人觉得备份Kubernetes就是备份节点的文件，其实不对，Kubernetes的所有配置——比如Pod数量、命名空间、服务发布记录、权限规则，都存在etcd这个分布式存储里。etcd的核心是“一致性”，就像一个小组做决策，必须超过一半成员同意，数据才会生效、不会冲突。如果备份的时候只拷了某一个节点的文件，这个文件可能和其他节点的数据不一致，恢复后集群直接报错，所以备份前必须先搞懂etcd的一致性要求，不然备份的是“假数据”。

1.1 etcd一致性的通俗解释

举个例子：3个节点组成etcd集群，要改一个资源，得至少2个节点同意，改完后所有节点的数据都一样。如果某个节点崩了，剩下的节点还是能正常读写，不会丢数据。所以我们要备份的，是etcd集群里所有节点都认可的那一份数据，不能是单独某个节点的本地文件。

二、etcd备份的完整落地方案

2.1 提前准备的必要条件

在备份之前，你得先拿到etcd的证书，因为etcd默认是加密访问的，就像进办公室得有门禁卡一样。证书一般放在Kubernetes的pki目录，比如/etc/kubernetes/pki/etcd，这个路径若有修改要对应调整。另外，你得有专门存备份的目录，比如/opt/etcd-backup，最好用独立磁盘，别和系统盘混放，防止系统盘损坏丢备份。

2.2 手动备份etcd的具体操作

手动备份适合测试环境或临时紧急备份，用etcd原生快照命令即可，示例在Kubernetes Master节点执行：

# 设置etcd API版本为3（API 2已被淘汰）
export ETCDCTL_API=3
# 生成带日期的备份文件，确保清晰可区分
etcdctl snapshot save /opt/etcd-backup/etcd-backup-$(date +%Y%m%d).db \
--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

执行后用ls /opt/etcd-backup/就能看到生成的备份文件，确认备份成功。

2.3 自动定时备份方案（生产环境必备）

手动备份太繁琐，生产环境必须用定时任务，比如Linux的crontab，设置凌晨2点（业务低峰期）备份，同时自动删除7天前的旧备份节省空间，示例：

# 切换root用户，编辑定时任务（普通用户无权限操作etcd证书）
sudo su
crontab -e
# 插入以下内容，保存退出即可生效
0 2 * * * export ETCDCTL_API=3 && etcdctl snapshot save /opt/etcd-backup/etcd-backup-$(date +%Y%m%d).db --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 && find /opt/etcd-backup -name "etcd-backup-*.db" -mtime +7 -delete

这个定时任务既保证备份时效性，又控制了备份占用的磁盘空间。

2.4 备份文件的有效性校验

备份后要确认文件有效，用etcdctl的快照校验命令，示例：

# 查看备份的快照状态，确认数据一致性
etcdctl snapshot status /opt/etcd-backup/etcd-backup-20240520.db \
--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

执行后显示总键数、版本等信息，无报错说明备份有效。

三、etcd备份后的恢复方案

备份的核心是应对故障，比如误删核心命名空间、Master节点全损，这时候必须按步骤恢复，避免集群出错。

3.1 常见恢复场景

比如开发人员误删生产测试命名空间、Kubernetes Master节点全部损坏、etcd某节点数据异常，这些场景都需要用备份恢复。

3.2 恢复前的准备

恢复时要停止所有访问etcd的Kubernetes组件，防止数据冲突，示例命令：

# 停控制平面组件，切断对etcd的读写
systemctl stop kube-apiserver
systemctl stop kube-controller-manager
systemctl stop kube-scheduler
systemctl stop etcd # 先停etcd才能操作数据目录

3.3 用快照恢复etcd数据

恢复时要替换原有数据目录，必须和原集群配置一致，示例：

# 先备份原有etcd数据，防止恢复失败可回滚
mv /var/lib/etcd /var/lib/etcd.bak
# 用快照恢复，指定数据目录和集群节点配置
etcdctl snapshot restore /opt/etcd-backup/etcd-backup-20240520.db \
--data-dir=/var/lib/etcd \
--initial-cluster="etcd-node1=https://etcd-node1:2380,etcd-node2=https://etcd-node2:2380,etcd-node3=https://etcd-node3:2380" \
--initial-cluster-token=etcd-cluster-0 \
--initial-advertise-peer-urls=https://etcd-node1:2380
# 修改etcd配置文件，确保地址匹配后启动etcd
systemctl start etcd
# 等etcd启动完成，再启动控制平面组件
systemctl start kube-apiserver kube-controller-manager kube-scheduler

3.4 恢复后的验证

启动后确认集群正常，用以下命令：

# 查看节点状态，应该都是Ready
kubectl get nodes
# 查看命名空间，确认未丢失
kubectl get ns

四、应用场景

4.1 开发测试环境快速回滚

开发环境常做各种测试，改配置出问题时，用备份快速恢复，不用重新搭建集群，节省时间。

4.2 生产环境容灾备份

生产环境可用性要求高，定时备份可应对节点故障、误操作，核心业务场景下能快速恢复，减少业务中断时间。

4.3 集群版本升级预案

升级Kubernetes版本前必须备份etcd，万一升级失败，可快速回滚到升级前状态，避免业务中断。

五、技术优缺点分析

5.1 优点

  1. 一致性有保证：用etcd原生快照命令，确保备份数据是集群认可的一致版本，无数据冲突。
  2. 恢复速度快：几十分钟就能恢复整个集群，远比重建快。
  3. 成本低：用etcd自带命令完成，无需额外工具，适配各种规模集群。

5.2 缺点

  1. 生产环境需维护校验：定时备份后要定期检查备份文件有效性。
  2. 恢复期间集群不可用：恢复时需停控制平面，期间集群无法对外服务，需提前规划时间。
  3. 占用磁盘空间：备份频繁或保留时间长会占磁盘，需定期清理旧备份。

六、注意事项

  1. 备份存独立存储：别和集群节点用相同磁盘，建议用对象存储（OSS、S3），防止节点全损丢备份。
  2. 证书妥善保管：etcd证书是访问核心，不能泄露或丢失，否则备份恢复无法操作。
  3. 版本匹配：备份时的etcd版本要和恢复时的集群版本一致，否则会不兼容。
  4. 禁止手动拷文件备份：直接复制/var/lib/etcd目录的备份不是一致的，必须用etcdctl快照命令。

七、总结

etcd是Kubernetes的核心存储，它的一致性是备份恢复的基础，不能只依赖工具，要从etcd的逻辑出发确保备份有效。落地方案要结合手动、自动备份，做好校验和恢复的全流程。生产环境必须重视etcd备份，它就是集群的“保险”，关键时刻能保住业务连续性。