429 说明什么
API Server 内置优先级与公平性机制，会在过载时主动拒绝请求并返回 429。短时出现通常意味着某个客户端并发太高，稍后重试即可；持续出现则说明集群请求总量已超出控制面处理能力，需要从请求来源侧治理，而不是只调大服务端上限。
基本信息
| 适用平台 | Kubernetes 1.20+（优先级与公平性默认开启） |
|---|---|
| 报错形式 | 请求返回 429 Too Many Requests，客户端日志出现限流提示 |
| 观察入口 | apiserver 指标、apiserver 日志、客户端握手限速参数 |
| 常见恢复 | 退避重试、降低并发、拆分高频列表请求 |
| 本质 | 保护控制面不被瞬时压力拖垮的降级手段 |
请求量异常的常见来源
- 控制器或脚本对全量资源列表轮询，间隔设置得过短
- 多个组件各自维护全量缓存，watch 断开后瞬间重新建链拉取
- 发布流水线在短时间内并发创建大量资源
- 监控采集器以过高的频率读取 apiserver 指标
- 客户端默认并发较低却开了大量实例，叠加后压力成倍放大
观察限流
观察限流
kubectl get --raw /metrics | grep -E 'apiserver_flowcontrol_rejected_requests_total|apiserver_flowcontrol_current_executing_seats' # 看被拒请求与被占用的执行位
kubectl logs -n kube-system kube-apiserver-node1 | grep -i '429' | tail -20 # 服务端侧限流记录
kubectl get --raw /healthz?verbose | head -20 # 控制面自检
kubectl get pods -n kube-system | grep apiserver # 确认副本数与重启情况指标与现象读法
| 观察项 | 含义 | 判断方向 |
|---|---|---|
| 被拒请求数增长 | 有请求没被处理 | 结合来源定位是哪类客户端在制造压力 |
| 执行位持续占满 | 控制面正在满负荷工作 | 说明是总量问题，不只是单个客户端 |
| 请求延迟上升 | 排队时间变长 | 负载已接近上限 |
| 某客户端高频列表 | 重复拉取全量数据 | 优先改造该客户端，改用增量监听 |
客户端通常自带请求限速与突发额度参数，默认值偏保守。控制器密集部署时往往不是服务端不够，而是客户端自身限速过低导致处理变慢，需要连同服务端指标一起看。
只调大服务端并发上限而不治理来源，会把压力从入口推到 etcd 与磁盘，控制面故障会来得更突然、更难恢复。