📚 课程目录第4章面试评分表与面试官视角分析

第4章 Kubernetes集群高可用架构设计

  章节聚焦：大厂 K8s 专家面试中，“高可用设计”是出现频率最高的系统设计题。面试官关注你能否在有限资源下权衡 控制面稳定性、数据面弹性 与 灾难恢复能力。

高可用设计决策矩阵

维度	关键组件	典型技术选型	常见陷阱
控制面	API Server / etcd / Controller Manager	3～5节点 etcd集群 + HAProxy + kube-vip	etcd成员数偶数导致选主失败
数据面	Pod / Service / Ingress	PodAntiAffinity + PDB + ClusterAutoScaler	PDB未设置 minAvailable 导致滚动更新阻塞
灾难恢复	etcd快照 / Velero / 跨集群迁移	每小时快照 + 异地对象存储	未定期演练恢复流程
可观测性	Prometheus / Grafana / Alertmanager	混合云统一告警 + 故障自愈 Pipeline	告警规则过于粗粒度导致“告警风暴”

📌 面试问题 1

问题：请设计一个生产级 Kubernetes 集群的高可用架构，集群规模约 2000 节点，横跨 3 个可用区。

面试官考察点：是否理解控制面与数据面解耦、etcd 容错模型、跨 AZ 流量成本。

回答框架：按五步法：①场景：2000 节点，管理面压力大，需拆分 etcd 与 kube-apiserver 层；②控制面：每 AZ 部署 1 个 Master 节点，共 3 节点 etcd 集群（奇数），使用 VIP+keepalived 实现 API Server 高可用；③数据面：PodAntiAffinity 跨 AZ 部署，设置 PDB 保证最小可用数，HPA 基于自定义指标；④灾难恢复：etcd 快照每 5 分钟存储到跨区域 S3；⑤可观测性：Prometheus + 大屏 + 故障自愈脚本。

简短示例回答（95字）：我会部署 3 个 AZ 各 1 个 Master，etcd 采用 3 节点集群并开启 TLS。API Server 通过 HAProxy 做负载均衡。Workload 设置 PodAntiAffinity 与 PDB，结合 Cluster Autoscaler 弹性。etcd 每 5 分钟快照，定期演练恢复。监控无死角，Alertmanager 配置分级告警。

可能追问：etcd 集群网络延迟过大怎么办？Master 节点故障时 kubelet 如何感知？

避坑提醒：切忌只谈抽象概念，必须给出具体版本号、组件搭配。例如“etcd 使用 v3.5，raft 选举超时配置为 1s”。避免说“用 x 云托管”来回避设计细节。

📌 面试问题 2

问题：假设 etcd 集群出现频繁 Leader 切换，你会如何排查与解决？

面试官考察点：对 etcd 内部机制（Raft、磁盘IO、网络）的掌握，以及排错方法论。

回答框架：①检查 etcd 指标（disk fsync duration、network latency）；②检查磁盘 IO 压力（是否与其他高 IO 应用共享磁盘）；③检查网络抖动（多 AZ 延迟）；④调整参数（heartbeat-interval、election-timeout）；⑤升级硬件或拆分 etcd 集群。

简短示例回答（90字）：首先用 etcdctl endpoint health 看各节点状态，再通过 PromQL 观察 avg(etcd_disk_wal_fsync_duration_seconds) 是否 >100ms。若磁盘达到瓶颈，使用独立 NVMe SSD 并调整 IO 调度器。同时检查节点间网络延迟，若超过 50ms 则需要调整 election-timeout 至 2000ms。

可能追问：etcd 的数据库大小超过 2GB 会产生什么问题？如何 compaction？

避坑提醒：不要只说“升级硬件”。面试官期望看到具体调优手段，例如调整 `--max-request-bytes` 或启用 v3 的自动压缩。同时避免先入为主认为是网络问题，要按数据驱动方式排查。

📌 面试问题 3

问题：如何设计跨可用区的 Pod 调度策略，以保证业务在 AZ 故障时仍能维持服务？

面试官考察点：对 Pod 调度策略（反亲和、拓扑分布约束）、PDB、以及优雅降级的理解。

回答框架：①使用 topologySpreadConstraints 实现 zone 级别均匀分布；②设置 PodAntiAffinity 避免同一应用集中；③为每个 Deployment 设置 PDB，minAvailable 设为 50% 或略低；④配合 Cluster Autoscaler 跨 zone 扩容；⑤使用 region 级别 Service Mesh 实现流量切换。

简短示例回答（85字）： Deployment 配置 topologySpreadConstraints: maxSkew=1, topologyKey=topology.kubernetes.io/zone，并设置 PDB minAvailable=2。同时使用 PodAntiAffinity 确保同类 Pod 不放在同一个 zone。配合 HPA 与 Cluster Autoscaler 在资源不足时跨 zone 扩容，保障单 AZ 故障时仍有一半以上副本可用。

可能追问：如果两个 AZ 同时故障，怎么保证数据不丢失？只读业务如何降级？

避坑提醒：不要只谈调度不谈状态。需要明确区分有状态与无状态应用。对于有状态应用，必须结合 StatefulSet + 跨 AZ 持久卷（如 Rook/Ceph 或云盘快照），并明确 RTO/RPO 指标。避免给出“全部自动修复”的不切实际承诺。

💡 面试官视角总结：本章三个问题覆盖了架构设计、故障排查、调度策略三个核心能力。高分回答的共同特征是：具体数字（节点数、延迟阈值、副本数） + 权衡说明（成本 vs 高可用） + 真实案例（遇到过什么坑）。建议备考时准备好 2～3 个自己亲历的高可用改造故事。