Etcd 和 kubernetes master的灾备与恢复

本文详细介绍了在某台带有etcd的Kubernetes Master节点完全故障时的灾备与恢复流程,包括etcd的集群恢复及Kubernetes Master的恢复步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Etcd和kubernetes master的灾备与恢复

背景说明

问题:假设某台带有etcd的k8s master节点完全故障,彻底无法恢复

方案:新启动一台主机,配置为故障master主机相同的ip和主机名,并尝试原地恢复,顶替原故障master节点

Etcd恢复

参考官方文档:

https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md#restoring-a-cluster

注意:从官方文档可得知,备份快照时会改变cluster id(改变cluster id不影响客户端,客户端是使用ip来连接访问的),因此,需要etcd cluster的每个成员都参与备份与恢复。

检查
~# export ENDPOINTS="https://10.90.1.238:2379,https://10.90.1.239:2379,https://10.90.1.240:2379"

~# etcdctl --endpoints=$ENDPOINTS --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem --cacert=/etc/etcd/ssl/ca.pem  member list
316dbd21b17d1b4f, started, NODE238, https://10.90.1.238:2380, https://10.90.1.238:2379, false
8a206cf1ed53b6f4, started, NODE240, https://10.90.1.240:2380, https://10.90.1.240:2379, false
e444265665d3bd32, started, NODE239, https://10.90.1.239:2380, https://10.90.1.239:2379, false

~# etcdctl endpoint health --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem
https://10.90.1.239:2379 is healthy: successfully committed proposal: took = 16.882627ms
https://10.90.1.240:2379 is healthy: successfully committed proposal: took = 17.046735ms
https://10.90.1.238:2379 is healthy: successfully committed proposal: took = 19.395533ms

~ # kubectl get nodes
NAME        STATUS   ROLES    AGE    VERSION
ubuntu238   Ready    master   123d   v1.15.3
ubuntu239   Ready    master   123d   v1.15.3
ubuntu240   Ready    master   123d   v1.15.3

确认正常无误

开始备份

关停客户端
# 3台分别执行,二进制安装的关停相应组件服务
service kubelet stop
service docker stop
备份快照

在每一台etcd节点上分别执行:

# 修改为对应节点的ip
export EP="https://10.90.1.238:2379"

export ETCDCTL_API=3

mkdir -p /var/lib/etcd_bak

etcdctl --endpoints=$EP --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem --cacert=/etc/etcd/ssl/ca.pem   snapshot save  /var/lib/etcd_bak/`hostname`-etcd_`date +%Y%m%d%H%M`.db

systemctl stop etcd

mv /var/lib/etcd /var/lib/etcd_old

拷贝文件:

scp -r /etc/etcd/ssl/* NEW_HOST
scp -r /etc/systemd/system/etcd.service  NEW_HOST
scp  /var/lib/etcd_bak/ubuntu238-etcd_202001011000.db  NEW_HOST

将备份出的快照文件、ssl认证文件、systemd启动脚本,拷贝到新主机上,同时,在新主机上安装好docker、kubelet、kubectl、etcd服务,安装步骤这里省略,由于这几个组件都是go语言的二进制程序,因此可以直接将原主机的执行文件scp到新主机上相同路径中,不必花费精力去找相应版本的rpm包。

恢复备份

在新加入的一台替换主机,和保持不变的另外2台主机上执行:

必须每台成员主机全部执行,因为etcd协商的cluster id等一些元数据发生了改变

# 这3个环境变量相应修改
export NODE_NAME=NODE238
export NODE_IP=10.90.1.238
export SNAPSHOT=ubuntu238-etcd_202001011000.db

export ETCDCTL_API=3
export ETCD_NODES="NODE238"=https://10.90.1.238:2380,"NODE239"=https://10.90.1.239:2380,"NODE240"=https://10.90.1.240:2380
export ENDPOINTS="https://10.90.1.238:2379,https://10.90.1.239:2379,https://10.90.1.240:2379"

cd /var/lib/etcd_bak/

etcdctl snapshot restore  $SNAPSHOT \
--name=$NODE_NAME \
--cert=/etc/etcd/ssl/etcd.pem \
--key=/etc/etcd/ssl/etcd-key.pem \
--cacert=/etc/etcd/ssl/etcd-ca.pem \
--initial-advertise-peer-urls=https://$NODE_IP:2380 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=$ETCD_NODES \
--data-dir=/var/lib/etcd/

完成以上步骤后,3台etcd主机上一起启动etcd并检查状态:

~ # service etcd start
~ # etcdctl endpoint health --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem
https://10.90.1.240:2379 is healthy: successfully committed proposal: took = 16.112222ms
https://10.90.1.238:2379 is healthy: successfully committed proposal: took = 16.126138ms
https://10.90.1.239:2379 is healthy: successfully committed proposal: took = 17.345037ms

etcd恢复成功!

K8s master恢复

如果是原主机不动,则无需操作,如果是替换为新主机,则需要将如下文件拷贝至新主机上(适用于kubeadm安装的k8s,二进制需要对应修改):

  • /etc/kubernetes/目录下的所有文件(证书,manifest文件)
  • 用户(root)主目录下 /root/.kube/config文件(kubectl连接认证)
  • /var/lib/kubelet/目录下所有文件(plugins、容器连接认证)
  • /etc/systemd/system/kubelet.service.d/10-kubeadm.conf(kubelet systemd 启动文件)

复制完成后,启动服务:

service docker start
service kubelet start

检查:

kubectl get nodes
NAME        STATUS   ROLES    AGE    VERSION
ubuntu238   Ready    master   123d   v1.15.3
ubuntu239   Ready    master   123d   v1.15.3
ubuntu240   Ready    master   123d   v1.15.3

不出意外的话,一分钟左右master就恢复了。

总结

master恢复还是很简单的,没什么好多说的,etcd的恢复比较麻烦一些,需要全部成员重新initial一次,一定要按步骤来,仔细一些不要错。

提示:操作需要中断客户端写入,即停止k8s服务,风险高,生产慎用!

<think>好的,我现在需要帮用户整理一个关于Kubernetes高可用部署的项目经验,用于他的简历。用户提到了三点:三master节点etcd高可用部署以及备份方案。用户是Linux运维工程师,所以需要突出他的技术能力项目细节。 首先,我要确定项目的结构内容。项目经验通常包括项目描述、项目过程反思收获三个部分。项目描述要简明扼要,说明项目的目的主要技术点。项目过程需要详细分步骤,展示用户的具体工作技术细节。反思收获则要总结遇到的问题学到的经验。 接下来,用户提到的三个主要部分:三master高可用、etcd高可用备份方案。这三个部分需要详细展开。三master部署需要考虑负载均衡,比如使用HAProxyKeepalived,以及kubeadm的配置参数。etcd的高可用需要明确部署方式,是单独集群还是堆叠式,以及SSL证书的配置。备份方案要包括备份策略、工具(比如etcdctl)恢复测试。 然后,我需要考虑用户作为运维工程师可能涉及的具体操作,比如使用Ansible进行自动化部署,编写部署脚本,监控日志收集(如PrometheusELK),以及可能遇到的挑战解决方案,比如证书问题、网络分区处理等。 在项目过程中,需要分步骤描述,比如架构设计、部署步骤、备份实施、验证测试等,每个步骤中的技术细节要具体,比如HAProxy的配置参数,etcd的systemd配置,备份脚本的编写,以及混沌测试的方法。 反思收获部分要体现用户的技术成长软技能,比如自动化的重要性、灾备的必要性、文档的重要性等。同时,可以提到遇到的挑战,比如证书管理、故障转移测试中的问题,以及如何解决这些问题。 需要确保使用中文,技术术语准确,并且符合用户简历的专业性。避免使用Markdown格式,但保留必要的技术名词结构。同时,要检查LaTeX格式是否正确,比如数学公式的正确使用,但在这个回答中可能不需要数学公式,所以需注意用户指令中的系统级指令是否有冲突。 最后,确保整个项目经验描述清晰,技术细节到位,能够体现用户的技术能力项目经验,帮助他在简历中脱颖而出。</think>以下是为您设计的简历项目经验模板,结合Kubernetes高可用集群部署的核心要点,突出技术深度实践成果: --- **项目名称:Kubernetes高可用生产集群部署灾备体系建设** **项目描述** 基于企业业务连续性需求,设计并实施Kubernetes高可用集群架构,实现包括3 Master节点高可用、etcd分布式集群部署、自动化备份恢复体系在内的完整解决方案。项目支撑日均百万级请求量的业务系统,保障全年可用性达99.99%。 **项目过程** 1. **架构设计阶段(3周)** - 采用`堆叠式拓扑`实现三Master高可用架构,通过HAProxy+Keepalived构建双VIP负载均衡层(API Server VIP: 192.168.100.100,ETCD VIP: 192.168.100.101) - 设计etcd集群独立部署方案,使用3节点组成`Raft共识集群`,配置TLS双向认证定期快照 ```bash # etcd启动参数示例 --name etcd1 \ --cert-file=/etc/etcd/ssl/etcd.pem \ --key-file=/etc/etcd/ssl/etcd-key.pem \ --peer-cert-file=/etc/etcd/ssl/etcd-peer.pem \ --peer-key-file=/etc/etcd/ssl/etcd-peer-key.pem ``` 2. **集群部署阶段(2周)** - 基于Ansible编写部署剧本,实现组件自动化安装 - 使用kubeadm初始化集群,关键配置参数: ```yaml controlPlaneEndpoint: "apiserver-vip:6443" etcd: external: endpoints: ["https://etcd1:2379","https://etcd2:2379","https://etcd3:2379"] caFile: /etc/etcd/ssl/ca.pem certFile: /etc/etcd/ssl/etcd.pem keyFile: /etc/etcd/ssl/etcd-key.pem ``` 3. **灾备体系建设(1周)** - 实施etcd多级备份策略: * 每日全量备份:`etcdctl snapshot save /backup/etcd-$(date +%s).db` * 实时增量备份:通过`etcd watch`机制同步至S3存储 - 编写自动化恢复脚本,实现5分钟内集群状态恢复 ```bash # 灾难恢复流程 etcdctl snapshot restore backup.db \ --data-dir /var/lib/etcd-new \ --name etcd-restore \ --initial-cluster "etcd-restore=https://new-node:2380" ``` 4. **验证调优(1周)** - 通过ChaosMesh实施混沌工程测试: * 模拟Master节点宕机:验证10秒内VIP漂移成功 * 注入网络分区:etcd集群自动选举新Leader耗时<200ms - 优化kubelet参数`--node-status-update-frequency=4s`提升节点状态感知速度 **反思收获** 1. **故障发现**:初期未配置etcd碎片整理,导致数据库大小超过8GB后出现性能抖动,通过添加`--auto-compaction-retention=72h`参数解决 2. **技术沉淀**: - 掌握Kubernetes核心组件高可用实现原理及故障转移机制 - 深入理解Raft共识算法在etcd中的实践应用 - 构建完整的灾备体系需考虑备份验证、恢复演练等全生命周期管理 3. **协作经验**:推动建立`变更三板斧`制度(预检、分批、回滚方案),使生产变更故障率降低70% --- **亮点包装技巧**: 1. 量化指标:可用性百分比、恢复时长、请求量级等数据增强说服力 2. 技术深度:展现对共识算法、网络方案等底层原理的理解 3. 故障处理:通过实际问题体现排障能力架构优化经验 4. 流程建设:突出技术方案之外的工程管理能力 建议根据实际实施细节调整参数场景描述,确保技术细节个人经验完全匹配。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值