apiserver是Kubernetes控制面的核心入口，所有kubectl命令、controller-manager、kubelet、监控组件的请求最终都要经过它。一旦某个组件突发大量请求，apiserver可能因为限流而拒绝服务，轻则watch断连、Pod状态更新失败，重则整个控制面雪崩。理解apiserver的限流机制并做针对性调优，是维护大规模集群的基本功。
一、传统的inflight限流参数及其局限
在APF出现之前，apiserver只有两个限流参数：--max-requests-inflight和--max-mutating-requests-inflight。前者控制只读请求的并发上限，默认400；后者控制写请求的并发上限，默认200。超出上限的请求会收到429状态码，响应体里带有Retry-After头提示客户端稍后重试。
这套机制的实现很简单：apiserver维护两个计数器，请求进来时计数加一，处理完成后减一，计数达到上限时直接拒绝新请求。可以通过kube-apiserver的启动参数修改，例如：
kube-apiserver \ --max-requests-inflight=800 \ --max-mutating-requests-inflight=400 \ ...
这种方式的问题是它完全不区分请求来源和重要性。假设某个监控组件以每秒上千次的频率list全量Pod，把只读并发的400个槽位全部占满，此时kubelet的心跳上报、kubectl的基本查询都会被429拒绝。也就是说，一个低价值的批量请求，可以把高价值的健康检查挤出队列，这在生产环境是致命的。
另一个问题是数值难以权衡。调小了容易误伤正常流量，调大了apiserver本身可能因为过载而响应变慢，甚至把etcd打挂。而且这个参数对所有端点一视同仁，无法对system:kube-controller-manager这类关键身份做倾斜。正因为这些局限，社区在1.18引入了Priority and Fairness（APF，API优先级与公平性）机制，并在1.20默认开启。
二、APF的工作原理：FlowSchema与PriorityLevelConfiguration
APF的核心思想是把请求分类成多个流（Flow），再根据优先级类别分配不同的并发配额。它由两个核心资源组成：FlowSchema负责识别请求属于哪一类，PriorityLevelConfiguration定义每个优先级类别的并发限制和排队策略。
FlowSchema通过一系列匹配规则对请求分类，匹配依据包括请求的verb、resource、namespace、用户身份等。每个FlowSchema指向一个PriorityLevelConfiguration，多个FlowSchema可以共享同一个优先级。默认内置的优先级包括：exempt（完全豁免限流，比如apiserver自身的健康检查和system-leader-election请求）、node-high（kubelet相关的system:nodes请求，并发配额最高）、system（controller-manager与scheduler）、leader-election、workload-high、workload-low、global-default（兜底）等。
每个PriorityLevelConfiguration内部有两种模式：一种是limited，通过nominalConcurrencyShares按比例分得总并发池的一部分，并可以配置排队队列的深度与排队时长；另一种是exempt，直接绕过限流。注意APF分配的是并发槽位（seat）而不是QPS，这一点和常见的令牌桶限流不同，它保护的是apiserver同时处理的请求数，更贴合后端资源瓶颈的本质。
查看当前集群的FlowSchema分布可以用：
kubectl get flowschema kubectl get prioritylevelconfiguration # 查看某个flow的实时统计 kubectl get --raw='/metrics' | grep apiserver_flow
其中apiserver_flow_dispatched_requests_total按FlowSchema统计已分发请求数，apiserver_flow_rejected_requests_total则统计被拒绝的数量。如果发现某个flow的rejected持续增长，说明该优先级的并发配额不够或队列满了，这就是调优的切入点。
三、生产环境调优实践与常见坑
首先要学会识别限流问题。客户端侧的典型表现是频繁收到Too many requests错误，或controller的日志中出现retries exceeded。服务端可以用kubectl get --raw查询APF的只读状态接口：
kubectl get --raw='/api/v1/namespaces/kube-system/services/https:kube-apiserver/proxy/metrics' \ | grep -E 'flow_rejected|flow_dispatched'
调优时把握几个原则。第一，不要急着调大总并发，先分析被拒的是哪个flow。如果是监控或CI大量list导致的，更好的做法是给这类流量创建一个低优先级的FlowSchema，让它走单独的小配额，而不是挤占全局额度。可以自定义一个PriorityLevelConfiguration限制并发为50，再写一个FlowSchema匹配该服务的ServiceAccount：
apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: PriorityLevelConfiguration
metadata:
name: monitoring-low
spec:
type: Limited
limited:
nominalConcurrencyShares: 10
limitResponse:
type: Queue
queuing:
queues: 16
handSize: 4
queueLengthLimit: 100
---
apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: FlowSchema
metadata:
name: monitoring-cron
spec:
priorityLevelConfiguration:
name: monitoring-low
matchingPrecedence: 1000
rules:
- subjects:
- kind: ServiceAccount
namespace: monitoring
name: prometheus
resourceRules:
- verbs: ["list", "watch"]
resources: ["pods"]
第二，注意matchingPrecedence的取值。数值越小优先级越高，内置的FlowSchema占用了一部分区间，自定义规则建议放在较大的数值上（比如1000以后），否则可能覆盖内置规则，导致本该走node-high的kubelet请求被错误降级。
第三，大集群场景下可以适当调大--max-requests-inflight给APF更大的总池子，同时观察etcd的延迟指标。APF只是在总量内重新分配，如果etcd本身已经是瓶颈，调大并发只会让延迟进一步恶化，此时应该考虑etcd调优或分库。另外在升级时留意APF的API版本变化，1.29起默认是v1beta3，老版本集群如果写死了v1beta1，升级后可能出现资源应用失败的问题。
最后提醒一点：exempt优先级要慎用。把业务流量放进豁免名单等于放弃了保护，一旦这些请求失控，apiserver没有任何手段兜底。合理利用默认的多级体系，让关键组件高优先级、普通业务按份额排队，才是APF设计的本意。配置变更后，持续观察一段时间的flow指标曲线，确认拒绝数归零、排队延迟可控，才算完成一次合格的限流调优。
Kubernetes apiserver限流APF限流max-requests-inflight修改时间：2026-09-13 02:02:37