3. APF 架构深度解析：FlowSchema 与 PriorityLevelConfiguration

APF（API Priority and Fairness）是 Kubernetes 1.20+ 引入的请求队列与并发控制机制，替代了原有的 MaxInFlight 限流器。其核心设计围绕两个 CRD 资源展开：FlowSchema 负责请求分类与优先级映射，PriorityLevelConfiguration 负责并发预算与排队策略。理解这两者的协同关系，是进行容量调优与配额校准的前提。

3.1 FlowSchema：请求分类与优先级映射

FlowSchema 定义了如何将进入 API Server 的请求归类，并指定其归属的 PriorityLevel。每个请求会按 matchingPrecedence（匹配优先级，数值越小优先级越高）依次匹配 FlowSchema，一旦命中即停止匹配。

3.2 PriorityLevelConfiguration：并发控制与排队机制

PriorityLevelConfiguration 定义了每个优先级级别的并发预算和排队行为。每个 PriorityLevel 拥有独立的 并发槽位（concurrency slots），请求在槽位不足时进入队列等待，队列满则直接拒绝（429 Too Many Requests）。

3.3 排队机制与公平调度

APF 使用 公平排队（Fair Queuing） 算法，结合 分片哈希（Shuffle Sharding） 实现请求级别的公平调度。每个 PriorityLevel 内部维护多个队列，请求通过 distinguisher 计算哈希后分配到特定队列，同一 distinguisher 的请求进入同一队列，避免单个用户/命名空间阻塞其他请求。

3.4 并发控制计算模型

APF 的并发控制基于 总并发预算（Total Concurrency Budget） 的分配。API Server 启动时根据 --max-requests-inflight 和 --max-mutating-requests-inflight 计算总槽位数，然后按各 PriorityLevel 的 assuredConcurrencyShares 比例分配。

当某个 PriorityLevel 的保证槽位未被完全使用时，空闲槽位可以临时借给其他负载较高的 PriorityLevel，实现资源利用率最大化。但每个 PriorityLevel 的 借用上限 受限于其配置的 queuing 参数和系统总预算。

3.5 请求分类与优先级实战配置

以下是一个生产环境的 FlowSchema 与 PriorityLevel 配置示例，适用于多租户集群：

apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: FlowSchema
metadata:
  name: system-kubelet
spec:
  matchingPrecedence: 500
  distinguisherMethod:
    type: ByUser
  rules:
  - subjects:
    - kind: ServiceAccount
      serviceAccount:
        name: kubelet
        namespace: kube-system
    resources:
    - apiGroups: [""]
      resources: ["nodes", "pods", "events"]
    verbs: ["get", "list", "watch", "update", "patch"]
  priorityLevelConfiguration:
    name: system-high
---
apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: PriorityLevelConfiguration
metadata:
  name: system-high
spec:
  type: Limited
  limited:
    assuredConcurrencyShares: 10
    limitResponse:
      type: Queue
      queuing:
        queues: 64
        handSize: 8
        queueLengthLimit: 50

3.6 监控与调试命令