Go服务调用Kubernetes API超时主因是未设context.WithTimeout，所有client-go API默认无超时，必须每次调用前创建带超时的ctx并及时cancel，否则goroutine挂死；错误统一返回context.DeadlineExceeded，需用errors.Is判断。
Go 服务调用 Kubernetes API 超时，90% 是没设 context 超时，不是 client-go 有问题。
client-go List/Get 必须带 context.WithTimeout
client-go 所有 API 方法（如 clientset.CoreV1().Nodes().List）默认不设超时，底层 http.Client 会无限等待。etcd 网络抖动、apiserver 限流、证书轮换卡顿，都会让 goroutine 挂死。
- 每次调用前必须显式创建带超时的 context：
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second) - 调用完立刻执行
cancel()，否则 goroutine 和 timer 泄漏 - 绝对不要直接传
context.Background()进 clientset 方法——它永不过期 - 如果是定时任务（如每分钟巡检节点），外层再套一层更长 timeout（如 30 秒），预留重试和降级时间
超时值设多少才合理
不能拍脑袋定 5 秒或 30 秒。K8s API 延迟受集群规模、etcd 负载、网络质量影响极大。小集群可能 200ms 完成，千节点集群 List Nodes 可能到 8~10 秒。
- 首次上线建议从
15*time.Second起步，配合 Prometheus 监控client_go_request_duration_seconds分位数（重点关注 p95） - 若 p95 8s，说明 apiserver 或 etcd 已成瓶颈，该查集群本身了
- 别把超时设得比
periodSeconds（如 kube-controller-manager 的 resync period）还短，否则反复失败又重试，放大压力
错误日志里看不到 timeout，只看到 context deadline exceeded
这是最典型的误判点。很多同学 grep "timeout" 没结果，就以为没超时——其实 Go 标准库所有超时都统一返回 context deadline exceeded 错误文本，不是 net/http: request canceled 或 i/o timeout。
立即学习“go语言免费学习笔记（深入）”；
- 检查 error 是否为
errors.Is(err, context.DeadlineExceeded)，而不是字符串匹配 - 如果用了第三方日志库（如 zap），确保 error 字段完整输出，别只打
err.Error() - 线上环境建议在超时路径加 trace log：
log.Printf("k8s node list timeout after %v, opts=%+v", timeout, opts)
为什么加了 timeout 还卡住？检查 transport 层配置
context 超时只控制 client-go 请求发起后的等待，不控制 DNS 解析、TCP 建连、TLS 握手这些前置环节。如果 apiserver 地址解析慢或网络不通，context.WithTimeout 可能还没真正进 HTTP 流程就卡住了。
- 确认
rest.InClusterConfig()或rest.KubeConfig加载正确，特别是host字段是否为可用地址（比如误配成https://kubernetes.default却没配 CoreDNS） - 检查
http.Transport是否被自定义过：若设置了IdleConnTimeout=0或MaxIdleConnsPerHost=-1，可能导致连接池异常 - 临时验证手段：用
curl -v --connect-timeout 5 --max-time 10 https://<apiserver>/api/v1/nodes</apiserver>对比原生 HTTP 行为
最容易被忽略的是：超时不是孤立参数，它和 ListOptions.Limit、Watch 机制、甚至 client-go 版本的 retry logic 都耦合。比如 v0.26+ 默认启用 rate limiting，但没配 QPS/Burst 时可能触发意外退避——这时光调大 timeout 没用，得看 clientset 构造时的 rest.Config 配置。
