1. 课程导论：Operator控制面蓝图概述、API Priority与Fairness (APF) 机制简介、命中率与误报率的核心定义
1.1 Operator控制面蓝图概述
在云原生生态中，Kubernetes Operator 是扩展控制面逻辑的核心模式。Operator 通过自定义资源（CR）和控制器循环，将运维知识编码为自动化程序。然而，随着集群规模增长和 Operator 数量激增，控制面的 API 请求压力成为稳定性瓶颈。
Operator 控制面蓝图 是一套面向生产环境的架构参考模型，涵盖以下关键层次：
| 层次 | 组件 | 职责 |
|---|---|---|
| 接入层 | API Server (kube-apiserver) | 请求认证、授权、准入控制、请求分发 |
| 调度层 | API Priority & Fairness (APF) | 请求排队、优先级分配、公平调度 |
| 处理层 | Operator Controller / Webhook | 资源调谐、变更校验、业务逻辑执行 |
| 存储层 | etcd | 持久化资源状态、监听变更事件 |
Operator 的调谐循环会频繁发起 List-Watch、Create、Update、Delete 等 API 调用。当多个 Operator 同时运行时，控制面可能面临请求洪峰，导致 API Server 过载、响应延迟飙升，甚至触发级联故障。
1.2 API Priority & Fairness (APF) 机制简介
APF 是 Kubernetes 1.20+ 引入的 GA 特性，用于替代旧的 MaxRequestsInFlight 限流机制。APF 通过 优先级（Priority） 和 公平性（Fairness） 两个维度，对 API 请求进行精细化调度。
1.2.1 核心概念
- PriorityLevelConfiguration (PLC)：定义请求优先级等级，每个等级有独立的并发配额（assuredConcurrencyShares）和排队参数。
- FlowSchema (FS)：将请求按属性（用户、组、资源、动词等）匹配到对应的 PLC。
- 排队模型：每个 PLC 内部维护多个队列，使用 shuffle sharding 算法确保公平性，防止单一流饿死其他流。
1.2.2 请求处理流程
- 请求到达 API Server，APF 拦截器根据请求属性匹配 FlowSchema。
- FlowSchema 将请求分配到对应的 PriorityLevelConfiguration。
- PLC 检查当前并发水位：若未达到限制，请求直接放行；若已超限，请求进入队列等待。
- 队列按 FIFO 顺序出队，但受限于公平性算法，确保高优先级流获得更多处理机会。
1.3 命中率与误报率的核心定义
在 APF 策略审计与调优过程中，命中率 和 误报率 是衡量策略有效性的两个关键指标。它们帮助 SRE 判断：当前 APF 配置是否准确地将请求分类到预期的优先级队列。
1.3.1 命中率 (Hit Rate)
定义： 在 APF 策略评估中，命中率表示 被正确分配到预期 PriorityLevel 的请求数 占 该预期类别总请求数 的比例。
示例： 假设 Operator-A 的所有调谐请求应被分配到 operator-critical 优先级。若 1000 次请求中有 950 次成功匹配，50 次被错误分配到其他优先级，则命中率为 95%。
1.3.2 误报率 (False Positive Rate)
定义： 误报率表示 不应属于某 PriorityLevel 的请求被错误分配进去 的数量，占 该 PriorityLevel 总分配请求数 的比例。
示例： 若 operator-critical 优先级队列中混入了 30 个来自低优先级 Operator 的请求，而该队列总请求数为 600，则误报率为 5%。
1.3.3 指标对比
| 指标 | 关注点 | 理想值 | 常见原因 |
|---|---|---|---|
| 命中率 | 策略是否覆盖了目标请求 | 接近 100% | FlowSchema 规则缺失、标签不匹配 |
| 误报率 | 策略是否引入了噪声请求 | 接近 0% | FlowSchema 规则过于宽泛、通配符滥用 |
1.3.4 为什么需要复核命中率与误报率？
- 避免关键请求被降级： 低命中率意味着高优先级 Operator 的请求可能被误分到低优先级队列，导致调谐延迟。
- 防止资源被低价值请求抢占： 高误报率意味着低优先级请求侵占了高优先级队列的并发配额，影响关键业务。
- 优化 APF 配置： 通过持续监控这两个指标，SRE 可以迭代调整 FlowSchema 规则，实现控制面的精细化流量管理。