如何使用Golang管理Kubernetes Pod资源-Golang-PHP中文网

“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等特殊场景需显式设置。

如何使用golang管理kubernetes pod资源

用 `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 的参数数组。

关键点：

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。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

排查步骤：

先用 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 或批量运维工具。