APF未启用需同时配置--feature-gates=APIPriorityAndFairness=true与--runtime-config=flowcontrol.apiserver.k8s.io/v1beta2=true；应创建workload-critical优先级、exempt管理员FlowSchema及cilium限流策略。
当集群中某个客户端（比如Cilium agent、自定义Operator或误配的Informer）持续发起大量LIST请求，kube-apiserver内存可能在几分钟内飙升至50GB并反复OOM崩溃，此时仅调高--max-requests-inflight参数无法根治问题——它不区分请求来源，关键管理流量和普通查询混在同一队列里互相挤占。
确认APF是否已启用
执行kubectl get prioritylevelconfigurations。若返回No resources found或报错the server doesn't have a resource type "prioritylevelconfigurations"，说明APF未启用或API组被禁用。
检查kube-apiserver启动参数：登录控制平面节点，运行ps aux | grep kube-apiserver | grep -E "(APIPriorityAndFairness|flowcontrol)"。必须同时存在--feature-gates=APIPriorityAndFairness=true与--runtime-config=flowcontrol.apiserver.k8s.io/v1beta2=true，缺一不可。
【缺少任一参数将导致APF完全不生效，所有FlowSchema和PriorityLevelConfiguration资源会被忽略】
创建专用高保障优先级：workload-critical
新建文件pl-workload-critical.yaml：
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2kind: PriorityLevelConfigurationmetadata: name: workload-criticalspec: type: Limited limited: assuredConcurrencyShares: 30 limitResponse: type: Queue queuing: queues: 64 queueLengthLimit: 100 handSize: 6
执行kubectl apply -f pl-workload-critical.yaml。此配置为关键工作负载预留30个并发额度，启用64队列+100长度缓冲，避免突发LIST请求直接触发429拒绝。
将system:masters和kube-scheduler定向到豁免队列
方法一：复用默认exempt优先级
直接编辑系统自带的health-for-strangers FlowSchema，将其matchingPrecedence设为1，确保最高匹配优先级；再添加subjects块匹配管理员组：
subjects:- kind: User name: system:admin- kind: Group name: system:masters- kind: User name: system:kube-scheduler
方法二：新建专用FlowSchema（推荐）
创建fs-exempt-admins.yaml，其中matchingPrecedence: 5，priorityLevelConfiguration.name: exempt，rules中明确限定verbs: ["get", "list", "watch"]且resources: ["nodes", "pods", "deployments"]——这能防止exempt队列被滥用，只放行真正需要零延迟的管理操作。
隔离恶意大查询：按ServiceAccount限流
第一步：识别问题客户端
运行kubectl top pods -n kube-system | grep cilium，结合kubectl logs -n kube-system cilium-xxxxx | grep -i "list.*pods"确认高频查询来源。记下其ServiceAccount名称（如cilium）和命名空间（如kube-system）。
第二步：创建限制性FlowSchema
编写fs-cilium-limited.yaml，关键点：distinguisherMethod.type: ByUser确保每个SA独立排队；matchingPrecedence: 500置于system-nodes之后、global-default之前；rules中clusterScope: true且verbs: ["list"]精确匹配，避免误伤create/update。
第三步：绑定低配PriorityLevel
新建pl-cilium-low.yaml，assuredConcurrencyShares: 5，limitResponse.type: Queue，queueLengthLimit: 20。这个5并发+20队列的组合，足以支撑Cilium每秒3–5次LIST，但会立即阻塞其突发至每秒50次的扫描行为。
第四步：应用并验证
依次执行kubectl apply -f pl-cilium-low.yaml→kubectl apply -f fs-cilium-limited.yaml。5秒后，观察kubectl get flowschemas.cilium-pods -o wide输出中的STATUS列是否变为True，且MISSINGPL为False。
