Kubernetes API速率限制调整及QPS、Burst配置问题咨询

kubeconfig = resolveKubeconfig(kubeconfig)
if kubeconfig == "" {
    return nil, fmt.Errorf("%s: %w", msgCouldNotCreateClientConfig, ErrLocatingKubeconfig)
}
config, err := clientcmd.BuildConfigFromFlags("", kubeconfig)
// 新增限流配置参考
config.QPS = 250
config.Burst = 500 

问题1：仅提交5个Deployment触发限流的原因 #

你遇到的限流基本都是client-go客户端本地的限流，而非Kubernetes API Server侧的限流：

• client-go官方默认的RESTClient配置参数为QPS=5、Burst=10，超过阈值后客户端会主动阻塞等待限流令牌，表现就是操作耗时变长，和API Server的服务端限流无关。
• 你感知到的只有5个Deployment提交请求，但实际unstruct模式的apply操作内部会产生远多于5次的请求：包括初始化客户端时拉取API资源列表的发现请求、每个apply操作前先查询对应资源当前状态的GET请求、校验资源权限的请求、最终提交变更的PATCH/POST请求，5个Deployment累计请求量很容易超过默认5QPS的阈值，触发客户端限流。

问题2：主动调高QPS到250的合理性和风险 #

这个操作是合理的，风险可控：

• 合理性：如果你的集群API Server日常负载不高，单客户端250QPS的请求量完全在绝大多数生产集群的承载范围内，调高后能避免客户端无意义的限流等待，提升操作效率。
• 潜在风险：只有当你有大量同配置的客户端同时向API Server发起请求，总请求量超过API Server的--max-requests-inflight（默认400）、--max-mutating-requests-inflight（默认200）阈值时，才可能导致API Server负载过高，影响集群其他业务。单客户端使用250QPS不会有问题。

问题3：是否需要同时配置Burst参数 #

建议同时配置Burst参数，两个参数的逻辑和配置规则如下：

• 两个参数都是客户端限流的令牌桶实现参数：QPS是每秒生成的令牌数，控制平均请求速率；Burst是令牌桶的最大容量，控制允许的瞬时峰值请求数。
• 如果你仅配置QPS=250，没有手动修改Burst的话，Burst还是会沿用默认值10，瞬时请求超过10时依然会被限流，无法完全发挥高QPS的优势。
• 常规配置规则是Burst设为QPS的1_{3倍即可，比如`QPS=250`对应`Burst=300`}Burst=750，如果有批量操作的需求可以适当调高Burst的值。

内容的提问来源于stack exchange，提问作者Jenny M