直接配置--max-requests-inflight和--max-mutating-requests-inflight是最基础有效的防御手段，分别限制非变更类和变更类请求的并发数，默认400和200，总和600；超限即返回429，不排队；应通过kubeadm配置升级持久生效，并搭配APF实现精细防护。
直接配置 --max-requests-inflight 和 --max-mutating-requests-inflight 是最基础、最有效的防御手段，能立刻限制恶意请求对 kube-apiserver 的并发冲击。它不依赖复杂策略，而是用硬性通道容量堵住“正在飞”的请求数，防止服务因堆积而崩溃。
理解两个核心并发限值
这两个参数控制的是“同时处理中”的请求数（即 inflight），不是每秒请求数（QPS）：
-
--max-requests-inflight：限制非变更类请求（如
GET、LIST、WATCH）的最大并发数，默认 400 -
--max-mutating-requests-inflight：限制变更类请求（如
POST、PUT、DELETE、PATCH）的最大并发数，默认 200
两者之和即为 apiserver 总并发上限（默认 600）。一旦达到上限，新请求会被立即拒绝（HTTP 429），不排队、不等待——这是对抗恶意轰炸的关键特性。
在 kubeadm 集群中安全修改参数
不要直接编辑静态 Pod 清单，应通过 kubeadm 配置升级机制持久生效：
- 编辑集群配置文件（如
cluster.yaml），在apiServer.extraArgs下添加：
extraArgs:
max-requests-inflight: "300"
max-mutating-requests-inflight: "150"
- 执行
kubeadm upgrade apply --config cluster.yaml（适用于已运行集群） - 或新建集群时用
kubeadm init --config cluster.yaml
修改后，kube-apiserver Pod 会自动滚动重启，新限值即时生效。注意：数值不宜过低（如低于 50/25），否则可能影响 kubelet 心跳、控制器同步等关键内部流量。
搭配 APF 实现更精细的防护
仅靠全局并发限流无法区分恶意客户端与正常组件。Kubernetes 1.20+ 默认启用的 API 优先级和公平性（APF）可补足这一短板：
- 为
system:masters（如kubectl）绑定exempt优先级，完全绕过限流 - 为
system:nodes（kubelet）分配专用system-node-high流量规则，保障节点心跳不被挤占 - 为普通用户或外部集成工具创建独立 FlowSchema，将其请求隔离到专属队列中
这样即使某个客户端发起大量请求，也只会撑爆自己的队列，不会阻塞系统关键路径。可通过 kubectl get flowschema,prioritylevelconfiguration 查看当前策略。
验证与观测要点
配置不是一劳永逸，需确认是否真正起效：
- 检查 apiserver 启动参数：
kubectl -n kube-system exec kube-apiserver-xxx -- ps aux | grep max- - 观察拒绝指标：
kube_apiserver_current_inflight_requests（实际并发）、kube_apiserver_request_total{code="429"}（被限流数） - 模拟压力测试时，用
watch -n1 'kubectl get nodes'确保管理操作始终可用，避免误伤
不复杂但容易忽略：限流是第一道防线，但必须配合日志审计（Audit）和网络层防护（如 WAF、IP 黑名单）才能形成纵深防御体系。
