K8S集群Etcd数据备份/规复

为什么 etcd 必须备份

Kubernetes 集群里除了 etcd，没有任何持久化的「全局事实」——所有 Pod 调度状态、Deployment 副本数、Secret、ConfigMap、Service 都实时落在 etcd 里。控制平面的其他组件都是无状态的，etcd 一没，集群等于失忆。所以备份策略是 K8s 运维里最不能省的一项。

注意 etcd 即使只用 1 GB 数据，写入时也可能瞬间涨到数 GB，备份必须留足磁盘；同时备份要避开高写入峰值。

一、安装 etcdctl

1.1 先看集群里 etcd 的版本

kubeadm 部署的 etcd 是静态 Pod，配置写在 manifests 目录里，直接 grep 镜像标签：

root@master:~# cat /etc/kubernetes/manifests/etcd.yaml | grep image: | awk '{print $2}'
registry.aliyuncs.com/google_containers/etcd:3.5.10-0

拿到 3.5.10 就装 v3.5.10 的 etcdctl，版本必须和服务端一或相差不超过一个小版本，否则快照格式可能不兼容。

1.2 下载并部署 etcdctl

# 下载
root@master:~# wget https://github.com/etcd-io/etcd/releases/download/v3.5.10/etcd-v3.5.10-linux-amd64.tar.gz

# 解压
root@master:~# tar -zxvf etcd-v3.5.10-linux-amd64.tar.gz

# 放进可执行目录
root@master:~# mv etcd-v3.5.10-linux-amd64/etcdctl /usr/bin/
root@master:~# mv etcd-v3.5.10-linux-amd64/etcdutl /usr/bin/

# 验证
root@master:~# etcdctl version
Version: 3.5.10
ApiVersion: 3.5

如果服务器不能直连 GitHub，可以走国内镜像站下载 release 包，内容一致。

二、备份 etcd 数据

2.1 建备份目录

# 备份数据存放目录
mkdir /var/lib/etcd-backup

2.2 执行快照

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 /var/lib/etcd-backup/etcd-snapshot-`date "+%Y-%m-%d"`.db

四个参数别漏：--endpoints 指向本机 etcd 端口（kubeadm 默认 2379 且启用 TLS），--cacert/--cert/--key 三个 PEM 文件在 /etc/kubernetes/pki/etcd/ 下。指定 --endpoints 单端点，比 --cluster 多端点模式在排障时更可控。

2.3 校验快照完整性

ETCDCTL_API=3 etcdctl --write-out=table snapshot status /var/lib/etcd-backup/etcd-snapshot-`date "+%Y-%m-%d"`.db

输出里有 DB size、revision、total number of kvs。这一步能提前发现「快照 0 字节」这种假成功，务必每次备份都跑。

三、恢复 etcd 数据

恢复是有破坏性的操作——它会清空当前 etcd 数据目录，再用快照覆盖。执行前先跟业务方确认窗口期，并且一定要先把当前的 kube* 配置文件挪走。下文用的快照文件名按当天日期，实际操作时建议改成明确的历史快照名，别用 date 动态取当天（恢复当天可能该快照已被清理）。

3.1 停 API 组件并把配置挪走

# kube* 静态 Pod 配置临时备份目录
mkdir /opt/backup

# 恢复后数据的工作目录
mkdir /var/lib/etcd-restore

# 把 kube* 配置临时移出 manifests（静态 Pod 一消失，容器会被 kubelet 停掉）
mv /etc/kubernetes/manifests/kube* /opt/backup/

3.2 执行恢复

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 \
  --data-dir=/var/lib/etcd-restore \
  snapshot restore /var/lib/etcd-backup/etcd-snapshot-2024-06-01.db

--data-dir 指定恢复后数据的落点；不指定的话，会在当前执行目录自动生成一个 default.etcd 目录——这是最常见的事故来源，一定显式指定。

3.3 验证并搬回配置

# 确认数据已落在恢复目录
ls /var/lib/etcd-restore

# 把 kube* 配置移回原目录
cp /opt/backup/* /etc/kubernetes/manifests/

3.4 改 etcd.yaml 的数据目录并重启

# 先把原配置改名（把 bak 放前面，恢复完系统才好认）
mv /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests/bak.etcd.yaml

# 生成新 etcd.yaml：把数据目录整体替换成恢复目录
sed 's!/var/lib/etcd!/var/lib/etcd-restore!' /etc/kubernetes/manifests/bak.etcd.yaml > /etc/kubernetes/manifests/etcd.yaml

# 验证替换结果（第一条应无输出，第二条应能看到 restore 路径）
cat /etc/kubernetes/manifests/etcd.yaml | grep '/var/lib/etcd'
cat /etc/kubernetes/manifests/etcd.yaml | grep '/var/lib/etcd-restore'

# 重启 kubelet 拉起静态 Pod
systemctl daemon-reload
systemctl restart kubelet

这里把 bak 放在文件名前面是有讲究的：kubelet 扫描 manifests 目录时会忽略带 . 开头或后缀带 .bak/.disabled 之类标记的文件，但实践中发现后缀写法在恢复后仍可能被识别成源配置，所以统一前置成 bak.etcd.yaml，语义和识别都清楚。

3.5 验证恢复成功

kubectl get node
kubectl get pod -A

节点重新 Ready、Pod 重建完成就说明恢复生效了。再抽查一个关键对象确认数据完整：

kubectl get ns
kubectl get deploy -A

四、备份策略建议

• 定时 + 长保留：把 snapshot save 写进 cron（比如每 5 分钟或每小时），保留 7–30 天，别只留一份。
• 快照落到别的主机：/var/lib 在本机，机器一坏备份跟着没。rsync/scp 同步到独立存储或对象存储。
• 留足磁盘：etcd 数据目录所在的分区要给快照留 2 倍余量，否则备份写到一半磁盘满，整个集群反而被拖垮。
• 定期演练恢复：备份不做恢复演练等于没备份。至少每季度在测试环境完整走一遍 3.x 的恢复流程。
• 多 master 集群：确认 APIServer 指向的 etcd 成员是否健康，恢复时通常只从快照恢复一个成员再重建其余节点，别同时对多个成员执行恢复。

小结

etcd 备份三步：装对版本的 etcdctl → snapshot save 加四个 TLS 参数 → snapshot status 校验。恢复四步：挪走 kube* 停 API → snapshot restore --data-dir → 搬回配置并改 etcd.yaml 的 data-dir → 重启 kubelet 验证。最大的两个雷是 --data-dir 不写导致数据落在执行目录、以及恢复完忘了改 etcd.yaml 的路径，导致新 etcd 还在读旧数据，集群看着「起来了」实际是空的。

qidao123.com企服评测-应用市场 编辑提示