API Server — Secretary

类比：它就像公司里的 秘书。

• 职责：所有请求（kubectl 命令、控制器、外部系统）都必须先交给秘书。秘书会检查请求是否合法，然后把它交给合适的部门（比如 etcd 或 Controller Manager）。
• 作用：它是整个 Kubernetes 的 通信中枢，没有它，其他组件之间无法交流。

📌 API Server 与 etcd 的关系

• API Server：接收用户或控制器的请求，比如“我要创建一个 Pod”。
• 它会先验证请求是否合法，然后把这个“文件”交给 etcd 存档。
• etcd：保存所有集群的状态数据（比如 Pod 的定义、节点信息、配置）。

类比： 秘书（API Server）收到一份申请表 → 检查没问题 → 把表交给档案管理员（etcd） → 档案管理员把它放进档案库。

为什么不是反过来？

• etcd 本身只是存储，不会主动发起操作。
• 它就像一个“被动的档案室”，只有秘书（API Server）来存取文件时才会动作。
• 所以，API Server 是主动方，etcd 是被动方。

💡 小结：

• API Server 是 沟通中枢，负责接收和分发请求。
• etcd 是 状态存储，负责保存所有数据。
• 它们的关系是：API Server 主动把数据交给 etcd 保存。

API Server 的通信方式

• Controller Manager（项目经理） 并不会直接去找工厂主管（Kubelet）。
• 它会通过 API Server（秘书） 下达指令。
• API Server 接收到指令后，会用 内部 gRPC 通信 把任务转交给 Kubelet（工厂主管）。
• Kubelet 再去安排工人（Pod）执行任务。

📌 类比总结：

• 项目经理（Controller Manager）发现问题 → 写一份任务单。
• 秘书（API Server）接收任务单 → 转交给工厂主管（Kubelet）。
• 工厂主管（Kubelet）安排工人（Pod）去完成任务。

这样，所有的沟通都必须经过秘书（API Server），保证流程统一、权限控制和安全。

💡 小结：

• API Server 是唯一的入口，所有组件都通过它沟通。
• Controller Manager 依赖 API Server 来下达任务。
• Kubelet 通过 API Server 接收指令，然后执行。

📌 如果 API Server 出现故障

• 沟通中断： 所有组件之间的交流都会停滞。Controller Manager、Scheduler、kubectl 等都无法再与集群交互。 类比：秘书突然消失，公司内部的部门就无法传递信息。
• 执行不受影响： 已经在工位上的工人（Pods）会继续工作，因为他们的任务已经安排好了。 类比：工厂里的工人即使没有新的指令，也会继续完成手头的工作。
• 影响范围：
  • 新的任务无法下达（比如新建 Pod）。
  • 集群状态无法更新（比如伸缩、调度）。
  • 但现有 Pod 不会立刻停止。

💡 总结类比：

秘书（API Server）突然不在 → 项目经理（Controller Manager）和人事经理（Scheduler）无法沟通 → 档案室（etcd）没人更新 → 工厂主管（Kubelet）收不到新任务 → 工人（Pods）继续干现有活，但没有新安排。

🔗 API Server 与 Scheduler 的交互

• Scheduler（HR Manager） 的工作是给新 Pod 找合适的节点。
• 当用户或控制器请求创建 Pod 时：
  1. API Server（秘书） 接收请求，并把 Pod 的定义存到 etcd（档案室）。
  2. Scheduler（人事经理） 会通过 API Server 读取这些未分配的 Pod 信息。
  3. Scheduler 决定 Pod 应该运行在哪个节点，并把调度结果再写回 API Server。
  4. API Server 再把这个结果传递给 Kubelet（工厂主管），由它去实际启动 Pod。

📌 类比总结：

• 秘书（API Server）收到一份“招聘申请”（Pod 创建请求）。
• 档案室（etcd）保存这份申请。
• 人事经理（Scheduler）通过秘书查阅申请，决定工人应该在哪个工厂上班。
• 秘书把人事经理的决定传达给工厂主管（Kubelet）。
• 工厂主管安排工人（Pod）开始工作。

💡 小结：

API Server 是 沟通枢纽，不仅和 Controller Manager 交互，还必须和 Scheduler 交互，才能完成 Pod 的调度和运行

🧩 API Server 的核心特性

• 唯一入口：所有请求（kubectl、Controller Manager、Scheduler、外部系统）都必须通过 API Server。
• 权限检查：它会先验证请求是否合法，包括 认证（Authentication） 和 授权（Authorization）。 👉 类比：秘书不会随便接收任何人的指令，她会先确认你是不是公司员工、有没有权限。
• 数据校验：API Server 会检查请求的内容是否符合 Kubernetes 的资源定义（比如 Pod 的 YAML 格式是否正确）。
• 统一通信：即使是内部组件（如 Scheduler、Controller Manager），也必须通过 API Server 来读写集群状态。

📌 类比补充

秘书（API Server）并不是“听谁都行”，而是：

1. 先看证件（认证）
2. 再看权限（授权）
3. 最后检查文件格式（数据校验） 只有通过这三关，秘书才会把请求交给档案室（etcd）或转发给其他部门。

💡 总结： API Server 是 守门人，它不仅是沟通枢纽，还负责安全和规范。没有它，集群就会变成“谁都能下命令”的混乱状态。

📌 快速回顾要点

• 角色类比：秘书，所有请求必须经过她。
• 核心职责：唯一入口、认证授权、数据校验、转发到 etcd 或其他组件。
• 交互关系：
  • 与 etcd（档案管理员）：保存和读取状态。
  • 与 Controller Manager（项目经理）：下达任务。
  • 与 Scheduler（人事经理）：调度 Pod。
  • 与 Kubelet（工厂主管）：通过 gRPC 下达执行指令。
• 故障影响：沟通中断，但现有 Pod 不受影响。

API Server 的关键点补充

• Admission Control： 在认证和授权之后，API Server 还会调用 Admission Controller 来进一步检查或修改请求。 👉 类比：秘书不仅检查证件和权限，还可能要求你补充材料或修改申请。
• Aggregation Layer： API Server 可以扩展，允许其他服务注册新的 API。 👉 类比：秘书可以帮公司开设“外部窗口”，让合作方也能通过她来提交请求。
• Watch 机制： API Server 提供 watch 功能，允许组件订阅资源变化。 👉 类比：秘书不仅能提供档案，还能在档案更新时主动通知相关部门。
• 高可用性： 在生产环境中，通常会部署多个 API Server 实例，前面加负载均衡器。 👉 类比：公司可能有多个秘书台，保证不会因为一个秘书缺席而瘫痪。

📌 小结

API Server 的完整职责不仅是 入口 + 安全检查 + 转发，还包括：

• Admission Control（进一步检查/修改请求）
• Aggregation Layer（扩展 API）
• Watch 机制（通知变化）
• 高可用性（多副本部署）