必须显式初始化pod.spec.containers且不能为空切片，pod.objectmeta.name需全小写数字短横线、≤63字符，containers[0].name不可为空，restartpolicy按需设为onfailure或never；client-go初始化须用inclusterconfig（pod内）或buildconfigfromflags（本地），并配置qps、burst和timeout；创建后需主动轮询get检查status.phase=="running"及ready=true条件。
必须显式初始化 Pod.Spec.Containers，否则 API Server 直接拒绝创建请求。
怎么填满 corev1.Pod 的必填字段
Go 里 corev1.Pod 看似结构简单，但漏掉几个字段会直接报 Invalid 错误，不是 panic，是 HTTP 422 响应体里明确告诉你缺啥。
-
Pod.ObjectMeta.Name必须全小写、数字、短横线，长度 ≤63；用rand.String(10)生成比硬编码安全 -
Pod.Spec.Containers是切片，不能为空（nil）也不能为零长（[]）；哪怕只启一个容器，也得写[]corev1.Container{{...}} -
Pod.Spec.Containers[0].Name不能为空字符串——API Server 会返回name must be non-empty -
Pod.Spec.RestartPolicy默认是Always，但单次运行的 Pod 应设为OnFailure或Never，否则可能被 kubelet 反复拉起
为什么 clientset.CoreV1().Pods(ns).Create() 总是 panic 或 401
不是代码写错了，是 client-go 初始化没到位。常见原因有三个：
- 没正确加载
rest.Config：Pod 内必须用rest.InClusterConfig()，本地调试必须用clientcmd.BuildConfigFromFlags("", os.Getenv("KUBECONFIG"))；硬编码"~/.kube/config"在 CI 或容器里大概率失败 - 没设
cfg.QPS和cfg.Burst：默认值是 0，会导致限流触发（HTTP 429），尤其在批量创建时 - 没设
cfg.Timeout：底层 http.Transport 没超时控制，某个卡住的请求会让整个 goroutine hang 死
创建后怎么确认 Pod 真跑起来了
Create() 只是把对象提交给 API Server，不等于调度完成、容器启动、就绪探针通过。要确认真实状态，得主动轮询：
- 用
clientset.CoreV1().Pods(ns).Get()拿最新对象，检查Status.Phase == "Running"且Status.Conditions中有Ready=True - 别依赖
Status.ContainerStatuses[0].Ready就完事——它可能为 true，但 liveness probe 还没通过，应用实际不可用 - 如果要等 Pod 完全就绪，推荐用
wait.PollImmediate(2*time.Second, 60*time.Second, isPodReady(clientset, ns, name))，自己写isPodReady函数判断条件
最常被跳过的细节是：Pod 创建成功后，Status 字段初始为空或不完整，需要主动 Get 刷新；没人帮你轮询，client-go 不是魔法，它只是个 REST 客户端。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
