二、集群架构与核心组件

本章把基础篇的对象模型放回真实进程：谁保存目标，谁作决策，谁在节点上执行，谁把结果写回来。

控制平面不是一个按顺序调用所有组件的总调度脚本。组件通过 API（Application Programming Interface，应用程序编程接口）对象和观察机制合作，故障会在不同位置表现为不同的“未推进”。

1、四个观察视角

专题	图号	要解决的问题
控制平面组件	K2-1	API Server、etcd、scheduler、controller-manager 及扩展服务怎样分工
节点组件与附加组件	K2-2	kubelet、运行时、网络、存储、代理和名称解析处于什么位置
API 请求与准入	K2-3	提交配置到保存对象之间，哪些环节可以拒绝请求
控制平面协作	K2-4	Deployment 如何变成节点上的容器，怎样逐层采集证据

先判断请求是否被接受，再判断下层对象是否产生，然后确认调度，最后核对节点执行与应用健康。控制平面、节点和应用各有观测入口，不用一个 Running 覆盖全部结论。

基础篇的 API 对象与调谐循环是先修内容。实验继续复用 handbook-web，执行环境和证据级别见 README。

读完后，应能不看图说明一次 Deployment 创建涉及的组件，指出至少三个可能失败的位置，并给出分别用于区分它们的对象字段或命令。

对数据库工程师，还应能解释：API Server 暂时故障时，已有数据库进程可能继续运行，但集群为什么不能因此被判定为“仍然具备完整恢复能力”。