2. K8s核心组件与API交互：API Server、etcd、Controller Manager、Scheduler的调用链路
在Kubernetes集群中，所有组件的协作都围绕API Server（kube-apiserver）展开。理解API Server、etcd、Controller Manager与Scheduler之间的调用链路，是掌握API事务边界治理的前提。本章将拆解这四大组件的交互模式、数据流向与关键调用点。
2.1 核心组件角色与职责
下表概括了四个核心组件在API交互中的定位：
| 组件 | 核心职责 | API交互角色 | 状态存储 |
|---|---|---|---|
| API Server | RESTful API网关、认证授权、准入控制、资源验证 | 唯一与etcd直接交互的组件 | 无状态，依赖etcd |
| etcd | 分布式键值存储，保存集群全部资源对象 | 仅接受API Server的读写请求 | 持久化存储 |
| Controller Manager | 运行各类控制器（Deployment、Node、Namespace等） | 通过API Server watch资源，回写状态 | 无状态，通过API Server读写 |
| Scheduler | 为未调度的Pod选择合适节点 | 通过API Server读取Pod/Node，绑定结果 | 无状态，通过API Server写入 |
关键原则：API Server是集群中唯一允许直接访问etcd的组件。Controller Manager和Scheduler必须通过API Server的REST接口或watch机制间接操作数据，这一约束保证了事务边界的一致性。
2.2 组件间调用链路全景
下图展示了从用户请求到组件协作的完整调用链路：
2.3 核心交互流程详解
2.3.1 API Server ↔ etcd：事务性读写
API Server是etcd的唯一客户端。所有资源对象的创建、更新、删除操作都通过API Server转化为etcd事务（txn）。关键流程如下：
- 请求到达：用户或组件通过REST请求（POST/PUT/DELETE）访问API Server。
- 准入控制：API Server执行认证、授权、MutatingAdmissionWebhook、ValidatingAdmissionWebhook。
- 对象验证：校验资源对象的Schema、字段合法性、默认值注入。
- etcd事务写入：API Server将资源对象序列化为JSON/Protobuf，通过etcd v3 API的Txn方法原子写入。
- 响应返回：etcd提交成功后，API Server构造REST响应返回给调用方。
事务边界要点：API Server对etcd的每次写入都使用乐观锁（resourceVersion机制）。如果并发写入导致版本冲突，API Server会返回409 Conflict，由客户端重试。这一机制保证了API事务的原子性与一致性。
2.3.2 Controller Manager ↔ API Server：List-Watch模式
Controller Manager内部运行数十个控制器，每个控制器都通过List-Watch模式与API Server交互：
- List：控制器启动时全量拉取关心的资源（如Deployment、ReplicaSet、Pod）。
- Watch：建立长连接，持续监听资源变更事件（ADDED/MODIFIED/DELETED）。
- Reconcile：收到事件后，控制器将当前状态与期望状态对比，通过API Server执行创建、更新、删除操作。
典型调用链路示例（Deployment控制器）：
1. Deployment Controller watch /apis/apps/v1/deployments
2. 收到 Deployment 创建事件（ADDED）
3. 计算期望 ReplicaSet 数量
4. POST /apis/apps/v1/namespaces/{ns}/replicasets → 创建 ReplicaSet
5. ReplicaSet Controller watch 到新 ReplicaSet
6. 计算期望 Pod 数量
7. POST /api/v1/namespaces/{ns}/pods → 创建 Pod2.3.3 Scheduler ↔ API Server：调度与绑定
Scheduler的调用链路分为两个阶段：
| 阶段 | API调用 | 说明 |
|---|---|---|
| 监听未调度Pod | watch /api/v1/pods?fieldSelector=spec.nodeName=="" | 持续监听nodeName为空的Pod |
| 读取节点信息 | list /api/v1/nodes | 获取所有节点状态、资源容量、标签 |
| 绑定Pod到节点 | POST /api/v1/namespaces/{ns}/pods/{name}/binding | 创建Binding对象，API Server更新Pod的nodeName |
| 更新调度记录 | PUT /api/v1/namespaces/{ns}/events | 记录调度成功/失败事件 |
事务边界风险：Scheduler在读取节点信息与写入binding之间存在时间窗口。如果节点资源在调度决策后被其他Pod占用，可能导致资源超分。Kubernetes通过调度队列的乐观锁与调度框架的插件机制（Reserve/PreBind）来缓解这一问题，但无法完全消除。
2.4 组件间调用链路的时序关系
以下SVG图展示了一个Pod从创建到运行的完整时序交互：
2.5 事务边界治理的关键观察点
基于上述调用链路分析，API事务边界治理需要重点关注以下环节：
- API Server的幂等性：同一请求重放不应产生副作用，依赖resourceVersion与etcd的原子比较交换（CAS）。
- watch事件的有序性：Controller Manager和Scheduler依赖watch事件的顺序一致性，etcd的MVCC机制保证了这一点。
- 乐观锁冲突处理：当多个控制器并发更新同一资源时，API Server返回409 Conflict，客户端必须实现重试逻辑。
- 最终一致性窗口：从API Server写入etcd到watch事件推送到控制器之间存在短暂延迟，设计上应容忍最终一致性。
实践建议：在构建自定义控制器或Operator时，务必遵循List-Watch模式，使用resourceVersion进行增量同步，并在更新操作中处理409冲突。避免直接访问etcd，所有数据交互必须通过API Server。