k8s etcd备份恢复

张3232026-04-28 10:21

第一部分：前置核心认知

1. 为什么备份的是 etcd？------ etcd 是集群的 "数据心脏"

etcd 是 Kubernetes 集群的 核心分布式键值存储数据库，整个集群的所有数据都存储在这里，备份 etcd 本质就是备份整个集群的所有配置与状态。

|--------------|----------------------------------------------------------|----------------------------|
| 核心特性 | 说明 | 对备份恢复的意义 |
| 键值存储 | 类似超大分布式字典，通过 key 快速读写 value，无复杂表结构 | 数据结构简单，快照备份 / 恢复效率极高 |
| 分布式强一致 | 多节点集群，基于 Raft 算法同步数据，保证过半节点存活即可正常工作 | 集群数据不会因为单节点故障丢失，备份快照可跨节点恢复 |
| 集群唯一状态中心 | 存储所有 K8s 资源：Pod/Deployment/Service 配置、节点信息、认证授权、集群状态变更记录 | 只要 etcd 数据完好，集群就能完整恢复 |

etcd 就是 K8s 集群的 "数据库"，数据库坏了，整个集群就废了；备份 etcd 就是给整个集群做完整的灾备。

2. 我们的集群是怎么来的------ kubeadm 标准化部署

我们操作的集群，是通过 kubeadm 搭建的，这是 K8s 官方的标准化部署工具，所有备份恢复用到的默认路径，都是它自动生成的标准配置。

kubeadm 是什么？

kubeadm 是 K8s 官方提供的集群部署脚手架，帮你自动化完成集群搭建的所有脏活：

  • 自动生成集群所有 TLS 安全证书（etcd、apiserver 等）

  • 自动部署控制平面组件（apiserver、控制器、调度器、etcd）

  • 自动配置 kubelet、kube-proxy，生成节点加入集群的命令

  • 支持集群升级、证书轮换、标准化运维

kubeadm 备份恢复高频默认路径（必须记牢）

|------------------------------|---------------------------------------------------------|
| 路径 | 作用 |
| /etc/kubernetes/pki/ | 集群所有 TLS 证书存放目录，备份恢复时的证书凭证都来自这里 |
| /etc/kubernetes/manifests/ | 控制平面静态 Pod 的清单目录，kubelet 会根据这个目录管理 apiserver、etcd 等核心组件 |
| /var/lib/etcd | etcd 数据的默认存储目录，恢复时会把快照数据写到这里 |

3. 操作前的权限准备：kubectl 上下文（Context）

备份恢复是集群最高风险操作，必须用管理员权限执行，这就需要先切换 kubectl 的上下文。

什么是上下文？

上下文 = 一套连接集群的完整登录配置套餐，包含三个核心信息：

  1. 要连接的集群地址

  2. 登录用的用户身份（权限）

  3. 默认操作的命名空间

通俗理解：你的电脑可以同时连接多个 K8s 集群（测试、开发、生产），上下文就相当于 "切换登录的集群 + 账号"，告诉 kubectl：你现在要操作哪个集群、用什么身份。

核心命令拆解
复制代码 
kubectl config use-context kubernetes-admin@kubernetes

这个命令是备份恢复前的第一步，拆解如下：

  • kubectl config：操作 kubectl 的连接配置文件（默认存放在 ~/.kube/config）

  • use-context：切换当前要使用的上下文

  • kubernetes-admin：kubeadm 自动生成的集群超级管理员用户，拥有最高操作权限

  • kubernetes：kubeadm 自动生成的集群名称

合起来就是：切换为超级管理员身份，连接当前的 K8s 集群，拿到操作备份恢复的完整权限

常用上下文查看命令
复制代码 
# 查看当前正在使用的上下文
kubectl config current-context

# 查看你电脑上所有可连接的集群/上下文
kubectl config get-contexts

第二部分：etcd 备份操作全解析

备份的核心是给 etcd 数据库生成一份完整的快照文件，用于后续故障恢复。

1. 备份前的准备

  1. 切换管理员上下文（见上文）

  2. 安装 etcd 客户端（如果未安装）

    复制代码 
    apt install etcd-client -y

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 /srv/etcd-snapshot.db
命令参数逐行解释

|--------------------------------------|-------------------------------------------------------|
| 参数 | 作用 |
| ETCDCTL_API=3 | 指定使用 etcd v3 API，K8s 1.13+ 都用 v3，v2 不支持快照功能，必须加这个环境变量 |
| --endpoints=https://127.0.0.1:2379 | 要连接的 etcd 客户端地址，这是 kubeadm 单 Master 集群的默认配置 |
| --cacert/--cert/--key | etcd 的 TLS 认证凭证，kubeadm 自动生成的证书路径，用来证明你有访问 etcd 的权限 |
| snapshot save | 生成 etcd 完整快照的命令 |
| /srv/etcd-snapshot.db | 备份快照的保存路径 |

3. 高频疑问：为什么备份用 127.0.0.1:2379？它和 Master 节点 IP 有关系吗？

这是备份操作最容易困惑的点，核心结论：它俩不是没关系，而是强绑定在 Master 节点上的本地配置

为什么是 [127.0.0.1](127.0.0.1)？

kubeadm 部署的单 Master 集群中，etcd 默认是运行在 Master 节点上的静态 Pod，它的安全配置是：

  1. 仅监听本地回环地址 ：etcd 的启动参数 --listen-client-urls 默认就是 https://127.0.0.1:2379，意思是：只接受来自本机的请求，不监听 Master 的物理网卡 IP，外部节点根本连不上

  2. 证书信任匹配 ：kubeadm 生成的 etcd 证书，默认把 127.0.0.1 加入了信任列表，用这个地址连接，证书校验会直接通过

  3. 稳定安全：本地回环连接不经过网卡，不会被防火墙、网络策略拦截，备份过程最稳定，也避免了 etcd 暴露在外部网络的风险

它和 Master 节点 IP 的关系？

  • 127.0.0.1 是 Linux 节点自带的本地回环地址，在你的 Master 节点上，它就代表 "这台 Master 节点自己"

  • 你在别的节点上用 127.0.0.1 连接，连的是那个节点自己，根本找不到 etcd

  • etcd 证书其实也信任 Master 的物理 IP，但 etcd 没监听那个 IP，所以你就算用物理 IP 也连不上

Master 节点是一间办公室，门牌号是 192.168.1.10（物理 IP），127.0.0.1 就是 "办公室内部" 的代称，etcd 只在办公室内部开了窗口，只接内部的请求，外面的人就算知道门牌号也进不来。

4. 备份后的验证

备份完成后，可以用这个命令验证快照文件的有效性：

复制代码 
ETCDCTL_API=3 etcdctl --write-out=table snapshot status /srv/etcd-snapshot.db

正常会输出快照的版本、数据大小等信息，证明备份文件完好。

5. 高频误解：为什么不能直接拷 /var/lib/etcd 目录当备份？

疑惑：既然可以 mv 备份 etcd 数据目录，为什么还要用 etcdctl？ 核心是：你看到的 mv 命令是「恢复失败后的回滚操作」，不是日常备份，两者完全不是一回事，两种备份方式的区别如下：

|-------------|--------------------------------|-----------------------------------|
| 对比项 | etcdctl snapshot 官方备份 | 直接拷贝 /var/lib/etcd 目录 |
| 备份模式 | 热备份：etcd / 集群正常运行，业务完全不中断 | 冷备份：必须先停 etcd，否则数据会损坏 |
| 数据一致性 | etcd 内部生成原子快照，100% 一致，可提前验证完整性 | 运行时拷贝会出现半写数据，备份大概率损坏，停服务拷贝也无法提前验证 |
| 对业务影响 | 无影响，生产环境可定时自动备份 | 必须停整个控制平面，集群不可用，生产环境无法接受 |
| 备份文件实用性 | 单文件、体积小、可跨节点 / 跨版本恢复，方便传输存储 | 零散文件、体积大、绑定当前节点环境，无法跨版本迁移 |

通俗类比：这就像 MySQL 备份，etcdctl snapshot 相当于官方的热备份工具 xtrabackup，不停库就能备份；而直接拷数据目录，相当于停掉 MySQL 后冷拷，只有临时回滚的特殊场景才会用，根本没法当日常备份。

第三部分：etcd 恢复操作全解析

恢复是把备份的快照文件，还原成 etcd 的数据，让集群回到备份时的状态，核心是恢复前必须停止集群写入，避免数据不一致。

1. 恢复前的关键准备：停止集群写入

etcd 恢复过程中，绝对不能有新的写入，否则会导致数据冲突、恢复失败，所以我们要先停掉控制平面组件：

复制代码 
# 1. 备份 manifests 目录，让 kubelet 停止管理静态 Pod，停掉 apiserver/etcd 等组件
mv /etc/kubernetes/manifests /etc/kubernetes/manifests.bak

# 2. 备份旧的 etcd 数据目录，防止恢复失败可以回滚
mv /var/lib/etcd /var/lib/etcd.bak

为什么移动 manifests 就能停组件？因为 kubeadm 的控制平面是静态 Pod，kubelet 会监控 /etc/kubernetes/manifests/ 目录，目录移走后，kubelet 就会把对应的 apiserver、etcd 等 Pod 全部删掉，整个集群就停止了写入。

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 \
snapshot restore /srv/etcd_exam_backup.db
新增参数解释

|----------------------------|-------------------------------------|
| 参数 | 作用 |
| --data-dir /var/lib/etcd | 恢复后 etcd 数据的存放路径，就是 kubeadm 的默认数据目录 |
| snapshot restore | 快照恢复命令，把备份的快照文件还原成 etcd 数据 |
| /srv/etcd_exam_backup.db | 你之前备份的快照文件路径 |

3. 恢复后的集群重启

恢复完成后，把之前停掉的组件恢复回来：

复制代码 
# 1. 恢复 manifests 目录，kubelet 会自动重新拉起控制平面组件
mv /etc/kubernetes/manifests.bak /etc/kubernetes/manifests

# 2. 重启 kubelet，让配置生效
systemctl restart kubelet.service

4. 恢复后的验证

等待几分钟，组件启动完成后，验证集群是否恢复正常：

复制代码 
# 查看节点是否恢复 Ready
kubectl get nodes

# 查看 kube-system 命名空间的 Pod 是否全部正常
kubectl get pods -n kube-system

# 验证你的业务资源是否都回来了
kubectl get pods

第四部分：易错点与补充说明

1. 多 Master 高可用集群的备份恢复

如果是多 Master 集群，操作逻辑完全一样：

  • 每个 Master 节点的 etcd 都监听本地的 127.0.0.1:2379

  • 你只需要在任意一个 Master 节点上执行备份 / 恢复命令即可，因为 etcd 集群的数据是一致的

2. 为什么不能省略证书参数？

etcd 默认开启了 TLS 认证，没有证书的话，你根本连不上 etcd，这是集群的安全机制，kubeadm 部署的集群默认强制开启，所以必须指定那三个证书路径。

3. 恢复失败了怎么办？

如果恢复过程中出问题，你可以直接回滚：

复制代码 
# 把旧的 etcd 数据恢复回来
mv /var/lib/etcd.bak /var/lib/etcd
# 把 manifests 恢复回来
mv /etc/kubernetes/manifests.bak /etc/kubernetes/manifests
# 重启 kubelet
systemctl restart kubelet.service

就能回到恢复前的状态，不会丢数据。

第五部分：操作速查表（快速过流程）

|----------------|---------------------------------------------------------------------------------------------------|
| 步骤 | 命令 |
| 1. 切换管理员上下文 | kubectl config use-context kubernetes-admin@kubernetes |
| 2. 安装 etcd 客户端 | apt install etcd-client -y |
| 3. 执行备份 | 备份命令（见上文） |
| 4. 恢复前停写入 | mv /etc/kubernetes/manifests /etc/kubernetes/manifests.bak mv /var/lib/etcd /var/lib/etcd.bak |
| 5. 执行恢复 | 恢复命令（见上文） |
| 6. 恢复集群 | mv /etc/kubernetes/manifests.bak /etc/kubernetes/manifests systemctl restart kubelet.service |
| 7. 验证集群 | kubectl get nodes、kubectl get pods -n kube-system |

相关推荐
PSLoverS2 小时前
CSS如何实现自适应宽度的标签页_利用CSS变量计算Tab宽度
jvm·数据库·python
2301_787312432 小时前
MySQL版本迁移中如何处理全局变量_手动比对新旧配置文件
jvm·数据库·python
深念Y2 小时前
AI时代办公格式的演进：PPT与Word的替代已现，Excel将走向何方？
数据库·人工智能·html·word·powerpoint·excel·markdown
LiAo_1996_Y2 小时前
JavaScript中利用宏任务拆分阻塞任务的实操案例
jvm·数据库·python
qq_349317482 小时前
如何在 Go 中安全高效地将 SSH 公钥复制到远程服务器
jvm·数据库·python
SQL必知必会2 小时前
SQL 入门：第一条查询怎么写？从 SELECT、WHERE 到 GROUP BY 讲清楚
数据库·sql
东风破1372 小时前
DM达梦数据库体系结构学习记录
数据库·学习
djjdjdjdjjdj2 小时前
如何配置外键的ON DELETE CASCADE_删除父记录自动清理子记录的级联设置
jvm·数据库·python
热门推荐
01近期有什么ai的新消息，新动态？ 2026.4月02GitHub 镜像站点032026年4月AI大事件深度解读：大模型竞争进入“深水区“042026年AI编程工具终极横评：Cursor vs Claude Code vs Copilot052026年AI前瞻：量子AI、具身智能与科学发现的新纪元06Codex 接入 DeepSeek API 完整配置文档07在Windows 11上安装Docker的踩坑记录08零基础教你claude code 接入 deepseek V409DeepSeek V4 全面解析：测评、对比、案例及实操指南10codex app每次打开重连5次Reconnecting问题解决