报错“no kind is registered for the type v1.Pod”是因未正确初始化scheme或clientset，需导入k8s.io/client-go/kubernetes（旧版）或k8s.io/client-go/objects/v1（v0.28+）以自动注册v1类型，禁用手动new runtime.Scheme。
用 client-go 创建 Pod 时为什么报错 “no kind is registered for the type v1.Pod”？
这是 client-go 版本与 API group/kind 注册不匹配的典型表现，常见于未正确初始化 scheme 或用了错误的 clientset。
必须显式注册核心资源类型，否则 clientset.CoreV1().Pods(namespace) 虽能编译通过，但序列化/反序列化会失败。
- 确保导入了
"k8s.io/client-go/objects/v1"（v0.28+）或"k8s.io/client-go/kubernetes"（旧版），它会自动触发v1.AddToScheme(scheme.Scheme) - 不要手动 new 一个空
runtime.Scheme；优先用clientgoscheme.Scheme（v0.26+）或scheme.Scheme（旧版） - 若自定义 scheme，需调用
corev1.AddToScheme(scheme)，且顺序不能颠倒（先 add 再 new client）
如何用 Golang 动态 patch Deployment 的 image 字段？
直接改 Deployment.Spec.Template.Spec.Containers[0].Image 并 Update() 是最简单方式，但有风险：可能覆盖他人并发修改。生产环境推荐使用 server-side apply 或 strategic merge patch。
更安全的做法是用 Patch() 配合 types.StrategicMergePatchType：
立即学习“go语言免费学习笔记（深入）”；
patchData, _ := json.Marshal(map[string]interface{}{
"spec": map[string]interface{}{
"template": map[string]interface{}{
"spec": map[string]interface{}{
"containers": []map[string]interface{}{{
"name": "myapp",
"image": "nginx:1.25",
}},
},
},
},
})
_, err := clientset.AppsV1().Deployments("default").Patch(
context.TODO(),
"my-deploy",
types.StrategicMergePatchType,
patchData,
metav1.PatchOptions{},
)
- 注意容器
name必须与原 manifest 中一致，否则 patch 会新增容器而非替换 - 使用
types.MergePatchType时，需提供完整容器对象，否则字段会被清空 - server-side apply（
Apply()）在 v1.22+ 更推荐，但需启用ServerSideApplyfeature gate
为什么 List() 返回空列表，但 kubectl get 看得到资源？
最常见的原因是 namespace 错误或 RBAC 权限不足 —— client-go 不会报“forbidden”，而常静默返回空列表 + nil error。
- 检查
clientset.CoreV1().Pods("myns").List()中的 namespace 是否拼写正确；用空字符串""表示全部 namespace 仅对 cluster-scoped 资源有效（如 Node），对 namespaced 资源（Pod/Deployment）必须指定 - 确认 ServiceAccount 已绑定含
list权限的 Role/ClusterRole，且 RoleBinding 的namespace字段与 client 查询的 namespace 一致 - 加一句
log.Printf("got %d items", len(list.Items))，再配合kubectl auth can-i list pods -n myns --as=system:serviceaccount:myns:mysa验证权限
用 Informer 监听 Pod 变化时，为什么 OnAdd/OnUpdate 不触发？
Informer 启动后默认只同步一次全量快照，后续事件是否触发取决于 resyncPeriod 和是否成功建立 watch 连接。很多问题出在初始化流程没走完。
- 必须调用
informer.Run(stopCh)启动，且stopCh不能是已关闭的 channel - 在
informer.HasSynced()返回 true 前，不应假设缓存已就绪；建议用cache.WaitForNamedCacheSync("pod-informer", stopCh, informer.HasSynced) - 若集群启用了
WatchCache（默认开启），但 watch event 被丢弃（如网络抖动、apiserver 重启），Informer 会自动 resync，但中间变更可能丢失 —— 关键业务应结合 UID 或 resourceVersion 做幂等校验
