2. K8s 架构核心回顾：控制平面组件、节点组件、Pod 生命周期、调度器工作原理
在深入准入控制与容量优化之前，必须重新校准对 Kubernetes 架构核心的理解。本章聚焦四个关键维度：控制平面组件的职责与通信、节点组件的负载特征、Pod 生命周期的状态转换，以及调度器的决策链路。这些是后续瓶颈分析的基础坐标系。
2.1 控制平面组件
控制平面是集群的“大脑”，负责全局决策与状态协调。以下表格列出核心组件及其关键职责：
| 组件 | 核心职责 | 关键端口/存储 | 瓶颈关注点 |
|---|---|---|---|
| kube-apiserver | 所有组件与 CLI 的唯一入口；认证、授权、准入控制、RESTful API 服务 | 6443 (HTTPS) | 请求并发量、etcd 响应延迟、准入插件链长度 |
| etcd | 集群状态持久化存储；键值存储，强一致性 | 2379 (客户端), 2380 (对等) | 磁盘 IOPS、网络延迟、快照与压缩频率 |
| kube-scheduler | 为新创建的 Pod 选择最优节点 | 10259 (安全端口) | 调度队列深度、预选/优选算法复杂度、节点资源余量 |
| kube-controller-manager | 运行各类控制器（Deployment、ReplicaSet、Node 等），维持期望状态 | 10257 (安全端口) | 控制器循环频率、Leader 选举开销、API Server 调用量 |
| cloud-controller-manager | 与云提供商 API 交互（负载均衡、存储卷、节点管理） | 10258 (安全端口) | 云 API 限频、网络延迟、节点状态同步 |
容量视角提示： 在大型集群（>500 节点）中，kube-apiserver 和 etcd 通常是控制平面最先出现性能拐点的组件。建议优先监控 apiserver 的请求延迟（特别是 LIST 请求）和 etcd 的 db 大小与 fsync 耗时。
2.2 节点组件
每个工作节点运行三个核心组件，它们直接决定了 Pod 的运行质量与资源利用率。
- kubelet：节点代理，负责管理 Pod 生命周期（创建、监控、重启）、上报节点状态、执行探针。关键指标：PLEG 重同步周期、Pod 启动延迟、镜像拉取时间。
- kube-proxy：维护节点上的网络规则（iptables/IPVS），实现 Service 的负载转发。关键指标：规则同步延迟、连接跟踪表大小。
- 容器运行时（containerd / CRI-O）：负责拉取镜像、启动/停止容器、管理容器文件系统。关键指标：镜像拉取带宽、容器启动时间、运行时 OOM 事件。
常见误区： 很多团队只监控节点 CPU/内存，却忽略了 kubelet 的 HTTP 请求超时 和 容器运行时镜像拉取并发限制。这两个因素在 Pod 大规模滚动更新时，会直接导致调度器误判节点可用资源。
2.3 Pod 生命周期
Pod 是 Kubernetes 中最小的调度单元。理解其状态转换是诊断调度与准入问题的前提。
性能优化关联： Pod 从 Pending 到 Running 的耗时是衡量集群“调度效率”的核心指标。如果大量 Pod 长时间停留在 Pending，应优先检查：调度器队列积压、节点资源碎片、镜像拉取带宽、存储卷挂载超时。
2.4 调度器工作原理
kube-scheduler 通过两阶段决策（Predicates + Priorities）为 Pod 选择最优节点。理解这一过程是进行容量规划与准入控制优化的关键。
2.4.1 调度流程
- 监听队列： 通过 Informer 机制监听 apiserver，获取未调度的 Pod（spec.nodeName 为空）。
- 预选阶段（Predicates）： 过滤掉不满足 Pod 要求的节点。常用过滤条件包括：资源不足（CPU/Memory）、端口冲突、污点容忍、节点选择器、存储卷拓扑约束。
- 优选阶段（Priorities）： 对通过预选的节点进行打分。常用打分策略包括：LeastRequestedPriority（资源余量最大）、BalancedResourceAllocation（CPU/内存均衡）、NodeAffinityPriority、TaintTolerationPriority。
- 绑定阶段（Bind）： 选择得分最高的节点，通过 apiserver 将 Pod 的 nodeName 写入 etcd。
2.4.2 调度器性能关键参数
| 参数 | 默认值 | 优化建议 | 影响 |
|---|---|---|---|
kube-scheduler --kube-api-qps |
50 | 大型集群可提升至 100-200 | 调度器与 apiserver 的通信吞吐 |
kube-scheduler --kube-api-burst |
100 | 提升至 200-400 | 突发请求时的瞬时并发能力 |
--permit-equal-sharing |
true | 保持默认 | Pod 优先级抢占时的资源公平性 |
NodeCachePeriod |
1s | 可降低至 500ms（需评估 apiserver 压力） | 节点缓存更新频率，影响调度决策实时性 |
容量优化陷阱： 不要盲目提高调度器的 QPS 和 Burst。过高的调度频率会导致 apiserver 和 etcd 的写压力激增，反而拖慢整体调度速度。建议在监控到调度器队列深度持续 > 100 时，再逐步调整。
2.5 组件间通信与瓶颈传导
理解组件间的依赖关系，有助于快速定位瓶颈根源。以下是一个典型的请求链路：
用户 (kubectl apply -f pod.yaml)
→ kube-apiserver (认证 → 准入控制 → 写入 etcd)
→ kube-scheduler (Watch 到新 Pod → 预选 → 优选 → 绑定)
→ kube-apiserver (更新 Pod 的 nodeName)
→ kubelet (Watch 到 Pod 调度到本节点 → 调用 CRI 创建容器)
→ 容器运行时 (拉取镜像 → 创建容器 → 启动进程)在这个链路中，任何一个环节的延迟都会传导至下游。例如：
- etcd 写入慢 → apiserver 响应慢 → 调度器获取 Pod 延迟 → 调度决策滞后。
- 镜像拉取慢 → kubelet 报告 Pod 状态为 Pending → 调度器认为节点资源未释放 → 新 Pod 无法调度。
- 准入控制插件耗时 → apiserver 处理请求变慢 → 所有组件通信受阻。