1、AI程序员系列文章

2、AI面试系列文章

3、AI编程系列文章

目录

1、

2、

3、etcd集群：K8s的"心脏"

为什么etcd如此重要？

Raft共识算法：少数服从多数

部署etcd集群

验证etcd集群健康状态

etcd快照备份：最后一根救命稻草

4、Master组件高可用

Controller Manager & Scheduler：选主机制

5、

6、

7、

8、

9、

开篇：那些让人崩溃的K8s故障

你是否遇到过这样的噩梦场景？

• Master节点宕机：整个集群瞬间变成"植物人"，kubectl命令全部超时，生产环境直接停摆
• etcd数据丢失：集群状态一夜回到解放前，所有Deployment、Service配置灰飞烟灭
• 升级时服务中断：以为只是打个补丁，结果业务挂了2小时，老板在群里疯狂@你

💡 效率技巧：生产环境的高可用不是可选项，而是必选项。就像你不能指望一台服务器永远不死机，也不能指望单Master的K8s能扛住生产流量。

本文将给出经过验证的K8s高可用架构方案，让你的集群真正做到"永不宕机"。

高可用架构全景图

先来看一张完整的架构图，理解各个组件是如何协同工作的：

核心组件说明

⚠️ 避坑警告：很多新手以为只要Master有3个节点就高可用了，结果etcd只部署了1个。记住：etcd是K8s的心脏，心脏停了，大脑（Master）再聪明也没用。

etcd集群：K8s的"心脏"

为什么etcd如此重要？

etcd存储了K8s的所有状态数据：Pod位置、Service配置、Secret、ConfigMap……可以说，etcd挂了，整个集群就失忆了。

Raft共识算法：少数服从多数

etcd使用Raft算法保证数据一致性。核心规则：

• 3节点集群：可容忍1个节点故障（需要2个节点存活）
• 5节点集群：可容忍2个节点故障（需要3个节点存活）

部署etcd集群

验证etcd集群健康状态

💡 效率技巧：etcd集群成员数量必须是奇数（3、5、7…）。偶数节点在故障时更容易出现"脑裂"，而且不会提高容错能力。

etcd快照备份：最后一根救命稻草

⚠️ 避坑警告：etcd快照备份必须定期进行，并存储在集群外部（如对象存储）。我见过太多人把备份放在etcd节点本地，结果节点挂了，备份也没了。

Master组件高可用

API Server：多副本+负载均衡

API Server是K8s的"前台接待"，所有操作（kubectl、控制器、调度器）都要通过它。实现高可用的关键是：多副本+负载均衡。

Controller Manager & Scheduler：选主机制

这两个组件不能同时运行多个活跃副本，否则会出现冲突。K8s通过Lease机制实现选主：

负载均衡器配置（Keepalived + HAProxy）

💡 效率技巧：故障切换时间可以控制在30秒以内。Keepalived的VRRP协议默认1秒宣告一次，3次未收到宣告就认为Master挂了，VIP漂移到备机。

Worker节点高可用

多可用区部署：不要把鸡蛋放在一个篮子里

污点与容忍：特殊工作负载的"VIP通道"

节点故障自动处理

⚠️ 避坑警告：不要把所有Worker节点放在同一个可用区！我见过某云厂商可用区故障，导致用户整个K8s集群瘫痪的案例。至少跨2个可用区部署，最好是3个。

集群联邦：多集群统一管理

什么时候需要集群联邦？

• 业务跨多个地域部署（北京、上海、广州）
• 需要跨集群的服务发现和流量调度
• 单集群规模太大（超过5000节点），需要拆分

使用Karmada部署联邦应用

💡 效率技巧：集群联邦不是银弹，它增加了架构复杂度。如果你的业务不需要跨地域部署，单集群+多可用区就够了。不要为了技术而技术。

备份策略：最后一道防线

三层备份体系

Velero安装与使用

自动化备份脚本

⚠️ 避坑警告：备份不是目的，恢复才是。定期做恢复演练！我见过太多人备份了几年，真正需要恢复时才发现备份文件损坏或无法使用。

故障演练：验证高可用性

演练清单

高可用性检查脚本

文末三件套

1. 【源码获取】

关注此系列获取后续更新，后台回复**‘k8sha’**获取本文完整配置脚本和架构图。

2. 【思考题】

你的K8s集群做过故障演练吗？如果现在就拔掉一台Master节点的网线，你的业务能撑多久？欢迎在评论区分享你的容灾方案。

3. 【系列预告】

• 服务网格：Istio/Linkerd深度实践，流量治理从此不再头疼
• 混合云：K8s跨云部署，摆脱厂商锁定
• 边缘计算：K3s+KubeEdge，把K8s延伸到边缘设备
• CI/CD：ArgoCD+Tekton，云原生时代的DevOps实践

总结

K8s高可用不是简单的"多部署几台机器"，而是一个系统工程：

记住：高可用是设计出来的，不是运维出来的。在架构设计阶段就考虑容错，比故障发生后再救火要有效得多。

标签：Kubernetes高可用 etcd集群 Master高可用 负载均衡 集群联邦 容灾备份

参考文档：

• Kubernetes官方高可用文档
• etcd集群运维指南
• Karmada官方文档