必须用rest.InClusterConfig()（Pod内）或clientcmd.BuildConfigFromFlags()（本地），不可混用；需显式设置QPS、Burst、Timeout和TLS配置，缺一不可。
用 rest.InClusterConfig 还是 rest.InClusterConfig？先看运行环境
在 Pod 里跑的 Go 程序，必须用 rest.InClusterConfig()；本地调试或非集群环境，得用 rest.InClusterConfig() 加上 kubeconfig 文件路径。硬编码 ~/.kube/config 或默认路径容易失败——os.Getenv("KUBECONFIG") 才是正确入口。
- Pod 内：直接调
rest.InClusterConfig()，它会读取/var/run/secrets/kubernetes.io/serviceaccount/下的 token 和 ca.crt - 本地开发：用
clientcmd.BuildConfigFromFlags("", kubeconfigPath)，其中kubeconfigPath应来自环境变量或命令行参数，别写死 - 如果
rest.InClusterConfig()返回no such file or directory，说明当前不在集群内，别强行 fallback，应明确报错或切换逻辑
rest.Config 创建后必须设置 QPS 和 Burst
默认配置下客户端会无节制发请求，触发 API Server 的限流（HTTP 429），尤其在 List+Watch 场景下极易复现。不设 QPS 不是“省事”，是埋雷。
- 生产环境建议设
QPS: 5.0、Burst: 10；CI 或低频工具可放宽到QPS: 20.0、Burst: 30 - 务必在传给
kubernetes.NewForConfig()前赋值：cfg.QPS = 5.0; cfg.Burst = 10 - 注意：修改
cfg是指针操作，多个 client 共享同一rest.Config时，QPS 设置会被覆盖——每个 client 应用独立 config 实例
用 kubernetes.Clientset 还是按需构造 dynamic.Client？
如果你只操作 Pod、Service、Deployment 这类核心资源，kubernetes.Clientset 最直接；但遇到 CRD、非标准 GroupVersion，或想写通用资源操作器，必须切到 dynamic.Interface。
-
Clientset优点：类型安全、IDE 支持好、方法链清晰，比如clientset.CoreV1().Pods("ns").List() -
dynamic.Client需手动构造schema.GroupVersionResource，例如 CRDmyapps.example.com/v1, Resource=applications必须显式指定GVR - 别混用：一个 client 同时依赖
Clientset和dynamic.Client会导致重复初始化 transport，增加内存与连接开销
超时和 TLS 配置经常被忽略的三个点
rest.Config 默认不设 Timeout，底层 http.Transport 也未限制 idle 连接，长期运行的服务容易堆积 stale connection，最终卡住请求。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式设
cfg.Timeout = 30 * time.Second，避免单个请求无限 hang 住 goroutine - 若用自签名证书或私有 CA，别只改
CAFile；要同步设cfg.TLSClientConfig.Insecure = false（默认已是 false，但显式写出来防误） - 集群内访问
https://kubernetes.default.svc时，cfg.Host必须带协议和端口（如https://kubernetes.default.svc:443），否则可能 fallback 到 http 或解析失败
实际初始化 client 的最小可靠片段里，QPS、Timeout、CAFile、运行环境判断这四件事缺一不可。少一个，上线后就可能表现为偶发 429、context deadline exceeded 或 x509 certificate signed by unknown authority。
