client-go是连接Kubernetes集群的官方推荐方式，需正确初始化rest.Config、区分资源作用域、使用Reflector处理Watch、严格配置RBAC权限。
用 client-go 连 Kubernetes 集群是最直接的方式
官方推荐、维护活跃、兼容性有保障，几乎所有生产级 Go 项目都基于它封装。别自己拼 HTTP 请求或调 kubectl 命令——容易漏认证逻辑、不处理重试、无法复用 Informer 机制。
关键点是初始化 rest.Config：本地开发通常用 rest.InClusterConfig()（Pod 内）或 rest.InClusterConfig()（本地 kubectl config），别硬写 API 地址和 token。
- Pod 内运行：直接调
rest.InClusterConfig()，它会自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的 token 和 ca.crt - 本地调试：用
rest.InClusterConfig()会失败，改用rest.InClusterConfig()——但注意：它依赖KUBECONFIG环境变量或默认路径~/.kube/config，且要求该 config 中用户凭证可用（比如用kubectl auth can-i验证权限） - 若 config 里用了 exec 插件（如 aws-iam-authenticator、gke-gcloud-auth-plugin），
client-go默认不支持，得提前用kubectl拿到长期有效的 token 再塞进config.BearerToken
调 Get / List 时注意 namespace 和资源 scope
不是所有资源都分 namespace。例如 Node、ClusterRole、StorageClass 是集群级（cluster-scoped），必须用 clientset.CoreV1().Nodes().Get() 这类无 namespace 参数的方法；而 Pod、ConfigMap 是命名空间级（namespaced），调 clientset.CoreV1().Pods("default").Get() 才对。
错用会导致 404 或 403：比如对 Node 传入 namespace，API server 直接拒绝；对 Pod 不传 namespace，则默认查 “default”，可能返回空或权限错误。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 查资源 scope 最快方式：执行
kubectl api-resources --namespaced=true或false - 代码里可统一用动态客户端
dynamic.Client绕过类型绑定，但失去编译期检查，适合泛化操作 -
List默认只返回当前页（limit=500），大数据量要手动处理Continuetoken，否则漏数据
Watch 资源变化必须用 Reflector + DeltaFIFO 模式
别用 clientset.CoreV1().Pods("default").Watch() 后自己循环读 watch.Event ——这容易卡住、丢事件、不重连。正确做法是交给 cache.NewListWatchFromClient 构建 cache.ListerWatcher，再喂给 cache.NewReflector。
Reflector 自动处理连接断开、重试、resourceVersion 同步、全量兜底 List，这才是稳定监听的基础。自己手写 Watch 循环在高负载或网络抖动下几乎必然出问题。
- resourceVersion=0 表示从最新状态开始，但 watch 必须 >0，Reflector 会自动用上次 List 结果里的
metadata.resourceVersion启动 - 不要在
watch.Event回调里做耗时操作（如 HTTP 请求、DB 写入），应发到 worker channel 异步处理 - Informer 的
AddFunc/UpdateFunc触发时机是事件入队后，非实时；若需严格顺序，得自己加锁或用workqueue.RateLimitingInterface
RBAC 权限不足时常见错误是 Forbidden 而非 NotFound
比如用 ServiceAccount 调 Pods().List() 却没配对应 RoleBinding，Kubernetes 返回的是 403 Forbidden，错误信息里带 cannot list resource "pods"，而不是 404。新手常误以为资源不存在或 API 路径错了。
验证权限最快方法：用相同 ServiceAccount 执行 kubectl auth can-i list pods -n default。如果返回 no，就该检查 Role/ClusterRole 的 rules 是否覆盖了动词（list、get、watch）、资源（pods）、API 组（"" 表示 core group，apps 表示 apps/v1）。
- ServiceAccount 默认挂载的 token 权限极低，必须显式绑定 RoleBinding
- 用
impersonate时，被模拟用户的权限决定最终结果，且要求当前用户有impersonate权限 - API server 日志里搜
RBAC DENY能看到具体哪条 rule 拦截了请求
