v1.19.9 kube-apiserver日志latency是否包含请求处理队列时长？

先明确：日志中的latency是否包含队列耗时？ #

从你提供的v1.19.9版本httplog.go实现来看，日志里的latency不包含请求在队列中等待的耗时。

这个计时是从kube-apiserver的HTTP handler接收到请求开始，到响应完全写出为止。而请求进入各种限流队列（比如inflight限流队列、Priority and Fairness调度队列）的等待时间，发生在HTTP handler之前，这段时间不会被计入日志中的latency。

如果要查看队列等待耗时，可关注apiserver的监控指标：apiserver_request_scheduling_duration_seconds（对应P&F调度等待）、apiserver_inflight_requests_wait_duration_seconds（对应传统inflight限流等待）。

针对你的场景：仅Go Clientset请求缓慢的排查方向 #

既然inflight请求指标远低于阈值、kubectl请求正常，问题大概率出在客户端侧或客户端与apiserver的交互环节，建议从以下几点排查：

1. Go Clientset的自身配置限制 #

默认kubernetes.Clientset的QPS（每秒请求数）为5、Burst（突发请求数）为10。如果微服务请求量超过这个限制，Clientset会在客户端本地限流，导致请求延迟发送。可检查代码中是否自定义调整了这两个参数：

config, err := rest.InClusterConfig()
if err != nil {
    // 错误处理
}
// 根据业务需求调整QPS和Burst
config.QPS = 50
config.Burst = 100
clientset, err := kubernetes.NewForConfig(config)

2. 客户端连接池复用问题 #

Go的HTTP客户端默认复用连接，但如果配置不当（比如超时过短、连接被过早关闭），可能导致每次请求都新建TCP连接，握手耗时会拉长整体请求时间。可检查Clientset的HTTP客户端配置：

• 确认未设置过短的IdleConnTimeout
• 检查是否开启了DisableKeepAlives（默认是false）

3. Priority and Fairness的调度影响 #

虽然开启了P&F且inflight请求少，但如果微服务请求的优先级较低，可能会被P&F调度逻辑延迟处理。可查看apiserver_request_scheduling_duration_seconds指标，筛选出微服务对应的userAgent请求，确认是否有明显的调度等待时间。

4. 客户端与apiserver之间的网络差异 #

kubectl所在节点和微服务所在节点到apiserver的网络状况可能不同。可在微服务节点执行：

curl -w "%{time_total}\n" -k https://<apiserver-ip>/api/v1/namespaces/xxx/resourcequotas

对比kubectl节点的执行结果，看网络耗时是否存在差异。

5. 认证环节的耗时 #

如果微服务使用ServiceAccount认证，检查是否每次请求都需要重新获取token（比如token缓存失效、代码未正确缓存token），或apiserver侧ServiceAccount token验证耗时过长。可在apiserver日志中搜索相关认证日志，确认是否有延迟。

6. 客户端侧的请求追踪 #

在微服务代码中添加请求耗时日志，记录从调用Clientset方法到收到响应的总时间，和apiserver日志中的latency做对比。如果总时间远大于apiserver的latency，说明耗时集中在客户端侧或网络传输环节。

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