Kubernetes核心概念与架构面试

本章聚焦 Kubernetes 核心组件 的高频面试题：API Server、Scheduler、Controller Manager、etcd、Kubelet、Kube Proxy。面试官不仅考察组件功能，更关注你对数据流、调度逻辑、高可用设计的理解。以下回答框架与真题卡片助你快速建立结构化的表达。

面试问题：请简述 Kubernetes 核心组件的功能，并说明创建 Pod 的完整流程。

• 面试官考察点：是否清楚每个组件的最小职责、API 交互顺序、以及数据流动方向。
• 回答框架：按时间顺序拆解：用户通过 kubectl → API Server → etcd 存储 → Scheduler 绑定 → Kubelet 创建 → Controller 确保副本。每步只提核心角色，避免过度展开。
• 示例回答：“用户提交 Pod YAML 到 API Server，API Server 写入 etcd 并返回。Scheduler 通过 predicates 选 Node，binding 写回 etcd。Kubelet 监听到 Pod 调度到本机，调用容器运行时启动容器。Controller Manager 监视副本数，确保期望状态。” (75字)
• 可能追问：
  • 如果 Scheduler 挂掉，Pod 还能调度吗？
  • API Server 如何保证幂等性？
  • etcd 出现脑裂会怎样？
• 避坑提醒：不要只说“Scheduler 选择节点”，要提 predicates（过滤）与 priorities（打分）两阶段；不要遗漏 etcd 作为唯一持久层。

面试问题：Kubernetes Scheduler 的调度原理是什么？调度器是怎么做打分和过滤的？

• 面试官考察点：是否理解调度框架的扩展性；能否区分过滤/打分阶段；是否了解自定义调度器的实现思路。
• 回答框架：先给出调度流程图：Predicates → Priorities → 最优 Node → Binding。分别举例常见过滤规则（如 NodeSelector、PortConflict）和打分规则（如资源利用率）。最后提 Scheduling Framework 插件化设计。
• 示例回答：“调度器首先通过 predicates 过滤掉不满足条件的 Node，例如端口冲突、资源不足；然后通过 priorities 对剩余 Node 打分，均衡 CPU/内存。最后选择最高分 Node 进行 binding。Kubernetes 1.19+ 支持通过 Scheduling Framework 自定义扩展。” (80字)
• 可能追问：
  • 如何实现 Pod 间的亲和性调度？
  • 调度器怎么处理抢占？
  • 如果所有 Node 都不满足，会怎么处理？
• 避坑提醒：不要忽略“Even Pod Spreading”和“Taints/Tolerations”在过滤阶段的作用；提到“优先级”时需区分 Pod 优先级与 Node 分值偏好。

面试问题：Kubernetes 的 API 设计采用了什么风格？为什么选择这种风格？

• 面试官考察点：对声明式 API 的理解；与命令式 API 的对比；以及对 RESTful、Watch、Admission Webhook 的认知。
• 回答框架：先点出核心：声明式（Declarative）API + RESTful 资源模型。对比命令式（如 docker run）劣势：分布式环境下状态维护困难。说明 Kubernetes 通过 etcd 存储、Controller 循环不断调和（Reconcile）实现最终一致性。最后提 API 版本化（alpha/beta/stable）和 CRD 扩展机制。
• 示例回答：“Kubernetes 采用声明式 RESTful API，用户提交期望状态，系统持续调和至一致。这种设计天然适用于分布式系统：解决了一致性问题，支持控制器模式；同时通过 Admission Webhook 实现策略注入，通过 CRD 实现能力扩展。” (85字)
• 可能追问：
  • 声明式 API 带来的副作用有哪些？
  • 如何设计一个安全的 Admission Webhook？
  • 为什么 API Server 要使用 TLS 双向认证？
• 避坑提醒：不要只答“RESTful”，必须强调“声明式”是灵魂；不要忽略 Watch 机制（长轮询）在控制器中的作用。避免说“Kubernetes 是全自动的”，需提用户仍需写 YAML 声明。