📚 课程目录第4章集群架构与高可用设计

集群架构与高可用设计：etcd、控制平面、节点管理、故障域

本章聚焦Kubernetes集群的核心骨架——高可用设计。面试官常通过HA方案考察候选人对控制平面、etcd、节点容错和故障域隔离的综合理解。下面先通过一张回答框架图掌握高可用设计的回答路径，再通过3个面试问答卡片深入细节，最后用真实项目案例展示落地经验。

面试问答卡片

卡片1：如何设计高可用Kubernetes集群？

面试问题	请描述如何设计一个生产级高可用Kubernetes集群，包括关键组件配置要点。
考察点	是否理解控制平面、etcd、工作节点的HA关系；能否考虑升级、备份、故障转移等生命周期管理。
回答框架	分层论述：1) etcd集群奇数节点跨AZ部署，使用独立磁盘和快照备份；2) 控制平面多副本 + 前置负载均衡(LB) + 健康检查；3) 节点池按AZ分布，设置污点/容忍隔离系统组件；4) 利用Pod反亲和和拓扑分布约束实现故障域打散。
示例回答	我会将etcd三节点跨3个可用区部署，并用systemd自动重启；控制平面部署3份kube-apiserver，前方挂载内网NLB；工作节点按AZ分配并通过节点亲和性将关键Pod分散。同时定期做etcd快照备份到对象存储，确保故障30分钟内恢复。
可能追问	如果etcd集群出现脑裂如何发现和处理？跨AZ延迟对etcd性能影响多大？升级控制平面时如何保证APIServer不中断？
避坑提醒	❌ 不要只说“多副本”而忽略etcd的Raft协议特性；❌ 避免将etcd与控制平面混部在同一组机器上（资源争抢）；❌ 忘记说明跨AZ部署时的网络延迟容限配置。

卡片2：etcd集群故障的影响与保障

面试问题	etcd集群故障会导致什么后果？如何保障etcd高可用？
考察点	是否清楚etcd是K8s的“大脑”，故障导致集群不可读写；是否掌握Raft选举、磁盘IO、网络分区等关键风险。
回答框架	先说明影响：API不可用、调度停止、资源同步中断。然后从部署面（奇数节点、独立SSD、快照）、运维面（监控leader延迟、定期defrag、跨AZ冗余）、灾难恢复面（备份恢复、从成员重建）三个层面展开。
示例回答	etcd故障导致apiserver读写出错，Pod状态无法更新。我通过3节点跨AZ部署、使用本地NVMe磁盘降低fsync延迟，配合Prometheus监控etcd_db_total_size_in_bytes，在超过2GB时自动defrag，并且每晚自动快照到S3。
可能追问	etcd集群成员如何安全替换？如何排查etcd leader频繁切换？Raft中投票超时如何设置合适？
避坑提醒	❌ 不要低估磁盘IO的重要性（机械盘直接导致集群不稳定）；❌ 避免使用NFS或网络存储作为etcd数据目录；❌ 不要忘记关闭etcd的自动压缩后仍需手动defrag。

卡片3：故障域(Failure Domain)设计

面试问题	谈谈你对故障域的理解，在K8s中如何利用故障域提升集群韧性？
考察点	是否理解故障域层级（机房/AZ/机架/节点）；能否运用拓扑分布约束、Pod反亲和、节点亲和等原生机制。
回答框架	先定义故障域（物理或逻辑的隔离边界）。然后给出三种典型实现：1) 节点打标（topology.kubernetes.io/zone）区分AZ；2) 使用podAntiAffinity实现跨AZ调度；3) 使用topologySpreadConstraints实现均匀分布。最后结合有状态应用举例。
示例回答	我们为节点打上zone标签，对有状态StatefulSet施加podAntiAffinity: preferredDuringScheduling，并添加topologySpreadConstraints要求maxSkew=1。这样当单个AZ故障时，只有1/3的Pod受影响，且剩余Pod能继续服务。
可能追问	跨AZ网络延迟导致Pod健康检查失败怎么处理？如何自动化感知故障域变化？多集群联邦如何结合故障域？
避坑提醒	❌ 不要滥用强反亲和导致Pod无法调度；❌ 避免只关注AZ而忽略机架级别故障（例如交换机单点）；❌ 警惕跨AZ网络带宽和延迟对etcd及有状态应用的影响。

项目案例：金融级跨AZ Kubernetes集群迁移与高可用改造

以下项目案例可帮助你将理论落地到真实场景，作为面试“项目经验”的参考模板。

项目模板详情

项目名称	金融级跨AZ Kubernetes集群迁移与高可用改造
业务背景	原有单AZ集群承载核心交易系统，已多次出现单一节点故障导致服务降级，业务要求RTO<5分钟、RPO为0，必须迁移至跨AZ高可用架构。
规模指标	200+ 节点（物理机 + 虚拟机），5000+ Pods，每日处理百万笔交易；etcd存储约2GB，QPS峰值15000。
技术栈	Kubernetes 1.24 / etcd 3.5 / Calico CNI / Traefik Ingress / Prometheus + Grafana / Rook Ceph (持久卷) / 自研调度器插件
核心难点	① 跨AZ网络延迟对etcd写性能的影响；② 有状态应用（数据库、消息队列）跨AZ调度与数据同步；③ 迁移过程零停机，需灰度滚动升级。
面试高频追问	如何定量评估跨AZ延迟对etcd QPS的影响？如何设计StatefulSet的反亲和策略？Ceph跨AZ读写延迟如何优化？迁移过程中如何保证数据一致性？
可迁移回答话术	“我们通过分层剥离 + 灰度验证的方式，先在测试环境模拟跨AZ延迟，调优etcd的heartbeat-interval和election-timeout；对有状态服务采用区域优先 + 本地持久卷方案，同时利用PodTopologySpread实现跨AZ的均匀分布。最终将RTO从原来的15分钟降低到3分钟。”

💡 面试加分表达：在回答高可用设计时，主动提到“我们做过AZ故障演练，模拟丢包和延迟，验证了集群自愈能力”会让面试官认为你有实战经验。建议用数字（如“3个AZ”、“5节点etcd”、“RTO<5分钟”）增强说服力。

📌 复习要点：本章核心逻辑线为“分层→etcd→控制面→节点→故障域”。建议在面试前梳理一张手绘图，标注每个组件的HA配置参数（如etcd的--max-txn-ops、kube-apiserver的--max-requests-inflight），并熟记至少一个故障域的yaml配置片段。