不安全，应禁用个人kubeconfig凭据；集群内用ServiceAccount+InClusterConfig自动加载token，集群外用Workload Identity绑定GCP服务账号获取短期OAuth2令牌。
直接用 ~/.kube/config 里的个人凭据去调用 Kubernetes API，在生产环境（尤其是 GKE）中是不安全的，也容易失效——它缺乏最小权限、不可审计、无法自动轮换，且在集群外长期暴露 token 风险极高。
集群内访问：必须用 rest.InClusterConfig()
Pod 内运行的应用（如 Operator、监控采集器）应完全跳过 kubeconfig，依赖 Kubernetes 自动挂载的 ServiceAccount 凭据：
-
rest.InClusterConfig()会自动读取/var/run/secrets/kubernetes.io/serviceaccount/token和ca.crt，无需硬编码路径或解析文件 - 确保 Pod 的
serviceAccountName显式指定，且该 ServiceAccount 已通过RoleBinding或ClusterRoleBinding绑定最小必要权限 - 若容器以非 root 用户运行，需确认挂载目录有读权限；否则会报错：
open /var/run/secrets/kubernetes.io/serviceaccount/token: permission denied - GKE v1.24+ 默认启用 TokenRequest API，token 有效期为 1 小时；不要缓存或日志输出该 token 内容
集群外访问：别碰静态 token，走 Google IAM + Workload Identity
本地开发、Cloud Functions 或跨集群管理工具等场景，绝不能导出个人 kubeconfig 或生成长期 bearer token。GKE 不支持手动签发客户端证书，也不开放 --token-auth-file 等参数：
- 正确路径是启用 Workload Identity：将 GCP Service Account（GSA）绑定到 Kubernetes ServiceAccount（KSA），让外部应用用短期 OAuth2 token 访问 API
- 调用前需先用
gcloud auth application-default login或 workload identity federation 获取 access token，再注入Authorization: Bearer <token></token>请求头 - 避免用
clientcmd.BuildConfigFromFlags("", "./kubeconfig")——相对路径在容器中必然失败；绝对路径又难维护，且含长期凭证 - 若临时调试必须用 kubeconfig，请确保其仅含
exec插件（如gke-gcloud-auth-plugin），而非静态user.token
Go 客户端初始化常见坑：QPS、错误处理与版本对齐
即使认证正确，client-go 默认配置也会导致 429 Too Many Requests 或 watch 断连后不重试：
立即学习“go语言免费学习笔记（深入）”；
- 必须显式设置
Config.QPS = 20和Config.Burst = 30，否则默认5/10在中等规模集群极易被限流 - Watch 操作不能裸用
ResultChan()；必须监听ctx.Done()并手动重试，否则网络抖动即永久中断 - 永远用
kubernetes.NewForConfig(config)获取完整Clientset，不要直接调corev1.NewForConfig()——后者可能因 client-go 版本升级缺失字段或 panic - 若用
controller-runtime，它已封装了 Informer 重连逻辑和 Leader Election，但只在需要响应 CRD 或修改资源时才引入，纯读取用client-go更轻量
最易被忽略的一点：所有基于 ServiceAccount 的访问都依赖 RBAC 绑定是否生效——kubectl auth can-i --list 是唯一可信验证方式，别靠“没报错”就认为权限够用。
