4. SLO 违约场景分析：常见违约场景、影响范围与严重等级
控制面 SLO 违约并非单一故障模式，而是由不同组件、不同压力形态引发的多维失效。本章聚焦三大高频违约场景——API Server 过载、etcd 慢查询、调度失败，逐一拆解其触发条件、影响范围与严重等级，为后续准入门禁策略提供判定依据。
4.1 场景一：API Server 过载
API Server 是控制面的流量入口，所有 kubectl、控制器、调度器、组件及外部系统的请求均汇聚于此。当并发请求量超过 API Server 的处理能力或 etcd 的承载上限时，即进入过载状态。
4.1.1 典型触发条件
- 突发读请求洪峰：大量 List-Watch 请求同时发起（如 CI/CD 批量部署、监控系统全量拉取资源）。
- 写请求风暴：控制器因配置错误产生大量 Update/Create 请求（如 HPA 频繁调整副本数、Operator 循环 reconcile）。
- 资源泄漏：客户端未关闭 Watch 连接，导致 API Server 维护大量长连接，内存持续增长。
- 认证/授权瓶颈：Webhook 鉴权延迟过高，导致请求排队积压。
4.1.2 影响范围
| 影响维度 | 具体表现 |
|---|---|
| 控制面可用性 | kubectl 命令超时、控制器无法同步状态、组件间通信中断 |
| 数据面 | Pod 状态更新延迟、Endpoint 变更无法及时下发至 kube-proxy |
| 运维操作 | 滚动更新、扩缩容、配置变更均无法执行 |
| 监控/告警 | Prometheus 拉取指标失败，告警系统失明 |
4.1.3 严重等级
- P0（严重）：API Server 完全不可用，所有客户端请求均返回 503/429，控制面功能瘫痪。
- P1（高）：API Server 响应延迟 > 5s，部分请求超时，控制器 reconcile 循环受阻。
- P2（中）：API Server 响应延迟 1~5s，偶发超时，但核心控制循环仍可维持。
关键指标：API Server 的
apiserver_request_duration_seconds 的 p99 超过 1s 即进入 P2 警戒线；超过 5s 触发 P1；完全无响应则进入 P0。
4.2 场景二：etcd 慢查询
etcd 是控制面的状态存储核心，所有资源对象、集群状态均持久化在 etcd 中。etcd 的读写性能直接决定 API Server 的响应速度。慢查询通常由磁盘 I/O、网络延迟、大对象存储或频繁的 compaction 引发。
4.2.1 典型触发条件
- 大对象写入：单个资源对象（如 ConfigMap、Secret）超过 1MB，导致 etcd 写入延迟飙升。
- 频繁的 List 全量查询：未使用分页或 Watch 机制，持续发起全量 List 请求，消耗 etcd 内存与 CPU。
- 磁盘 I/O 瓶颈：etcd 数据盘使用 HDD 或共享存储，fsync 延迟过高。
- Leader 频繁切换：网络分区或节点故障导致 Raft 选举震荡，写入性能骤降。
4.2.2 影响范围
| 影响维度 | 具体表现 |
|---|---|
| API Server | 所有读写请求均依赖 etcd，慢查询直接导致 API Server 响应延迟 |
| 调度器 | 调度器无法及时获取节点状态，调度决策延迟 |
| 控制器 | Deployment、StatefulSet 等控制器无法更新状态，reconcile 循环阻塞 |
| 集群稳定性 | etcd 空间不足或 compaction 失败可能导致集群只读 |
4.2.3 严重等级
- P0（严重）：etcd 写入延迟 > 10s 或完全不可写，集群进入只读模式，控制面功能丧失。
- P1（高）：etcd 读写延迟 2~10s，API Server 频繁超时，控制器状态更新滞后。
- P2（中）：etcd 读写延迟 500ms~2s，偶发慢查询，但整体控制面仍可工作。
注意：etcd 慢查询往往被误判为 API Server 过载。排查时应优先检查 etcd 指标
etcd_request_duration_seconds 和 etcd_disk_wal_fsync_duration_seconds，以区分根因。
4.3 场景三：调度失败
调度器负责将 Pod 分配到合适的节点。当调度器因资源不足、节点故障、调度策略冲突等原因无法完成调度时，Pod 将长时间处于 Pending 状态，直接影响应用可用性。
4.3.1 典型触发条件
- 资源碎片化：集群整体资源充足，但单个节点无法满足 Pod 的 CPU/Memory 请求。
- 节点故障：大量节点处于 NotReady 状态，可用节点池缩小。
- 调度策略冲突：Pod 设置了严格的 nodeSelector、affinity 或 taint/toleration，导致无可用节点。
- 调度器性能瓶颈：调度器队列积压，调度周期过长（超过 5s）。
4.3.2 影响范围
| 影响维度 | 具体表现 |
|---|---|
| 应用部署 | 新 Pod 无法启动，滚动更新卡住，扩缩容失败 |
| 集群利用率 | 资源闲置但 Pod 无法调度，集群效率下降 |
| 自愈能力 | 故障 Pod 被驱逐后无法重新调度，服务降级 |
| 运维效率 | 运维人员需手动排查调度失败原因，增加 MTTR |
4.3.3 严重等级
- P0（严重）：调度器完全不可用，所有 Pod 均无法调度，集群无法承载新工作负载。
- P1（高）：调度延迟 > 10s 或超过 20% 的 Pod 处于 Pending 状态，核心服务受影响。
- P2（中）：调度延迟 5~10s 或少量 Pod 因资源碎片化 Pending，可通过手动干预解决。
4.4 三大场景对比与关联
下表从触发源、影响链路、典型指标三个维度对三大违约场景进行横向对比：
| 场景 | 触发源 | 影响链路 | 核心指标 |
|---|---|---|---|
| API Server 过载 | 客户端请求洪峰、资源泄漏 | API Server → 控制器 → 数据面 | apiserver_request_duration_seconds |
| etcd 慢查询 | 大对象、磁盘 I/O、Leader 切换 | etcd → API Server → 所有组件 | etcd_request_duration_seconds |
| 调度失败 | 资源碎片、节点故障、策略冲突 | 调度器 → Pod 状态 → 应用可用性 | scheduler_pod_scheduling_duration_seconds |
实践建议：在准入门禁设计中，应针对上述三种场景分别设置独立的准入规则。例如：API Server 过载时拒绝非关键写请求；etcd 慢查询时限制大对象创建；调度失败时禁止提交无调度约束的 Pod。
4.5 场景关联 SVG 图：控制面 SLO 违约影响链路
下图展示了三大违约场景在控制面内部的传播路径与相互影响关系：
4.6 场景关联 SVG 图：SLO 违约严重等级判定矩阵
下图以矩阵形式展示三大场景在不同严重等级下的判定标准，帮助运维人员快速定级：
4.7 准入门禁与违约等级的映射
基于上述场景与等级分析，准入门禁策略应按照以下映射关系执行：
| 违约等级 | 准入门禁动作 | 适用场景 |
|---|---|---|
| P0 | 阻断所有非关键写请求，仅允许只读操作和紧急运维命令 | API Server 完全不可用、etcd 只读、调度器宕机 |
| P1 | 限流：对非关键命名空间/用户实施请求速率限制，拒绝大对象创建 | API Server 高延迟、etcd 慢查询、调度大面积失败 |
| P2 | 告警并记录，对特定资源类型（如 ConfigMap > 500KB）实施准入检查 | 偶发超时、资源碎片化导致的调度失败 |
| P3 | 正常通行，仅记录审计日志 | 轻微波动，未触发 SLO 阈值 |
核心原则：准入门禁的严格程度应与当前控制面 SLO 违约等级正相关。P0 时宁可过度阻断，也不允许故障扩散；P2 时则优先保障关键业务，对非关键请求实施柔性限流。