第2章 受理与登记：声明进入控制平面

第2章 受理与登记：声明进入控制平面

章节摘要：本章跟着一条线走——orders-api 的声明离开你的终端之后、抵达工作节点之前，在控制平面里经历的那段"看不见的旅程"。kubectl 提交的对象先过 API Server 的认证、授权、准入三道关卡，被修订成合法形态后写入 etcd 账本；调度器与控制器再通过 Watch 机制收到广播，各自认领任务。

一条主线

上一章结束时，orders-api 的声明还只是一个文本文件。当你在终端敲下 kubectl apply，这份声明开始了旅程中最凶险的一段：它要穿过一整套安检与登记体系。凶险在哪？在于集群里流转的任何数据都必须先变成"资源对象"——API Server 只受理结构化的资源，etcd 只存储通过校验的资源，其余组件只消费 Watch 推送的资源变更。三道关卡、一本账、一套广播，构成了控制平面的全部戏份。

理解这条线的直接收益是排障提速：apply 报 403，是关卡二的授权问题；apply 成功但 Pod 迟迟不出现，多半是账本之后没人接单（调度或控制器异常）。本章把这条线走通，后续遇到任何"声明不动了"，都能定位到具体环节。

先看声明的受理全景，四类组件各守一段：

图 2-1：控制平面四组件分工与声明流经路径

沿途站点

本章三节，对应声明的三段路程：

• 2.1 API Server：一切声明的唯一受理窗口：认识资源模型（apiVersion 与 kind 的来历）、REST 式访问、以及"组件间不直连、一切经它中转"的星型拓扑。这一节回答"集群的门在哪、门里什么样"。
• 2.2 kubectl apply 的安检流水线：认证（你是谁）、授权（你能干什么）、准入（提交的内容要不要改）三道关卡逐个过，重点是 RBAC 的 Role 与 RoleBinding 写法，以及 403 报错的读法。
• 2.3 etcd 与 Watch：声明的账本与广播站：声明落账后如何被其余组件知晓——resourceVersion 版本号、Watch 长连接、控制器端的 Informer 缓存，这是理解"自愈为什么能发生"的钥匙。

三节是严格的接力关系：没有 2.1 的资源模型，2.2 的报错读不懂；没有 2.3 的 Watch 机制，第4章的调和循环就成了无源之水。

拐点与结论

本章的认知拐点在 2.3：etcd 是集群唯一的记忆，Watch 是集群的神经系统。想通这一点，"组件之间怎么协同"的疑问就全部消解——它们不直接通信，全都盯着同一本账的变更流。第4章讲控制器每隔秒级对账一次、第3章讲调度器监听未绑定的 Pod，机制上都是在 Watch 这条神经上做文章。

结论一句话：apply 返回 created，只代表声明过了安检、入了账；声明变成运行中的容器，是账本之后一串组件接力的结果，接力过程从第3章开始展开。

读完你应该

• 说出 API Server 的三个职责与"星型拓扑"中其余组件为何不直连；
• 解释 apiVersion 中组与版本的来历，并用命令列出集群支持的资源类型；
• 写出授权一个命名空间内只读角色的 Role 与 RoleBinding，并读懂 403 报错；
• 描述认证、授权、准入三道关卡的先后顺序与各自的决定权；
• 说明 resourceVersion 与 Watch 的关系，解释控制器如何做到秒级感知变更。

下一章的接力

声明已经入账、广播已经发出。第3章切到工作节点一侧：调度器如何为每个 Pod 挑选节点、kubelet 如何把容器真正拉起来，以及容器跑起来之后，探针如何接管"健康裁判"的职务。