控制面API Server一旦对请求限流，调度器发出的Pod绑定、节点更新、缓存同步请求会被直接拒绝或排队，调度吞吐的瓶颈不在算法效率，而在控制面给调度器的“呼吸空间”被掐住了，限流阈值设置过紧时,调度器连把结果写回集群的机会都要排队。
Kubernetes调度吞吐上不去怎么办：先查API限流
很多团队排查调度慢的时候，第一反应是看调度器CPU、内存、日志，资源占用不高，日志也没有明显报错，但吞吐就是上不去，遇到这种情况，先查API Server的限流指标,多数情况下问题不在调度器本身。
调度器的工作链路很清晰：监听Pod变更 → 过滤打分 → 选定节点 → 向API Server提交绑定请求，前两步是纯计算，第三步是网络写入,限流卡的就是第三步。
调度器被限流的三个典型信号
- apiserver_request_terminations_total 指标持续增长，说明请求被主动切断
- 调度器日志反复出现
client rate limiter或context deadline exceeded - 调度队列深度波动异常：队列明明有大量待调度Pod，但调度器处理速率明显低于理论值
这三个信号同时出现，基本可以确认控制面限流是吞吐瓶颈，单独出现一个,还需要继续排查。
排查路径与具体操作
先拿到API Server的限流相关指标：
kubectl get --raw /metrics | grep -E "apiserver_request_terminations|apiserver_flowcontrol"重点看 flowcontrol 相关指标，API Server的优先级公平性机制（APF）会为不同请求分类分配并发份额，调度器发起的绑定请求排在哪个优先级、拿到多少配额,直接决定调度吞吐上限。
如果看到调度器发起的 pods/binding 请求被大量丢弃或排队,就需要调整FlowSchema和PriorityLevelConfiguration。
控制面限流和节点资源不足区别：别让kubelet背锅
很多工程师分不清调度失败到底是谁的责任，Pod卡在Pending状态，节点上内存明明还够，调度器就是不下发，这时候要分清：是调度器被限流导致决策结果没写回去，还是节点真的装不下
。
两种瓶颈的关键差异
| 判断维度 | 控制面限流 | 节点资源不足 |
|---|---|---|
| 调度器日志 | 有限流相关报错 | 通常是Unschedulable |
| Pod状态 | Pending，无事件或事件很少 | Pending，有Insufficient事件 |
| 节点资源 | 有充足余量 | CPU/内存实际紧张 |
kubectl describe pod |
事件为空或只有调度失败 | 有详细的资源不足说明 |
| API Server指标 | 请求丢弃率升高 | 正常 |
最简单的判断方法：手动对一个资源需求很小的测试Pod执行 kubectl bind 操作，如果这个操作都超时，说明控制面已经卡住了，如果测试Pod秒绑成功,问题大概率在资源侧。
实操判断命令
kubectl describe pod <pod-name> -n <namespace>如果事件列表里出现 FailedScheduling 并且原因是 Insufficient cpu 或 Insufficient memory，这是典型的资源不足，如果事件列表几乎空白，或者只有一条 Scheduling 事件后再无下文，就要去看API Server侧。
大规模集群Pod调度延迟排查：API限流参数调优对比
大规模集群Pod调度延迟排查的核心思路是：先量化，再调参,最后对比效果。
API限流参数调优对比的三个层次
- 默认值层面：Kubernetes默认的APF配置对中小集群够用，但节点数量超过一定规模后，绑定请求的并发配额就不够看了
- 调度器参数层面：
--kube-api-qps和--kube-api-burst这两个参数控制调度器向API Server发请求的速率，默认值偏保守 - APF配置层面：调整FlowSchema的优先级分配，给
system:kube-scheduler对应的FlowSchema更高并发份额
具体调整步骤
先查看当前APF配置：
kubectl get flowschemas.flowcontrol.apiserver.k8s.io kubectl get prioritylevelconfigurations.flowcontrol.apiserver.k8s.io
找到调度器对应的FlowSchema，查看它绑定的PriorityLevel，多数集群里调度器的请求被归类到 workload-low 或类似级别，并发名额有限，可以创建一个独立的PriorityLevelConfiguration，把调度器请求单独分出来,分配更充裕的并发预算。
调度器自身的限流参数也要同步调整，在kube-scheduler启动参数里，把 --kube-api-qps 和 --kube-api-burst 提到一个相对宽裕的值，但注意别调得过大，否则调度器会在瞬时向API Server打出大量请求,反而加剧控制面压力。
调优对比的方法：先在测试集群跑一轮基准，记录单位时间内成功调度的Pod数量，调整参数后，同样负载下再跑一轮，对比两次的调度吞吐和API Server请求丢弃率，多数情况下,合理调整后吞吐提升的幅度相当明显。
控制面API Server的“呼吸节奏”如何影响调度吞吐
API Server不是无限容量的，它内部有一套复杂的优先级公平性机制，给每种请求类型分配“呼吸配额”，调度器的绑定请求和节点状态更新请求，在API Server眼里只是众多流量中的一部分。
APF机制的本质
APF把请求按来源和类型分组，每组绑定一个优先级，高优先级请求能抢占更多并发处理名额，低优先级请求只能排队甚至被丢弃。调度器的请求如果没有专门的优先级配置，往往被塞进默认的低优先级池子里，和大量控制器请求、健康检查请求挤在一起。
这个机制的设计初衷是保护API Server不被某类流量压垮，但副作用是：在调度高峰期，调度器的关键写入请求可能被其他更“吵”的流量挤掉。
调度器与API Server的“憋气”状态
调度器从Watch管道拿到待调度Pod后，如果绑定请求一直排队，它只能把Pod重新放进队列，这就是调度器“憋气”：明明算出了结果，就是说不出来，更麻烦的是，调度器的速率限制器会进一步降低重试频率,导致整个调度循环的节奏被拖慢。
北京地区K8s集群优化服务的选择思路
北京地区K8s集群优化服务目前主要分两类：云厂商原生的托管控制面方案，以及第三方专业技术团队提供的调优服务，两类选择的核心差异不在技术本身,而在对控制面参数的掌控深度。
托管集群的控制面限制
使用云厂商托管Kubernetes服务时，API Server的APF配置通常被锁定或限制修改，这是云厂商为了多租户安全做的取舍，但对调度吞吐有强需求的团队来说，这个限制恰好卡在关键位置，北京地区的多家大型互联网公司在使用托管集群时,调度吞吐瓶颈往往最终指向控制面参数不可调。
自建集群的调优空间
自建集群则完全不同，API Server参数、APF配置、调度器限流参数全部可控，优化的天花板更高，代价是需要团队对Kubernetes控制面机制有足够深的理解，北京不少中大型企业选择在核心业务场景下自建控制面,正是为了拿到这个调优空间。
选择建议很简单：如果调度吞吐是核心指标，优先考虑控制面参数可调的自建或半托管方案，如果业务对调度延迟不敏感,托管集群的省心程度更具吸引力。
Q&A：控制面API接口限流常见问题
控制面API限流会直接导致Pod调度失败吗
会，调度器向API Server提交Pod绑定请求时，如果请求被限流拒绝，调度器无法把决策结果写回集群，Pod会一直停留在Pending状态，直到调度器重试成功，限流导致的“调度失败”是可恢复的,不像资源不足那样需要人工干预。
API限流参数调优为什么有时效果不明显
因为控制面限流是多层的，调度器自身的 --kube-api-qps 只是客户端侧限流，API Server内部的APF机制才是服务端限流，只调整调度器参数，不调整APF配置，就像把水龙头的阀门开大，但水管本身还是原来的粗细，两层都要调,效果才会显现。
多大的集群规模容易触发控制面限流拖累调度吞吐
没有一个绝对的节点数阈值，节点数量超过数百台、同时有较多控制器在工作、或者大量Pod频繁创建销毁，就可能触发，判断标准不是集群规模本身，而是 API Server请求丢弃率在调度高峰时是否持续上升，用指标说话,比听凭经验更可靠。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641571.html
