2. K8s 核心架构回顾：API Server、etcd、Scheduler、kubelet、Controller Manager 的角色与性能影响
在深入准入控制与 Pod 密度优化之前，必须重新审视 Kubernetes 控制平面的五大核心组件。每个组件既是功能节点，也是性能瓶颈的潜在来源。理解它们的角色与资源消耗模式，是后续调优的基石。
2.1 控制平面组件全景
下图展示了 Kubernetes 控制平面与工作节点之间的核心交互路径。箭头方向代表请求流向与数据依赖关系。
2.2 各组件角色与性能影响分析
| 组件 | 核心职责 | 性能敏感点 | 典型瓶颈指标 |
|---|---|---|---|
| API Server | 所有 REST 请求的入口；认证、授权、准入控制、验证与持久化 | 请求吞吐量、序列化/反序列化开销、watch 连接数、TLS 握手 | QPS、P99 延迟、goroutine 数、内存占用 |
| etcd | 集群状态的一致性与持久化存储；支持 watch 机制 | 磁盘 I/O（WAL 与快照）、网络延迟、key 数量与大小、租约数量 | fsync 延迟、DB 大小、请求速率、leader 选举频率 |
| Scheduler | 为未调度的 Pod 选择合适节点；执行预选、优选、绑定 | 集群规模（节点数）、调度队列深度、调度算法复杂度、extender/plugin 延迟 | 调度吞吐量（Pod/sec）、调度延迟、pending Pod 数量 |
| kubelet | 节点代理；管理 Pod 生命周期、容器运行时、资源统计 | Pod 密度、镜像拉取并发、PLEG（Pod Lifecycle Event Generator）轮询、cAdvisor 数据采集 | PLEG 延迟、Pod 启动时间、节点状态上报延迟 |
| Controller Manager | 运行各种控制器（Deployment、ReplicaSet、Node Controller 等） | 控制器循环频率、informer 缓存大小、workqueue 深度、leader 选举 | 控制器同步延迟、workqueue 积压、内存占用 |
2.3 关键性能路径详解
2.3.1 API Server：集群的流量中枢
API Server 是唯一与 etcd 直接交互的组件。每一次 Pod 创建、更新、删除请求都必须经过以下路径：
- 认证与授权：TLS 握手、TokenReview、SubjectAccessReview。
- 准入控制：MutatingAdmissionWebhook → 对象验证 → ValidatingAdmissionWebhook。
- 对象验证与持久化：序列化为 protobuf/JSON → 写入 etcd。
- 通知分发：通过 watch 机制将变更推送给所有监听者（Scheduler、kubelet、Controller Manager）。
2.3.2 etcd：一致性的代价
etcd 使用 Raft 共识算法保证强一致性。每一次写入都需要多数节点（quorum）确认：
- 磁盘 I/O 敏感：WAL（Write-Ahead Log）的 fsync 延迟直接决定写入延迟。建议使用 SSD/NVMe 并独立挂载。
- key 数量限制：etcd 默认的 key 数量上限为 2GB 或 100 万个 key。大量 Secret、ConfigMap 或 Event 会膨胀 DB 大小。
- watch 风暴：当大量客户端同时 watch 同一前缀（如 /registry/pods），etcd 需要为每个 watch 维护事件队列，容易导致内存飙升。
--quota-backend-bytes=8589934592（8GB）；定期清理过期 Event（kubectl delete events --all）。
2.3.3 Scheduler：调度效率决定集群利用率
Scheduler 通过 informer 监听未调度的 Pod（spec.nodeName == ""），执行两阶段调度：
- 预选（Filter）：过滤掉不满足 Pod 资源请求、污点容忍、节点选择器等条件的节点。
- 优选（Score）：对剩余节点打分，选择最优节点。
在 1000 节点集群中，每次调度需要遍历所有节点，预选阶段的资源计算复杂度为 O(n)。当 Pod 密度高时，调度队列的排序与重试机制也会消耗大量 CPU。
2.3.4 kubelet：节点级的 Pod 密度天花板
kubelet 是每个节点上最核心的代理。其性能直接影响单节点能运行的最大 Pod 数量：
- PLEG 轮询：kubelet 定期调用容器运行时（如 containerd）查询 Pod 状态。默认轮询间隔为 1 秒，当 Pod 数量超过 100 时，PLEG 延迟会显著增加。
- cAdvisor 采集：内嵌的 cAdvisor 采集每个容器的 CPU/内存/网络指标。Pod 密度越高，采集周期越长，可能影响节点状态上报。
- 镜像拉取：并发拉取镜像时，kubelet 的串行化处理可能导致 Pod 启动延迟。
kubelet_pleg_relist_duration_seconds 和 kubelet_pod_start_duration_seconds。如果 PLEG 延迟持续超过 5 秒，说明 Pod 密度已接近节点极限。
2.3.5 Controller Manager：控制循环的稳定性
Controller Manager 内部运行数十个控制器，每个控制器通过 informer 监听资源变化并驱动实际状态向期望状态收敛：
- Deployment Controller：创建/更新 ReplicaSet，管理滚动更新。
- Node Controller：监控节点心跳，标记 NotReady 节点并驱逐 Pod。
- EndpointSlice Controller：维护 Service 的后端端点列表。
当集群规模大或资源变更频繁时，控制器的 workqueue 可能积压，导致同步延迟。例如，Node Controller 的 --node-monitor-period 默认 5 秒，在 1000 节点集群中，每 5 秒需要处理 1000 次节点状态更新。
2.4 组件间依赖与性能耦合
从耦合图中可以清晰看到：API Server 是唯一的中心枢纽。etcd 的写入延迟会直接放大 API Server 的响应时间，进而影响 Scheduler 的绑定速度、Controller Manager 的同步周期以及 kubelet 的状态更新。因此，性能调优的首要目标是降低 API Server 与 etcd 的延迟。
2.5 性能调优的起点：组件级指标采集
在开始任何调优之前，必须建立基线指标。以下是最关键的 Prometheus 指标：
| 组件 | 关键指标 | 告警阈值建议 |
|---|---|---|
| API Server | apiserver_request_duration_seconds |
P99 > 5s |
| etcd | etcd_disk_wal_fsync_duration_seconds |
P99 > 10ms |
| Scheduler | scheduler_e2e_scheduling_duration_seconds |
P99 > 10s |
| kubelet | kubelet_pleg_relist_duration_seconds |
P99 > 5s |
| Controller Manager | workqueue_depth |
持续 > 100 |
kubectl top 和 Prometheus + Grafana 搭建控制平面监控面板。重点关注 API Server 的 etcd.db.total_size 和 kubelet 的 kubelet_running_pods，这两个指标直接反映集群的 Pod 密度压力。