第3章 Kubernetes核心概念与集群架构：高频问题、回答框架、公司侧重点
本章聚焦K8s面试中最常出现的核心概念与集群架构问题。从组件职责到Pod生命周期，从控制面/数据面划分到高可用设计，帮你构建系统化的回答框架。文末附大厂考察侧重点速查。
📋 Kubernetes核心组件一览表（含公司侧重）
| 组件名称 | 所属层次 | 核心职责 | 面试关注点 / 公司侧重 |
|---|---|---|---|
| API Server | 控制面 | 集群统一入口，REST API 鉴权与代理 | 阿里 高并发鉴权 QPS 优化 |
| Scheduler | 控制面 | Pod 调度决策，资源匹配与亲和性 | 字节 大规模调度效率与抢占策略 |
| Controller Manager | 控制面 | 状态控制器，维护声明式期望状态 | 腾讯 控制器模式与自定义 CRD |
| etcd | 控制面 | 集群元数据与状态持久化存储 | 腾讯 稳定性、备份恢复与性能 |
| Kubelet | 数据面 | Pod 生命周期管理，健康检查与容器运行时 | 美团 健康检查与故障自愈 |
| Kube-proxy | 数据面 | 网络代理，Service 负载均衡与转发 | 通用 iptables / IPVS 模式选择 |
💡 复习提示： 面试时先分层（控制面 vs 数据面）再逐一展开，体现系统思维。大厂侧重各有不同，准备时针对目标公司强化对应模块。
🎯 面试问题
请简述Kubernetes的核心组件及其主要作用。
📌 面试官考察点
- 是否清晰区分控制面与数据面
- 每个组件的核心职责是否准确
- 能否体现声明式API的设计理念
📝 回答框架
- 分层总述：先分为控制面（管理集群）与数据面（运行负载）
- 控制面逐一说明：API Server → Scheduler → Controller Manager → etcd
- 数据面逐一说明：Kubelet → Kube-proxy → 容器运行时
- 点睛总结：各组件通过声明式API协同，控制器模式维持期望状态
💡 示例回答
K8s核心组件分控制面与数据面。控制面包括API Server（集群入口与鉴权）、Scheduler（调度Pod）、Controller Manager（状态控制器）、etcd（数据存储）；数据面包括Kubelet（管理Pod）、Kube-proxy（网络代理）。各组件通过声明式API协同工作。
❓ 可能追问
- API Server的鉴权机制有哪些？（RBAC / ABAC / Webhook）
- Scheduler的调度流程是怎样的？
- etcd的稳定性如何保障？
⚠️ 避坑提醒
不要遗漏etcd（很多人只提API Server和Scheduler）；不要混淆Kubelet与容器运行时（Kubelet是agent，运行时是containerd等）；控制面组件不要只说名字，要带一句职责。
🎯 面试问题
描述Pod在Kubernetes集群中的生命周期与状态转换。
📌 面试官考察点
- 是否完整掌握Pod的5种状态
- 能否解释状态转换的触发条件
- 是否理解RestartPolicy的影响
📝 回答框架
- 状态列举：Pending → Running → Succeeded / Failed → Unknown
- 转换说明：调度成功进入Running，容器退出根据exit code决定Succeeded/Failed
- 关键机制：RestartPolicy（Always / OnFailure / Never）影响重试行为
- 实践价值：CrashLoopBackOff是常见故障，通过kubectl describe排查
💡 示例回答
Pod状态包括Pending（等待调度）、Running（容器运行）、Succeeded（正常退出）、Failed（异常退出）、Unknown（通信异常）。状态转换由调度结果和容器退出码决定。RestartPolicy控制重启行为，连续失败会进入CrashLoopBackOff。掌握状态链是Pod排障的基础。
❓ 可能追问
- CrashLoopBackOff的触发条件是什么？如何排查？
- Init容器对Pod生命周期有什么影响？
- 如何查看Pod的详细事件？
⚠️ 避坑提醒
不要只说出3-4个状态，Unknown常被遗漏；不要混淆Pod状态与容器状态；回答时带上排障命令（
kubectl describe pod / kubectl logs）体现工程能力。
🎯 面试问题
谈谈你对Kubernetes集群架构中控制面与数据面的理解，以及如何实现高可用。
📌 面试官考察点
- 是否准确划分控制面与数据面边界
- 高可用设计的核心手段是否清晰
- 能否结合生产环境实际方案
📝 回答框架
- 分层定义：控制面负责集群治理，数据面负责负载运行
- 控制面高可用：多副本 + 负载均衡（SLB前置API Server），etcd集群（3/5节点）
- 数据面高可用：Node多副本 + Pod反亲和 + HPA自动扩缩
- 总结：分层隔离故障，控制面是核心，etcd是集群的"心脏"
💡 示例回答
控制面由API Server、Scheduler、Controller Manager、etcd组成，负责集群调度与状态管理；数据面由Kubelet、Kube-proxy及容器运行时组成，负责负载运行。高可用通过API Server多副本+SLB、etcd 3节点集群、Controller Manager leader选举实现，确保控制面不中断。
❓ 可能追问
- etcd集群的节点数为什么推荐奇数？
- 如何在不中断服务的情况下升级控制面？
- 大规模集群中API Server的性能瓶颈如何优化？
⚠️ 避坑提醒
不要只谈控制面高可用而忽略数据面；etcd的奇数节点原因要清楚（选举与容错）；避免只说理论，最好带一句"生产环境中我们使用SLB+3节点etcd+leader选举"。
🏢 大厂侧重点速查
- 腾讯云： 侧重etcd稳定性、大规模集群架构、TKE定制化
- 阿里云： 侧重调度性能、资源利用率、混部技术、ACR镜像加速
- 字节跳动： 侧重高可用、多集群管理、容器化迁移效率
- 美团： 侧重稳定性、监控告警体系、成本优化与Kubelet健康检查