初始化client-go需据运行环境选config：本地用BuildConfigFromFlags，集群内用InClusterConfig；操作资源须匹配GroupVersion（如Deployment用AppsV1），注意命名空间、ResourceVersion和Watch重连。
直接用 client-go 操作 Kubernetes 集群资源，核心是构造正确的 RESTClient 或更常用的 Clientset，再调用对应资源的 Interface 方法。不是所有资源都走 CoreV1，CRD 和部分内置资源（如 HorizontalPodAutoscaler）需用对应 GroupVersion 的 client。
如何初始化 client-go 的 Clientset
必须提供有效的 kubeconfig（本地开发）或 service account token（集群内运行），否则会报 no Auth Provider found for name "oidc" 或 x509: certificate signed by unknown authority。
- 本地调试：用
rest.InClusterConfig()会失败，应改用clientcmd.BuildConfigFromFlags("", kubeconfigPath) - 集群内运行：必须用
rest.InClusterConfig()，且 Pod 需绑定含足够 RBAC 权限的ServiceAccount - 若 kubeconfig 含多个 context，需显式调用
clientcmd.NewDefaultClientConfigLoadingRules().Load()并指定Context
config, err := clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig")
if err != nil {
panic(err)
}
clientset, err := kubernetes.NewForConfig(config)
if err != nil {
panic(err)
}
如何操作 CoreV1 资源（如 Pod、Service）
Clientset.CoreV1() 返回的是命名空间感知的接口，List()、Create() 等方法默认操作 default 命名空间，漏传 namespace 参数会导致 NotFound 或误操作其他 NS。
- 查所有命名空间下的 Pod：用
clientset.CoreV1().Pods("").List(ctx, opts)，空字符串表示 all-namespaces - 创建 Pod：必须设置
ObjectMeta.Namespace，否则默认为default，且GenerateName和Name不能同时设 - 更新时需带
ResourceVersion，否则可能因乐观锁失败；建议先Get再改再Update
pod, err := clientset.CoreV1().Pods("myns").Create(ctx, &corev1.Pod{
ObjectMeta: metav1.ObjectMeta{Name: "test-pod"},
Spec: corev1.PodSpec{
Containers: []corev1.Container{{Name: "nginx", Image: "nginx:alpine"}},
},
}, metav1.CreateOptions{})
如何操作非 CoreV1 资源（如 Deployment、Ingress、CRD）
Deployment 属于 apps/v1，Ingress 在 1.19+ 是 networking.k8s.io/v1，CRD 则依赖其定义的 group 和 version。硬写 clientset.CoreV1() 去调 Deployment 会编译失败。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Deployment：
clientset.AppsV1().Deployments(namespace) - Ingress：
clientset.NetworkingV1().Ingresses(namespace) - CRD：
dynamicClient.Resource(schema.GroupVersionResource{Group: "...", Version: "...", Resource: "..."}).Namespace(ns) - 注意
Scale子资源（如 Deployment 的 replicas）要用ScaleClient，不是直接改 spec
Watch 机制常见卡点和内存泄漏风险
Watch 不是长连接保活的“自动重连”，而是单次流式响应；一旦连接断开（如 apiserver 重启），Watch() 返回的 watch.Interface 就失效，不手动重试会静默停止监听。
- 必须检查
err和event.Type == watch.Error，触发后重建 Watch - 忘记调用
watch.Interface.Stop()会导致 goroutine 和 channel 泄漏 - 对高频变更资源（如大量 Pod），
ResourceVersion="0"会绕过缓存直查 etcd，加重 apiserver 压力 - 推荐用
cache.NewSharedIndexInformer封装，它内置重连、本地缓存、事件分发
真正难的不是调哪个方法，而是搞清资源所属的 GroupVersion、命名空间作用域、RBAC 权限粒度，以及 Watch 生命周期管理——这些地方出错，日志里往往只显示 Forbidden 或 connection refused，没上下文很难定位。
