4. APF 队列机制：排队模型、并发限制、队列深度与超时

APF（API Priority and Fairness）是 Kubernetes 1.20+ 引入的请求排队与并发控制机制，替代了旧的 MaxInFlight 限流器。APF 通过多级队列、公平调度和超时控制，保障高优先级请求（如 kubelet 心跳、etcd 读）不被低优先级批量写请求（如 ListAllPods）阻塞。理解 APF 的排队模型、并发限制、队列深度与超时参数，是容量调优的核心前提。

4.1 排队模型：从 FlowSchema 到队列的映射

APF 的排队模型分为三层：FlowSchema → PriorityLevel → Queue。每个请求先匹配 FlowSchema，再归属到对应的 PriorityLevel，最后被哈希到该级别下的某个队列中等待调度。

关键概念： FlowSchema 通过 spec.matchRules 匹配请求属性（用户、组、资源、动词等）；PriorityLevel 定义并发上限与队列配置；Queue 是实际排队单元，每个队列内部按 FIFO 顺序处理请求。
组件 作用 配置示例
FlowSchema 将请求分类并绑定到 PriorityLevel kubectl get flowschema
PriorityLevel 定义并发数、队列数、队列长度 kubectl get prioritylevel
Queue 实际排队单元，按哈希分配 由 APF 控制器自动管理
APF 排队模型：FlowSchema → PriorityLevel → Queue APF 排队模型三层架构 FlowSchema 匹配请求属性 PriorityLevel 并发 + 队列配置 Queue 组 每个队列 FIFO 按哈希分配 说明： 每个 PriorityLevel 可配置 queues（队列数）和 handSize（哈希种子）， 请求通过 FlowSchema 匹配后，按 (requestID + handSize) % queues 分配到具体队列。

4.2 并发限制：并发数与排队阈值

每个 PriorityLevel 有两个关键并发参数：assuredConcurrencyShares（保证并发份额）和 limit（硬限制）。APF 调度器按份额比例分配总并发容量（默认 400），超出保证份额的请求进入队列等待。

参数 含义 默认值 调优建议
assuredConcurrencyShares 该级别保证的并发份额 5（全局默认） 高优先级（如 leader-election）可设为 10-20
limit 该级别最大并发数（含排队中） 无限制 建议设置，防止单级别耗尽所有并发
queuingConfig.queues 队列数量 64 低流量级别可减少到 8-16
queuingConfig.queueLengthLimit 每个队列最大深度 50 高突发场景可提升到 100-200
调优经验： 如果 kube-apiserver 日志中出现 APF queue full 或 request rejected due to queue full，说明队列深度不足或并发份额分配不合理。优先增加 queueLengthLimit，其次调整 assuredConcurrencyShares。

4.3 队列深度与超时：排队等待与请求丢弃

APF 的队列深度由 queueLengthLimit 控制，当队列满时新请求被直接拒绝（HTTP 429 Too Many Requests）。请求在队列中的最大等待时间由 queuingConfig.handSize 和 requestWaitLimit 共同决定，默认超时 60 秒。

  • 队列深度（queueLengthLimit）： 每个队列最多容纳的请求数。超过后新请求被拒绝，返回 429。
  • 排队超时（requestWaitLimit）： 请求在队列中等待的最大时间（默认 60s）。超时后请求被移除并返回 429。
  • 公平性： APF 使用 轮询调度（Round Robin） 在队列间分配处理机会，避免某个队列饿死。
APF 队列深度与超时流程 APF 队列深度与超时流程 请求到达 队列满？ 拒绝 429 入队等待 超时？ 超时移除 正常处理 说明：队列满或超时均返回 HTTP 429（Too Many Requests），客户端应重试（kube-apiserver 默认重试策略为指数退避）。

4.4 关键指标与监控

在 Grafana 面板中，APF 队列的核心监控指标包括：

指标名 类型 含义 告警阈值
apiserver_flowcontrol_current_inqueue_requests Gauge 当前队列中等待的请求数 > 队列总容量 80%
apiserver_flowcontrol_request_queue_length_after_enqueue Histogram 入队后的队列长度分布 P99 > queueLengthLimit
apiserver_flowcontrol_rejected_requests_total Counter 被拒绝的请求总数 速率 > 0 持续 5min
apiserver_flowcontrol_request_wait_duration_seconds Histogram 请求在队列中的等待时间 P99 > 30s
注意： 如果 apiserver_flowcontrol_rejected_requests_total 持续增长，说明 APF 配置过紧或后端（etcd）处理能力不足。此时应先检查 etcd 的磁盘 IO 和请求延迟，再调整 APF 队列参数，避免盲目增加队列深度掩盖后端瓶颈。

4.5 实战调优步骤

  1. 识别瓶颈级别： 通过 apiserver_flowcontrol_current_inqueue_requests 找到排队最严重的 PriorityLevel。
  2. 调整队列深度： 修改对应 PriorityLevel 的 queueLengthLimit，从 50 提升到 100 或 200。
  3. 调整并发份额： 增加高优先级级别的 assuredConcurrencyShares，减少低优先级级别。
  4. 设置硬限制： 为每个 PriorityLevel 设置 limit，防止单级别耗尽所有并发。
  5. 验证效果： 观察拒绝率下降、等待时间缩短、API Server 响应时间改善。
示例： 调整 workload-low 级别的队列深度和并发份额：
apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: PriorityLevelConfiguration
metadata:
  name: workload-low
spec:
  type: Limited
  limited:
    assuredConcurrencyShares: 10
    limit:
      type: NonReplenishing
      nominalConcurrencyShares: 100
    queuingConfig:
      queues: 32
      handSize: 8
      queueLengthLimit: 100
      requestWaitLimit: 60s
← 上一章 📖 返回目录 下一章 →