前言前面几周我们把业务迁移、监控、日志全部搭完集群已经能正常跑、能看指标、能查日志。但说实话能跑不代表稳能看不代表扛故障。做过生产运维都懂K8s 最大的隐患永远不是业务 Pod而是集群本身。尤其是 ETCD一旦崩掉、数据损坏、误删数据整个集群直接瘫痪所有资源全部失效。这周我直接带大家落地生产真正能用的高可用、备份、故障恢复、节点替换全套流程。所有内容都是我线上真实踩坑沉淀下来的没有空话每一套操作、每一个报错、每一个修复命令都是生产实战打磨出来的。一、为什么生产 K8s 必须做 ETCD 备份干运维三年最深刻的体会平时从不备份出事连夜跑路。K8s 所有集群数据全部存在 ETCDPod、Deployment、Service、Ingress、PVC、权限、状态、配置、调度记录全部在 ETCD 里。ETCD 一旦损坏kube-apiserver 直接起不来kubectl 全部命令超时所有业务虽然还在跑但无法变更、无法发布、无法扩容节点慢慢失联集群彻底瘫痪很多新人踩坑觉得集群好好的不用备份等误删 ns、etcd 崩了、磁盘坏道直接傻眼。生产标准底线每日自动备份 备份有效性校验 定期恢复演练二、环境说明标准 kubeadm 三 master 高可用集群ETCD 静态 pod 运行所有节点已时间同步集群业务正常运行中三、ETCD 手动快照备份生产标准操作日常做变更、升级、改核心配置前必须手动快照一次。1. 先确认 ETCD 集群健康状态ETCDCTL_API3 etcdctl \ --endpointshttps://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 \ endpoint health全部返回healthy再继续操作有异常坚决不做变更。2. 创建备份目录我生产统一放在/data/etcd-backup统一管理mkdir -p /data/etcd-backup3. 手动快照备份命令生产通用ETCDCTL_API3 etcdctl \ --endpointshttps://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 /data/etcd-backup/etcd-$(date %Y%m%d-%H%M).db4. 校验备份是否有效很多人漏这一步备份文件生成不代表能用磁盘满、中断、IO 异常都会导致备份损坏。校验命令ETCDCTL_API3 etcdctl snapshot status /data/etcd-backup/你的备份文件.db能输出 hash、revision、keys 数量才算真正备份成功。四、企业级自动定时备份脚本带自动清理 校验手动备份不靠谱人会忘生产必须脚本定时跑。1. 编写 etcd-backup.sh#!/bin/bash BAK_DIR/data/etcd-backup DATE$(date %Y%m%d-%H%M%S) mkdir -p $BAK_DIR # 执行快照备份 ETCDCTL_API3 etcdctl \ --endpointshttps://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 $BAK_DIR/etcd-$DATE.db # 校验备份有效性 ETCDCTL_API3 etcdctl snapshot status $BAK_DIR/etcd-$DATE.db if [ $? -eq 0 ];then echo [$DATE] 备份成功 $BAK_DIR/success.log else echo [$DATE] 备份失败 $BAK_DIR/error.log fi # 自动清理7天前旧备份 find $BAK_DIR -name etcd-*.db -mtime 7 -delete2. 授权并测试chmod x /data/etcd-backup/etcd-backup.sh bash /data/etcd-backup/etcd-backup.sh3. 配置定时任务每天凌晨 2 点自动备份crontab -e写入0 2 * * * /data/etcd-backup/etcd-backup.sh /data/etcd-backup/run.log 21五、ETCD 故障完整恢复流程集群瘫痪救命操作我线上遇到过好几次误删集群资源、etcd 数据损坏、节点异常导致集群无法读写。恢复核心经验三年运维总结三台 master必须全部停止 kubelet不能只恢复一台三台 master全部清空旧 etcd 数据目录三台必须用同一份快照文件恢复恢复完必须修正权限不然 apiserver 起不来1. 所有 Master 停止 kubeletsystemctl stop kubelet2. 所有 Master 备份损坏的旧数据目录千万不要直接删防止恢复失败需要回退mv /var/lib/etcd /var/lib/etcd-bak-err3. 在任意一台 Master 执行快照恢复ETCDCTL_API3 etcdctl \ snapshot restore /data/etcd-backup/有效备份.db \ --data-dir/var/lib/etcd4. 关键步骤修复目录权限90% 的人恢复失败都是因为这步etcd 运行用户是 etcdroot 恢复后的目录权限不对直接起不来chown -R etcd:etcd /var/lib/etcd chmod 700 /var/lib/etcd5. 所有 Master 启动 kubeletsystemctl start kubelet6. 集群恢复校验等待 2~3 分钟集群自愈kubectl get nodes kubectl get all -A资源全部恢复、节点全部 Ready 即为恢复成功。六、生产节点故障替换实战线上机器硬件损坏、磁盘坏道、内核崩掉是常态必须熟练替换节点。1. Worker 节点故障下线先驱逐业务再删节点绝对不能直接删机器# 驱逐节点业务 kubectl drain k8s-worker01 --ignore-daemonsets --delete-emptydir-data # 删除故障节点 kubectl delete node k8s-worker01新节点重装系统后重新获取 join 命令加入集群kubeadm token create --print-join-command2. Master 节点故障替换高可用核心master 故障不能直接删要先清理 etcd 成员不然集群一直异常# 查看异常成员 ETCDCTL_API3 etcdctl \ --endpointshttps://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 \ member list # 删除故障节点ID ETCDCTL_API3 etcdctl \ --endpointshttps://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 \ member remove 故障ID # 删除故障节点 kubectl delete node k8s-master03新 master 加入高可用集群kubeadm join 集群IP:6443 \ --tokenxxxx \ --discovery-token-ca-cert-hash sha256:xxxx \ --control-plane七、生产真实踩坑 超详细解决方法坑 1只备份不校验出事发现备份全部损坏现象平时定时备份看着日志正常集群崩了准备恢复发现备份文件为空、损坏、无法识别。真实原因服务器磁盘满、IO 卡顿、备份过程中断脚本退出但没有报错提示肉眼看不出异常。详细解决方法必须在备份脚本里加入自动校验我现在所有生产脚本都带校验ETCDCTL_API3 etcdctl snapshot status $BAK_DIR/etcd-$DATE.db if [ $? -eq 0 ];then echo [$DATE] 备份成功 $BAK_DIR/success.log else echo [$DATE] 备份失败 $BAK_DIR/error.log fi每天看一眼 error.log有问题立刻处理。坑 2ETCD 恢复后 kube-apiserver 一直 CrashLoopBackOff现象etcd 恢复看着没问题但是 apiserver 起不来集群完全不可用。真实原因用 root 账号恢复快照生成的 /var/lib/etcd 目录属主是 rootetcd 进程没有读写权限直接卡死。详细解决方法所有 master 节点统一执行权限修复chown -R etcd:etcd /var/lib/etcd chmod 700 /var/lib/etcd systemctl restart kubelet执行完等待 1~2 分钟集群自动恢复。坑 3只恢复单台 master导致集群脑裂、数据分裂现象恢复完一台 master另外两台旧数据还在集群状态混乱一会正常一会异常。真实原因ETCD 集群三节点数据不一致新旧数据共存直接脑裂。详细解决方法生产恢复硬性规范三台 master 全部停止 kubelet三台全部移动旧数据目录三台全部用同一份快照恢复三台统一修复权限三台同时启动 kubelet严格按我上面的完整恢复流程操作不会出问题。坑 4备份目录日积月累磁盘爆满现象没人管备份目录几十天备份堆积磁盘 100%导致节点卡死。详细解决方法脚本强制自动清理 7 天前备份无需人工干预find /data/etcd-backup -name etcd-*.db -mtime 7 -delete坑 5节点时间不同步ETCD 集群不健康现象节点时间差几秒etcd 集群间歇性 unhealthy集群不稳定。详细解决方法所有节点统一部署时间同步yum install chrony -y systemctl enable --now chronyd chronyc tracking确保所有节点时间一致这是集群稳定的基础。八、生产运维规范面试超级加分生产 K8s禁止单 master必须三 master 高可用所有核心变更前手动快照备份每天自动备份 自动校验 自动清理每季度必须做一次灾备恢复演练保证备份可用故障节点先驱逐、再删除绝不直接删节点严禁手动修改、删除 /var/lib/etcd 目录九、本周总结这周内容属于运维保命级技能。平时开发、部署业务谁都会但真正拉开运维差距的就是故障处理、灾备恢复、集群维稳。学完这周你彻底掌握ETCD 手动 自动企业级备份集群瘫痪完整恢复流程Master、Worker 节点故障替换生产高频坑点全套解决方案现在你的 K8s 集群不仅能跑业务还能扛故障、可恢复、可灾备完全达到企业生产标准。下周预告第 8 周K8s 网络深度实战Service 负载均衡、NodePort、Ingress 七层路由、NetworkPolicy 隔离、Cilium eBPF 网络优化吃透 K8s 最难点网络体系。