连不上集群主因是配置与环境不匹配：本地用clientcmd.BuildConfigFromFlags配绝对路径kubeconfig，Pod内必须用rest.InClusterConfig并确保RBAC和CA证书正确。
如何用 client-go 连上 Kubernetes 集群
连不上集群是 90% 的 Go 操作失败第一步。不是代码写错，而是配置没走通。
关键点在于 config 构建方式必须匹配运行环境：
- 本地调试：用
clientcmd.BuildConfigFromFlags("", clientcmd.RecommendedHomeFile)，确保~/.kube/config可读且当前 context 有效 - Pod 内运行（in-cluster）：用
rest.InClusterConfig()，它会自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的 token 和 ca.crt - 别混用——比如在本地硬编码 serviceaccount token 路径，或在 Pod 里还去读
~/.kube/config，都会直接 panic
常见错误信息：open /root/.kube/config: no such file or directory 或 certificate signed by unknown authority，基本都是 config 加载路径或证书链问题。
用 client-go 创建 Deployment 的最小可行代码
不是所有字段都要填，但漏掉 selector 和 template.metadata.labels 会导致 Deployment 创建成功却起不来 Pod。
立即学习“go语言免费学习笔记（深入）”；
核心约束：二者 label 必须完全一致，否则 kubectl get deploy 显示 0/3 副本，kubectl get pods 却空空如也。
示例片段（只保留必要字段）：
dep := &appsv1.Deployment{
ObjectMeta: metav1.ObjectMeta{
Name: "go-app",
},
Spec: appsv1.DeploymentSpec{
Replicas: ptr.To(int32(3)),
Selector: &metav1.LabelSelector{
MatchLabels: map[string]string{"app": "go-app"},
},
Template: corev1.PodTemplateSpec{
ObjectMeta: metav1.ObjectMeta{
Labels: map[string]string{"app": "go-app"},
},
Spec: corev1.PodSpec{
Containers: []corev1.Container{{
Name: "go-app",
Image: "your-registry/go-app:v1.0",
Ports: []corev1.ContainerPort{{ContainerPort: 8080}},
}},
},
},
},
}
_, err := clientset.AppsV1().Deployments("default").Create(ctx, dep, metav1.CreateOptions{})
注意：ptr.To() 是 Go 1.21+ 推荐写法，避免手动取地址；旧版本需写 &[]int32{3}[0] 或用 int32Ptr 工具函数。
为什么 List Pods 总是返回空列表
不是 API 调用失败，而是默认只查 default 命名空间，且没传任何过滤条件。
常见误操作：
- 调用
clientset.CoreV1().Pods("").List(...)—— 空字符串命名空间不合法，会报错 - 忘记加
metav1.ListOptions{FieldSelector: "status.phase=Running"}，导致返回大量 Terminating/Pending 状态的“幽灵 Pod” - 权限不足：ServiceAccount 没绑定
pod-readerClusterRole，返回Forbidden但错误信息藏在err.Error()里，容易被忽略
快速验证方式：先用 kubectl get pods -A 确认目标 Pod 存在，再用相同命名空间重试 Go 代码。
Operator 场景下 Reconcile 函数最常踩的坑
Reconcile 不是“执行一次就完事”，它会被反复触发。逻辑里如果没做幂等处理，可能重复创建资源、反复打日志、甚至把数据库连爆。
典型问题点：
- 没检查资源是否已存在：每次 reconcile 都
Create()Deployment，结果集群里堆满同名但 UID 不同的 Deployment - 用
Get()失败就直接Create()，但没处理IsNotFound(err)，导致其他错误（如权限拒绝）也被当成“不存在”来创建 - 更新时直接
Update()整个对象，没做 deep copy 或没保留ResourceVersion，触发冲突错误the object has been modified; please apply your changes to the latest version and try again
真正安全的做法：先 Get，存在则 Update（带原 ResourceVersion），不存在才 Create；所有 error 都显式判断类型，不靠 != nil 糊弄过去。
复杂点永远在状态比对和并发控制上——Kubernetes 不保证事件顺序，两个 reconcile 可能同时跑，靠 client-go 自带的 workqueue 做不了最终一致性，得自己加锁或用 patch 语义。
