必须根据运行环境选择配置方式：pod内用rest.inclusterconfig()读serviceaccount凭证，集群外用clientcmd.buildconfigfromflags()加载kubeconfig；且务必在newforconfig前设置qps、burst、timeout及tls参数，避免429错误和连接泄漏。
Go 语言配置 Kubernetes 客户端不是“选一个函数调用就行”，而是必须根据运行环境（集群内 or 集群外）走不同路径，且 rest.Config 创建后不设 QPS/Burst/Timeout 就等于默认开启限流失败开关。
怎么判断该用 rest.InClusterConfig 还是 clientcmd.BuildConfigFromFlags
关键看程序在哪跑：
- 在 Pod 里运行：必须用
rest.InClusterConfig()，它会自动读/var/run/secrets/kubernetes.io/serviceaccount/下的token和ca.crt - 本地开发、CI 脚本、外部服务：必须用
clientcmd.BuildConfigFromFlags("", kubeconfigPath)，其中kubeconfigPath应来自os.Getenv("KUBECONFIG")或命令行参数——硬编码"~/.kube/config"或拼接homedir.HomeDir()在容器或非标准环境大概率失败 -
rest.InClusterConfig()返回no such file or directory？说明当前根本不在集群 Pod 里，别写 fallback 逻辑自动切到本地配置，这会让错误更难定位；应该明确报错并退出，或由上层控制流程分支
为什么 cfg.QPS = 5.0; cfg.Burst = 10 是必填项，不是可选项
默认 rest.Config 的 QPS 是 0（不限速），Burst 是 0（无突发容量），实际效果是客户端疯狂发请求，API Server 一概返回 HTTP 429 Too Many Requests，尤其在 List+Watch 场景下秒级复现。
- 生产环境建议设
cfg.QPS = 5.0、cfg.Burst = 10；CI 或低频工具可放宽至QPS = 20.0、Burst = 30 - 必须在传给
kubernetes.NewForConfig()前赋值，顺序错了等于没设 -
cfg是指针，多个 client 共享同一rest.Config实例时，QPS设置会被覆盖——每个 client 应基于独立 config 实例初始化
超时和 TLS 配置最容易被跳过的三件事
rest.Config 默认不设 Timeout，底层 http.Transport 也不限制 idle 连接，长期运行的服务会堆积 stale connection，最终卡住 goroutine。
- 务必显式设
cfg.Timeout = 30 * time.Second，避免单个请求无限 hang 住 - 若用自签名证书或私有 CA，不能只改
cfg.CAFile；还要同步设cfg.TLSClientConfig.Insecure = false（禁用证书校验时才设true），并确保cfg.TLSClientConfig.CAData或CAFile可读 - 长期运行的服务（如 operator）要额外配置
http.Transport.MaxIdleConns和MaxIdleConnsPerHost，否则连接池膨胀会导致 DNS 缓存失效或连接拒绝
最常被忽略的复杂点是：同一个二进制既要支持集群内运行又要支持本地调试时，不能靠“自动探测”混用两种 config 初始化方式——环境差异会导致认证失败、证书路径错乱、QPS 覆盖等连锁问题。正确做法是启动时通过 flag 或 env 明确指定模式，并各自走完整初始化链路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
