直接用client-go写管理工具可行，但须避开单例配置、跨集群复用client、忽略transport隔离三类高频错误；多集群必须弃用rest.InClusterConfig，改用clientcmd.BuildConfigFromFlags或手动构造rest.Config，并为每个集群独占独立Config、Transport和Clientset，显式设置QPS/Burst。
直接用 client-go 写管理工具是可行的，但必须避开单例配置、跨集群复用 client、忽略 transport 隔离这三类高频翻车点。
为什么不能直接用 rest.InClusterConfig 管理多个集群
rest.InClusterConfig() 只读 /var/run/secrets/kubernetes.io/serviceaccount/ 下的 token 和 ca.crt，硬绑定当前 Pod 所在集群。哪怕你传入不同 namespace 或伪造 context，它返回的 *rest.Config 仍指向本集群 API server。
- 误用表现：代码里调了两次
rest.InClusterConfig()，却以为能分别连 A 集群和 B 集群 —— 实际全连到本集群 - 正确做法：多集群场景下彻底弃用
rest.InClusterConfig()，改用clientcmd.BuildConfigFromFlags()或手动构造rest.Config - 注意 base64 解码：
certificate-authority-data字段需用base64.StdEncoding.DecodeString()解码后赋给TLSClientConfig.CAData
如何安全地并发操作多个 Kubernetes 集群
关键不是加锁，而是每个集群独占一套底层资源：独立的 rest.Config、独立的 http.Transport、独立的 Clientset 实例。
- 必须为每个 client 设置显式 QPS/Burst，例如
config.QPS = 5.0、config.Burst = 10，否则默认值（5/10）在轮询多个集群时可能压垮某个 API server - transport 层要隔离：不复用全局
http.DefaultTransport，而是为每个 client 构造专属&http.Transport{...} - 封装建议：定义
type ClusterClient struct { Clientset *kubernetes.Clientset Config *rest.Config }，避免裸露 config 或 clientset
StatefulSet 管理中容易被忽略的字段细节
创建或更新 v1.StatefulSet 时，ServiceName 和 PodManagementPolicy 这两个字段不写会出问题，但报错不明显。
立即学习“go语言免费学习笔记（深入）”；
-
ServiceName必须非空且指向一个已存在的Service，否则 StatefulSet 控制器拒绝创建 Pod，日志只显示failed to get headless service -
PodManagementPolicy默认是OrderedReady，若想并行启动所有副本（如批量初始化场景），得显式设为Parallel -
RevisionHistoryLimit默认为 10，但生产环境建议设为 2～3，避免旧 ReplicaSet 占用过多 etcd 存储
Ingress v1 版本里 Annotation 的坑
用 networkingv1.Ingress 时，IngressClassName 是字段，不是 annotation；而像 nginx.ingress.kubernetes.io/rewrite-target 这类控制器特有行为，仍必须走 Annotations。
- 常见错误：把
IngressClassName写进 annotations，导致 Ingress 不被任何控制器处理，状态卡在None - 正确写法：
IngressClassName: &[]string{"nginx"}[0]（注意取地址）或更稳妥的strPtr("nginx")辅助函数 - 兼容性注意：Kubernetes 1.19+ 才正式 GA
networkingv1，低于此版本需降级用networkingv1beta1，字段名和结构有差异
真正难的不是写对第一个 StatefulSet 创建逻辑，而是后续所有资源清理、版本回滚、PVC 生命周期绑定、以及跨集群权限收敛这些隐性路径 —— 它们不会在第一次 go run main.go 时报错，但会在半夜告警里突然浮现。
