最简可行路径是：构建Clientset→构造含Namespace、GenerateName/Name、非空Containers切片及RestartPolicy的v1.Pod→调用clientset.CoreV1().Pods(ns).Create()。必须显式设Namespace和Containers，Name需符合DNS-1123规范，私有镜像需配置ImagePullSecrets。
用 client-go 创建 Pod 最简可行路径
直接写代码创建 Pod，核心就是调用 client-go 的 Create() 方法，传入符合 v1.Pod 结构的实例。不走 YAML 文件解析、不依赖 kubectl 命令行，纯 Go 控制面操作。
关键前提是：你已有可用的 *kubernetes.Clientset 实例（通常通过 rest.InClusterConfig() 或 clientcmd.BuildConfigFromFlags() 构建），且 RBAC 允许对 pods 资源执行 create 操作。
-
Pod必须指定Namespace，空字符串或未设会导致Invalid value: "": a DNS-1123 subdomain must consist of lower case alphanumeric characters... -
Metadata.Name不能含大写字母、下划线或特殊符号，只支持小写字母、数字、连字符，且必须以字母或数字开头结尾 - 容器镜像若为私有仓库，需提前在对应 Namespace 中创建
Secret并在Pod.Spec.ImagePullSecrets中引用，否则卡在ImagePullBackOff
v1.Pod 中哪些字段不能省略
API Server 对 Pod 对象有硬性校验，以下字段缺失会直接返回 422 Unprocessable Entity 错误：
-
ObjectMeta.Namespace：即使想创建在default，也得显式写"default" -
ObjectMeta.GenerateName或ObjectMeta.Name：二者至少填一个；用GenerateName会让 API 自动生成带随机后缀的名字（推荐用于临时 Pod） -
Spec.Containers：长度必须 ≥ 1，且每个Container至少要有Name和Image -
Spec.RestartPolicy：如果不设，默认是"Always"，但该值仅对ReplicationController等控制器有效；独立 Pod 推荐显式设为"Never"或"OnFailure"，避免意外重启掩盖问题
示例片段：
立即学习“go语言免费学习笔记（深入）”；
pod := &corev1.Pod{
ObjectMeta: metav1.ObjectMeta{
GenerateName: "demo-pod-",
Namespace: "default",
},
Spec: corev1.PodSpec{
Containers: []corev1.Container{{
Name: "main",
Image: "nginx:1.25",
}},
RestartPolicy: corev1.RestartPolicyNever,
},
}
创建失败时最常遇到的错误信息和定位方法
调用 clientset.CoreV1().Pods(ns).Create(ctx, pod, opts) 后若返回 error，不要只看 err.Error() —— 它往往只是 “Operation cannot be fulfilled…” 这类泛化提示。真正有用的信息藏在 apierrors.ReasonForError(err) 和原始响应体里。
-
StatusReasonForbidden：RBAC 权限不足，检查 ServiceAccount 绑定的 Role 是否含resources: ["pods"], verbs: ["create"] -
StatusReasonInvalid：字段校验失败，打印err.(*errors.StatusError).ErrStatus.Details.Causes可看到具体哪一字段不合法（比如field: metadata.name, reason: Invalid value） -
StatusReasonServerTimeout：APIServer 响应超时，常见于集群负载高或网络延迟大；建议给ctx加上context.WithTimeout，并捕获重试逻辑 - 如果 Pod 长时间处于
Pending，用kubectl describe pod <name></name>查Events区域，比 Go 日志更直接 —— Go client 不自动拉取事件
为什么不用 Apply 而坚持用 Create
client-go 没有原生 Apply 方法（那是 kubectl apply 的封装逻辑）。如果你用 Update 或 Patch 去“更新”一个不存在的 Pod，会报 NotFound；而 Create 是幂等性最弱的操作 —— 同名 Pod 已存在就直接报错。
- 要实现类似
kubectl apply的行为，得自己先Get判断是否存在，再决定Create或Update，还要处理ResourceVersion冲突 - 对一次性调试 Pod、CI 中临时 Job Pod，
Create+GenerateName是最干净的做法，避免残留旧对象干扰 - 若真需要声明式更新，建议直接调用
kubectl apply -f -通过exec.Command，或者引入sigs.k8s.io/cli-utils/pkg/kstatus/polling等辅助库，别硬造轮子
实际编码中，Create 的调用链很短，但背后的权限、命名、镜像拉取、调度约束任何一个环节断掉，都会让 Pod 卡住不动 —— 它不像本地进程那样能立刻看到 panic，得习惯查 kubectl get events -n <ns></ns> 和 describe。
