第4章 Kubernetes集群架构与高可用面试：Master/Node组件、Etcd、负载均衡、故障转移
考点热度：🔥🔥🔥🔥🔥（高频）｜ 面试占比：约15%｜ 建议复习时长：3小时
本章聚焦K8s集群核心组件的协作原理、高可用设计思路及故障场景应对。面试官会从组件职责、数据流向、容错机制三个层面层层追问。你需要掌握「组件→通信→故障隔离→恢复策略」的完整链路，而非死记硬背端口号。
复习提示：回答高可用问题时，先按“组件-数据流-冗余-恢复”四层拆解；再举一个具体故障场景（如apiserver宕机）的恢复过程，体现系统性思维。
📌 面试问题1：请描述Kubernetes Master节点包含哪些核心组件？各组件的作用是什么？
🎯 考察点：基础组件认知、职责边界、数据流理解
📊 难度：⭐
回答框架：先总述Master四个组件 → 逐个说明职责 → 强调apiserver是唯一入口 → 简单提及高可用部署方式。
示例回答： Master节点包括kube-apiserver（统一入口，RESTful接口）、kube-scheduler（将Pod绑定到合适Node）、kube-controller-manager（运行各类控制器，如ReplicaSet）、etcd（集群状态存储）。高可用时部署多个apiserver+etcd集群，scheduler和controller-manager通过leader选举选主。
🔍 可能追问：apiserver无状态意味着什么？
🔍 追问：scheduler选主依赖什么机制？
⚠️ 避坑：不要遗漏etcd组件，不要混淆controller-manager和scheduler职责
📌 面试问题2：Etcd在K8s集群中的关键作用是什么？如何保证Etcd的高可用？
🎯 考察点：分布式存储原理、Raft协议、集群容错
📊 难度：⭐⭐⭐
回答框架：角色定位（存储所有集群状态）→ 数据模型（key-value + watch）→ 高可用通过Raft实现（奇数节点，多数派写入）→ 部署建议（独立节点、SSD、定期snapshot/defrag）。
示例回答： Etcd存储集群所有配置、状态和元数据，是K8s的“大脑”。高可用通过Raft共识算法实现：部署3或5个节点，只有多数节点（2N+1）写入成功才返回。我们生产环境使用3节点独立etcd集群，SSD磁盘，每2小时自动snapshot，防止数据丢失。
🔍 追问：Raft的leader选举和term机制？
🔍 追问：etcd集群脑裂怎么处理？
⚠️ 避坑：避免说“etcd强一致性但性能低”，面试官关注的是正确性和容错设计
📌 面试问题3：请描述K8s集群的kube-apiserver高可用方案以及请求负载均衡的实现方式。
🎯 考察点：负载均衡实践、apiserver无状态特性、健康检查
📊 难度：⭐⭐⭐
回答框架： apiserver无状态，可水平扩展 → 前端用四层LB（如Nginx/HAProxy）或云LB → 后端配置多个apiserver实例 → 健康检查端口 → 推荐使用keepalived + nginx或直接使用云原生LB。
示例回答： 我们使用3个apiserver实例，前方部署Nginx做四层代理。Nginx通过stream模块代理6443端口，并配置health_check_interval探测apiserver健康状态（/livez）。如果某个apiserver宕机，LB自动摘除，客户端通过VIP继续访问，实现秒级故障转移。
🔍 追问：为什么不用七层LB（HTTP）？
🔍 追问：kubelet如何连接到LB？
⚠️ 避坑：不要只说“用云LB就行”，要说出具体LB类型和配置细节
🔧 项目案例实战
项目模板：企业级K8s高可用集群方案设计与实施
| 项目名称 | 某金融科技公司容器云平台高可用改造 |
| 业务背景 | 原有单Master集群存在单点故障，业务要求99.99%可用性，需要构建跨可用区的高可用K8s集群 |
| 规模指标 | 管理200+ Node节点，3000+ Pod，日均API请求量约500万次，Etcd存储约2GB |
| 技术栈 | Kubernetes v1.26，Etcd v3.5，HAProxy + Keepalived，Prometheus + Grafana，Velero备份 |
| 核心难点 | ① Etcd集群延迟优化（跨AZ网络延迟约5ms）；② apiserver水平扩展后客户端连接池耗尽；③ 故障转移时scheduler重新调度Pod的浪涌问题 |
| 面试高频追问 |
|
| 可迁移回答话术 |
“在金融场景下，我们优先保证数据一致性和可恢复性。Etcd集群采用3节点跨AZ部署，设置--quota-backend-bytes=8GB，并开启自动压缩。apiserver前方LB配置maxconn限制，配合客户端sidecar重试策略。故障转移时，我们使用POD反亲和确保关键应用分布在不同的故障域。”
|
📌 面试加分提醒：提到“故障转移”时，一定要区分控制面故障（Master组件）和数据面故障（Node/工作负载）。控制面故障导致集群管理中断，但已有Pod正常运行；数据面故障需要node controller驱逐Pod。两者恢复方案不同，面试官非常看重这种分层意识。
📊 核心组件高可用设计对比表
💡 结构化记忆口诀：“API无状态，LB前面挡；调度和管控，选主保不慌；Etcd靠Raft，奇数节点抗；Node本地跑，DaemonSet帮。”