应按运行场景选择认证方式：Pod内用rest.InClusterConfig()自动读取ServiceAccount凭证，本地开发用clientcmd.BuildConfigFromFlags()且kubeconfig路径须为绝对路径；监听Endpoints而非Service以获取真实后端IP列表，并用Informer替代轮询实现可靠服务发现。
能连上 Kubernetes API，不代表服务发现就可靠；多数 Golang 项目卡在认证配置和 Endpoints 监听这两步。
怎么选对 client-go 的认证方式
Pod 内运行和本地调试必须用不同配置，硬编码或路径写错直接 401 Unauthorized 或 x509: certificate signed by unknown authority。别猜，按场景走：
- 在 Kubernetes Pod 里跑：只用
rest.InClusterConfig()，它自动读/var/run/secrets/kubernetes.io/serviceaccount/下的token和ca.crt - 本地开发或 CI 环境：用
clientcmd.BuildConfigFromFlags("", "/absolute/path/to/kubeconfig")，第二个参数必须是绝对路径，"./kubeconfig"在容器里基本失效 - 千万别设
InsecureSkipVerify: true—— 这不是“方便”，是绕过 TLS 校验，K8s 默认不接受 HTTP，中间人风险拉满 - QPS 默认是 5，高频率 List/Watch 容易被 apiserver 限流，建议显式设
Config.QPS = 20、Config.Burst = 30
为什么监听 Service 不如监听 Endpoints
Service 是抽象规则，真正含 IP+Port 列表的是 Endpoints 对象。监听 Service 只能知道规则变了，但不知道后端实例增删——服务发现就断了。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 用
corev1.SchemeGroupVersion.WithResource("endpoints")启 Watch，不是corev1.SchemeGroupVersion.WithResource("services") - 若 Service 是 headless（
clusterIP: None），Endpoints会包含所有匹配 Pod 的地址，这才是你要的真实后端列表 -
Endpoints.Subsets可能为空（比如所有 Pod 都未就绪），不能直接 panic，得清空本地缓存并触发下游重试逻辑 - 别用轮询
List()—— 高频请求压垮 apiserver，且可能错过瞬时变更；Informer 才是标准做法
Informer 同步完成 ≠ 缓存已就绪
informer.HasSynced() 返回 true 只表示 list + watch 流程启动成功，不代表所有对象都已写入本地缓存。首次 OnAdd 触发前，部分 Endpoints 可能还没进缓存。
立即学习“go语言免费学习笔记（深入）”；
- 别在
HasSynced()后立刻读缓存做服务发现，容易漏实例 - 正确做法：等
informer.GetStore().List()返回非空且长度稳定，再开始消费 - 注册
cache.ResourceEventHandler时，OnAdd回调要能处理重复或乱序事件，ResourceVersion是判断更新顺序的关键依据 - 如果用
cache.NewInformer，确保resyncPeriod设为 0（禁用 resync）或足够长（比如 5 分钟），避免频繁全量刷新干扰增量更新
最常被跳过的细节是：headless Service 必须手动创建，且 Endpoints 要靠你代码维护 —— K8s 不自动填，除非 Service 有 selector 且匹配到 Pod。没 selector 的 headless Service，Endpoints 就是空的，Informer 也收不到变化。
