rest.InClusterConfig()用于Pod内自动读取ServiceAccount挂载的token、ca.crt和API地址（https://kubernetes.default.svc），失败主因是未绑定SA或RBAC权限不足，错误为“no such file or directory”而非401。
用 rest.InClusterConfig() 读取集群内 Pod 的 kubeconfig
在 Kubernetes 集群内部运行的 Go 程序（比如 Operator 或 sidecar），默认不依赖本地 ~/.kube/config，而是通过 ServiceAccount 自动挂载的 Token 和 CA 证书来构建 client 配置。核心就是 rest.InClusterConfig()。
它会自动读取三个关键路径：
/var/run/secrets/kubernetes.io/serviceaccount/token/var/run/secrets/kubernetes.io/serviceaccount/ca.crt-
https://kubernetes.default.svc（固定 API server 地址）
调用失败通常是因为容器没绑定 ServiceAccount，或该 SA 没被授予对应 RBAC 权限——此时 rest.InClusterConfig() 会返回 no such file or directory 错误，而不是权限拒绝。
示例片段：
立即学习“go语言免费学习笔记（深入）”；
cfg, err := rest.InClusterConfig()
if err != nil {
log.Fatal(err) // 注意：这里 err 不是 "forbidden"，而是文件读取失败
}
clientset, err := kubernetes.NewForConfig(cfg)
用 clientcmd.BuildConfigFromFlags() 读取本地或挂载的 kubeconfig 文件
开发调试、CI 脚本或非集群内运行的 Go 程序，一般走标准 kubeconfig 文件路径。别硬编码 ~/.kube/config，应支持命令行参数或环境变量控制。
clientcmd.BuildConfigFromFlags() 是最常用入口，它接受两个参数：master URL（可空）和 kubeconfig 文件路径。空 master 表示从 config 文件里读；空路径则 fallback 到 $HOME/.kube/config。
常见坑：
- 传入空字符串
""当作路径，会导致读取失败（不是 fallback）；必须传nil或留空 flag - 如果 kubeconfig 中 context 使用了
exec插件（如 aws-iam-authenticator），Go client 默认不执行它，会报exec plugin: invalid apiVersion—— 需要显式启用rest.SetExecCredentialPluginEnvVar()并确保插件二进制在$PATH - Windows 下路径分隔符错误（比如硬写
"C:\Users\me\.kube\config"）易引发解析失败，建议用filepath.Join()
如何安全处理多集群配置（rest.Config 复用与隔离）
一个进程里同时操作多个集群时，不能复用同一个 *rest.Config 实例：它内部包含共享的 transport、token refresh 逻辑和 TLS 设置，混用会导致认证冲突或连接复用异常。
正确做法是为每个集群构造独立的 *rest.Config，并注意以下细节：
- 对每个 config 显式调用
rest.CopyConfig()再修改，避免浅拷贝导致字段污染 - 若需自定义 transport（如加 trace、超时），应在调用
rest.RESTClientFor()前设置Config.Transport，而不是改 clientset 自身 - 使用
rest.AnonymousClientConfig()获取无认证 config（例如访问 metrics-server 的 /metrics 端点），但注意它仍继承 CA 和 host，只是去掉 token/Bearer
典型错误是把一个 config 传给多个 clientset.NewForConfig() 后又并发修改其 BearerToken 字段——这会破坏所有 client 的请求头。
遇到 x509: certificate signed by unknown authority 怎么办
这个错误几乎只出现在两种场景：一是用了自签名 CA 的私有集群，二是 kubeconfig 里 certificate-authority-data 被截断或 Base64 解码失败。
排查步骤：
- 先确认 config 文件中
clusters[0].cluster.certificate-authority-data是完整 Base64 字符串（无换行、无空格），可用base64 -d手动解码验证是否输出 PEM 格式证书 - 若用
rest.InClusterConfig()，检查挂载的ca.crt是否真实存在且可读（ls -l /var/run/secrets/...） - 临时绕过校验（仅测试！）：设置
Config.InsecureSkipTLSVerify = true，但生产环境必须修复 CA 来源 - 某些 K3s/KinD 集群默认用
localhost:6443作为 server 地址，而客户端 DNS 解析不到，需改用127.0.0.1:6443并确保 CA 匹配该 IP 的证书 SAN
CA 问题往往藏得深：比如 config 文件里写了 certificate-authority: /some/path/ca.crt，但程序运行时该路径不存在或权限不足，Go client 不报错，而是静默 fallback 到系统根证书——结果连不上私有集群。
