2. Kubernetes 控制平面组件概述：API Server、etcd、Scheduler、Controller Manager 的角色与网络交互模式
Kubernetes 控制平面是集群的“大脑”，负责全局决策与状态管理。其核心组件包括 API Server、etcd、Scheduler 和 Controller Manager。理解每个组件的职责及其网络交互模式，是进行网络拓扑数据采集与调度决策优化的基础。
2.1 组件角色与核心职责
| 组件 | 核心角色 | 关键职责 |
|---|---|---|
| API Server | 控制平面网关 | 提供 RESTful API，处理所有集群操作请求；认证、授权、准入控制；是唯一与 etcd 交互的组件。 |
| etcd | 分布式键值存储 | 存储所有集群状态（Pod、Service、ConfigMap 等）；保证强一致性与高可用；是集群的“唯一真相源”。 |
| Scheduler | 调度决策者 | 监听未调度的 Pod，根据资源需求、约束、亲和性等策略，将 Pod 绑定到最优 Node。 |
| Controller Manager | 状态调节器 | 运行多个控制器（如 Node Controller、Replication Controller），持续调节实际状态至期望状态。 |
关键洞察： API Server 是控制平面的“中心枢纽”，所有组件（包括 kubelet、kube-proxy）都通过 API Server 进行通信，从不直接访问 etcd。这种设计隔离了存储层，提升了安全性与可扩展性。
2.2 网络交互模式详解
控制平面组件的网络交互遵循“API Server 为中心”的星型拓扑。所有外部请求、组件间通信、状态变更通知均通过 API Server 转发或代理。
2.2.1 API Server 与 etcd 交互
- 协议： gRPC（HTTP/2），默认端口 2379。
- 模式： API Server 是 etcd 的唯一客户端。所有读写操作（Create/Get/Update/Delete/Watch）均由 API Server 发起。
- 网络特性： 使用 TLS 双向认证；Watch 机制通过长连接实现实时状态推送，减少轮询开销。
2.2.2 Scheduler 与 API Server 交互
- 协议： HTTP/HTTPS，通过 API Server 的 REST API。
- 模式： Scheduler 通过 Watch 机制监听
Pod资源（特别是spec.nodeName为空的 Pod）。决策后通过 Bind 请求将 Pod 绑定到目标 Node。 - 网络特性： 依赖 API Server 的事件通知机制，减少无效轮询；调度周期受网络延迟影响。
2.2.3 Controller Manager 与 API Server 交互
- 协议： HTTP/HTTPS，通过 API Server 的 REST API。
- 模式： 每个控制器（如 Deployment Controller、Node Controller）独立 Watch 相关资源。当状态偏离期望时，控制器通过 API Server 创建、更新或删除资源。
- 网络特性： 控制器循环（Informer 机制）基于本地缓存 + Watch 事件驱动，减少对 API Server 的重复查询。
网络拓扑数据采集要点： 在采集控制平面网络拓扑时，应重点关注 API Server 的 连接数、请求延迟、Watch 事件吞吐量 以及 etcd 的 磁盘 I/O 和 网络延迟。这些指标直接影响调度决策的时效性。
2.3 控制平面网络交互拓扑图
下图展示了控制平面组件之间的核心网络交互路径。箭头方向表示请求发起方向，实线代表同步请求，虚线代表 Watch 长连接。
2.4 组件间通信的协议与端口清单
| 通信对 | 协议 | 默认端口 | 认证方式 | 关键特征 |
|---|---|---|---|---|
| API Server → etcd | gRPC (HTTP/2) | 2379 | TLS 双向证书 | 强一致性读写；Watch 长连接 |
| Scheduler → API Server | HTTPS | 6443 | 客户端证书 / | Watch Pod；Bind 请求 |
| Controller Manager → API Server | HTTPS | 6443 | 客户端证书 / | 多控制器独立 Watch |
| kubectl → API Server | HTTPS | 6443 | 证书 / / OIDC | 用户交互入口 |
| kubelet → API Server | HTTPS | 6443 | 客户端证书 | 上报 Node 状态；获取 Pod 清单 |
网络优化提示： 在大型集群中，API Server 与 etcd 之间的网络延迟是调度延迟的主要瓶颈之一。建议将 etcd 部署在低延迟网络（如同一可用区），并启用 etcd 的
--auto-compaction-retention 参数控制历史版本数量，避免 Watch 事件积压。
2.5 网络交互模式对调度决策的影响
调度决策的时效性高度依赖控制平面网络的稳定性与低延迟。以下是关键影响路径：
- Pod 创建事件传播： 用户创建 Pod → API Server 写入 etcd → etcd 返回成功 → API Server 通知 Scheduler（Watch 事件）。此路径延迟约 5-20ms（正常网络下）。
- 调度决策回写： Scheduler 选定 Node → 发送 Bind 请求到 API Server → API Server 写入 etcd → etcd 确认。此路径延迟直接影响 Pod 启动时间。
- 控制器调节： Controller Manager 检测到状态偏差（如 Pod 副本数不足）→ 通过 API Server 创建新 Pod。此过程同样依赖 Watch 事件的实时性。
数据采集指标建议： 在控制平面网络拓扑数据采集中，应重点采集以下指标：
• API Server 的 请求延迟 P99（特别是写请求）
• etcd 的 磁盘 fsync 延迟 和 网络往返时间
• Scheduler 的 调度周期 和 绑定延迟
• Watch 事件的 端到端延迟（从 etcd 变更到组件收到通知）
• API Server 的 请求延迟 P99（特别是写请求）
• etcd 的 磁盘 fsync 延迟 和 网络往返时间
• Scheduler 的 调度周期 和 绑定延迟
• Watch 事件的 端到端延迟（从 etcd 变更到组件收到通知）
2.6 高可用部署下的网络拓扑变化
在生产环境中，控制平面组件通常以多副本形式部署（如 3 个 API Server、3 个 etcd 节点）。此时网络拓扑变为：
- API Server 多副本： 前端通过负载均衡器（如 HAProxy、云负载均衡）分发请求；每个 API Server 实例均与所有 etcd 节点建立连接。
- etcd 集群： 节点间通过 Raft 协议通信（端口 2380），选举 Leader；API Server 只与 Leader 节点进行写操作，读操作可分散到 Follower。
- Scheduler / Controller Manager 多副本： 通过 Leader 选举机制（基于 Endpoint 或 Lease 资源）确保同一时刻只有一个活跃实例执行调度或调节操作，避免冲突。
这种拓扑增加了网络复杂度，但也提供了容错能力。在采集网络拓扑数据时，需要额外关注负载均衡器的健康检查、etcd 集群的成员变更以及 Leader 选举带来的瞬时延迟抖动。