etcd 快照恢复是什么
Kubernetes 的全部控制面数据都存在 etcd 里：从快照重建一个 etcd 数据目录，再让控制面组件指向新目录，就能修复误删资源、误改配置或数据损坏后的集群状态。恢复是覆盖式动作，需要停机窗口，多成员集群要按官方步骤处理成员清单与启动顺序。
基本信息
| 适用对象 | 自建 Kubernetes 集群与独立部署的 etcd |
|---|---|
| 前提条件 | 有一份可用快照（由定时任务或人工执行产生） |
| 核心命令 | etcdctl snapshot status 检查、etcdctl snapshot restore 恢复 |
| 影响范围 | 恢复期间控制面不可用，业务 Pod 通常继续运行 |
| 关键要点 | 恢复目录的属主与权限必须和原 etcd 进程一致 |
| 版本要求 | 建议使用与集群 etcd 同版本的 etcdctl，跨大版本按官方路径处理 |
典型使用场景
- 误删关键命名空间或自定义资源后的状态回退
- etcd 数据目录损坏、进程无法启动
- 升级失败导致大量 API 对象异常
- 定期演练：验证快照真的能恢复（最重要的场景）
- 集群迁移：用快照把资源集合带到新集群
恢复流程
恢复流程
# 1) 先检查快照是否可用并查看元信息
etcdctl snapshot status /backup/etcd-2026-10-13.db --write-out=table
# 2) 停止 kube-apiserver 与 etcd 进程，控制面进入停机窗口
systemctl stop kube-apiserver etcd
# 3) 恢复到新数据目录，不要直接覆盖原目录
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-2026-10-13.db --data-dir=/var/lib/etcd-restore --name=etcd1 --initial-cluster=etcd1=https://10.0.0.11:2380 --initial-advertise-peer-urls=https://10.0.0.11:2380
# 4) 修正属主与权限，并让 etcd 指向新数据目录
chown -R etcd:etcd /var/lib/etcd-restore
# 5) 启动 etcd 与控制面，做健康检查
etcdctl endpoint health --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.keysnapshot status 读法
| 字段 | 含义 | 正常/异常 |
|---|---|---|
| hash | 快照文件哈希 | 用于确认快照未被截断或损坏 |
| revision | 快照对应的 etcd 版本号 | 与预期时间点不符说明拿错了快照 |
| total keys | 键总数 | 明显偏少说明快照不完整或来自别的集群 |
| total size | 数据文件大小 | 与集群规模严重不符要警惕 |
| version | 写入该快照的 etcd 版本 | 与当前集群差异大时先查官方升级路径 |
恢复前先把当前数据目录整体复制一份：恢复是覆盖式动作，万一新目录起不来，还能退回现场继续排查。
多成员集群不能只在一台机上覆盖数据目录：成员清单、peer 地址与启动顺序都要按官方步骤处理，否则集群起不来。