“no endpoints available”错误主因是client-go连不上API Server：集群内用rest.InClusterConfig()，本地调试须改用rest.InClusterConfig()加载kubeconfig；Pod镜像需含registry和tag，Command/Args为参数数组而非shell命令；Create()后Pending属正常，需kubectl describe查Events并轮询Status.Phase判断就绪；删Pod默认不级联，PropagationPolicy仅在Operator等特殊场景需显式设置。
用 client-go 创建 Pod 时为什么报错 “no endpoints available”？
这通常不是代码写错了，而是客户端连不上 API Server。检查 rest.InClusterConfig() 和 rest.InClusterConfig() 的使用场景是否匹配——在集群内运行要用前者，在本地调试必须用 rest.InClusterConfig() 替换为 rest.InClusterConfig() 加载 kubeconfig 文件。
常见错误操作：
- 直接在本地跑 demo 代码却硬编码
rest.InClusterConfig()，结果找不到 service account token - 用了
rest.InClusterConfig()但没挂载/var/run/secrets/kubernetes.io/serviceaccount目录（Pod 内） - kubeconfig 中 context 指向了已删除的 cluster 或 user，
kubectl get pods能用不代表 Go 客户端能用
快速验证：把 ~/.kube/config 复制到项目目录，用 rest.InClusterConfig() 加载，再打印 config.Host 看是否是预期的 API 地址。
如何用 corev1.Pod 正确设置容器镜像和启动命令？
镜像名必须完整（含 registry 地址和 tag），否则调度器拉取失败；Command 和 Args 不是 shell 命令行，而是直接传给容器 runtime 的参数数组。
立即学习“go语言免费学习笔记（深入）”；
关键点：
-
Image字段不能为空，nginx会失败，得写成nginx:1.25或registry.example.com/nginx:1.25 -
Command若不设，默认用镜像ENTRYPOINT；Args若不设，默认用镜像CMD；两者都设就完全覆盖镜像定义 - 想执行
sh -c 'sleep 30'，要写成Command: []string{"sh"}, Args: []string{"-c", "sleep 30"}
示例片段：
pod := &corev1.Pod{
ObjectMeta: metav1.ObjectMeta{Name: "demo-pod"},
Spec: corev1.PodSpec{
Containers: []corev1.Container{{
Name: "main",
Image: "alpine:3.19",
Command: []string{"sh"},
Args: []string{"-c", "echo hello && sleep 300"},
}},
},
}
为什么调用 Create() 后 Pod 状态一直是 Pending？
绝大多数情况是资源请求超限或节点污点不匹配，和 Go 代码关系不大。但容易忽略的是：client-go 默认不等待 Pod 就绪，Create() 返回后立即查状态，大概率看到的就是 Pending。
排查步骤：
- 先用
kubectl describe pod demo-pod查 Events，看有没有FailedScheduling或ImagePullBackOff - 确认 Node 是否有足够
cpu/memory：检查Resources.Requests是否超过节点可分配量 - 如果 Pod 设了
Tolerations或NodeSelector，确保目标 Node 存在且打了对应 label - 不要依赖
Create()返回值判断 Pod 是否运行——它只表示 API Server 接收成功
真正等就绪得自己轮询：Get() 拿状态，检查 pod.Status.Phase == corev1.PodRunning 且所有容器 Ready 为 true。
删除 Pod 时要不要用 PropagationPolicy？
默认行为是只删 Pod 本身，不会级联删关联的 PVC、Service 等。但如果你的 Pod 是用 Job 或 ReplicaSet 控制的，删 Pod 后控制器可能立刻新建一个——这不是 client-go 的问题，是 Kubernetes 控制器的行为。
需要显式控制传播策略的场景：
- 删 Deployment 下的某个 Pod 实例，又不想触发重建：加
PropagationPolicy: metav1.DeletePropagationBackground不够，得先缩容 Deployment 或临时停 controller - 删 Pod 同时删绑定的 PVC（非常规操作）：需手动
Delete()PVC，不能靠PropagationPolicy自动完成 - 后台删除（
DeletePropagationBackground）比前台（Foreground）快，但不保证依赖对象已清理完毕
最安全的删法：
deletePolicy := metav1.DeletePropagationBackground
options := &metav1.DeleteOptions{PropagationPolicy: &deletePolicy}
err := clientset.CoreV1().Pods("default").Delete(context.TODO(), "demo-pod", *options)
注意：PropagationPolicy 对大多数用户无感，除非你正在写 Operator 或批量运维工具。
