高频面试问题与回答框架：常见问题、答题结构、公司侧重点
本节聚焦K8s交付面试中最常被问到的三类问题，并给出结构化回答框架。掌握“理解问题→拆解关键→技术方案→效果验证→总结升华”五步法，能帮你提升回答的条理性和说服力。不同公司（云原生厂商、互联网自研、传统企业转型）对同一问题的侧重点差异，也会在问答卡片中标注。
常见面试问题分类与公司侧重点
| 问题类别 | 典型问题举例 | 互联网公司侧重 | 云原生厂商侧重 | 传统企业侧重 |
|---|---|---|---|---|
| 集群架构 | K8s高可用方案、etcd选主原理 | 大规模集群扩展性 | 多集群管理、联邦 | 运维稳定性、灾备 |
| Pod调度 | 调度器原理、节点亲和性 | 资源利用率、调度延迟 | 调度策略自定义 | 资源隔离、合规性 |
| 网络与存储 | CNI选型、PV/PVC绑定时机 | 网络性能、容器网络模型 | 服务网格集成 | 存储对接外部系统 |
| 监控与日志 | Prometheus采集K8s指标 | 自定义监控、告警规则 | OpenTelemetry | 日志合规、长期存储 |
| CI/CD | GitOps与ArgoCD实践 | 快速迭代、灰度发布 | 多环境同步 | 审批流程、安全扫描 |
| 故障排查 | Pod启动失败、节点NotReady | 根源分析能力 | 工具链（Lens、k9s） | ITIL流程对接 |
🎯 问题1：请描述一下Kubernetes的调度原理和调度过程
面试官考察点
- 是否理解调度器的核心流程（预选→优选→绑定）
- 能否解释关键概念（节点亲和性、资源配额、污点容忍）
- 对默认调度器（default-scheduler）与自定义调度器的区分
回答框架
先一句话定调：K8s调度器通过“过滤”和“打分”两步，为Pod选择最佳节点。然后分三点展开：① 预选阶段（Predicates）：过滤不满足条件节点；② 优选阶段（Priorities）：对剩余节点打分；③ 绑定阶段（Bind）：将Pod与目标节点关联。最后结合一个实际例子说明调度策略的调整。
简短示例回答
“调度器通过预选过滤掉资源不足或污点不匹配的节点，然后优选阶段根据资源利用率、亲和性等策略打分，选择最高分节点绑定。比如一次压力测试中，我们通过设置Pod优先级和节点拓扑约束，将关键业务调度到独立GPU节点，调度耗时从平均3秒降到1.2秒。”
可能追问
- 调度器如何保证公平性？
- 如何自定义调度器？举例说明调度周期如何影响性能？
- 如果调度失败，Pod会一直Pending吗？
🎯 问题2：如何保证Kubernetes集群的高可用性？
面试官考察点
- 是否了解控制平面组件（etcd、kube-apiserver、kube-scheduler等）的高可用部署方式
- 能否区分Master节点与Worker节点高可用方案的不同
- 对etcd集群的故障域设计有无实操经验
回答框架
从控制平面和数据平面两个维度回答：① 控制平面：etcd集群奇数节点（3或5），节点跨可用区；apiserver前端加LB；scheduler/controller-manager使用leader选举。② 数据平面：工作节点通过DaemonSet + 多副本部署关键组件（如CoreDNS、Ingress Controller）；Pod通过PDB、HPA保障弹性。最后提一下自愈能力：节点故障后Pod自动迁移到其他节点。
简短示例回答
“我们生产环境使用3个Master节点跨AZ部署etcd集群，kube-apiserver通过SLB做接入层。Worker节点每个业务至少2个Pod，设置PDB保证最小可用实例数。曾遇到一个可用区宕机，etcd自动切换领导者，业务Pod在其他AZ重新调度，持续提供服务。”
可能追问
- etcd集群网络分区如何处理？
- 如何验证HA方案的有效性？常用的混沌工程工具？
- 3个Master vs 5个Master的选择依据？
🎯 问题3：你在工作中如何处理Pod被驱逐（Eviction）的问题？
面试官考察点
- 是否理解Pod驱逐的触发条件（节点资源不足、节点故障、kubelet主动驱逐）
- 能否结合QoS（Guaranteed/Burstable/BestEffort）解释驱逐优先级
- 是否有实际排查和预防的经验
回答框架
先说明驱逐的常见原因，然后按步骤排查：① 检查节点资源（kubectl describe node）看是否触发阈值；② 查看kubelet日志确认驱逐事件；③ 分析被驱逐Pod的QoS类别和资源请求/限制；④ 解决方案：调整资源配额、设置PDB、使用PriorityClass保护关键Pod。最后建议通过Prometheus采集节点资源使用率，提前告警。
简短示例回答
“有一次节点内存OOM触发kubelet驱逐，先用了kubectl get events –sort-by='.lastTimestamp'确认驱逐顺序，发现全是BestEffort的Pod。我们给核心业务Pod设置了Guaranteed QoS，并为非关键Pod配置低PriorityClass。同时增加节点内存Buffer到20%，再次模拟压力测试未再驱逐。”
可能追问
- kubelet的驱逐阈值如何计算？eviction-hard和eviction-soft的区别？
- 如果多个节点同时驱逐怎么办？是否有容错机制？
- 如何设计Pod的QoS策略来最小化驱逐影响？