kube-batch 不是 go 可直接调用的库，而是独立调度器，需通过提交符合规范的 podgroup 和 job 资源（如设置 schedulername 为 kube-batch、正确注解 group-name、确保 rbac 权限等）由其监听调度。
为什么 kube-batch 不是 Go 程序直接调用的库
很多人一上来就想在 Go 代码里 import "github.com/kubernetes-sigs/kube-batch"，然后调用某个函数提交任务——这行不通。kube-batch 是一个独立运行的 Kubernetes 调度器组件（类似 kube-scheduler），不是 SDK 或 client 库。它不提供 Go 函数接口供业务逻辑直接集成，而是通过监听集群中特定类型的 Job（如 Job、PyTorchJob、TfJob）来触发调度行为。
你的 Go 程序真正要做的，是生成符合 kube-batch 识别规则的资源对象（比如带 scheduling.k8s.io/group-name 注解的 PodGroup 和 Job），然后用 kubernetes/client-go 提交到 APIServer。
- 必须创建
PodGroupCRD 资源（podgroups.scheduling.sigs.k8s.io），否则kube-batch不会把作业当批处理任务看待 -
Job的spec.template.spec.schedulerName必须设为kube-batch（不能是default-scheduler） - Go 客户端提交时需确保 RBAC 允许创建
podgroups和对应Job类型（常见坑：权限不足导致403 Forbidden）
如何用 Go 构建一个可被 kube-batch 调度的 MPI 作业
HPC 场景下最典型的是 MPI 任务，需要多 Pod 协同启动、强依赖顺序和资源拓扑感知。Kube-Batch 支持通过 PodGroup 实现 gang scheduling（成组调度），但 Go 程序本身不参与调度决策，只负责构造正确的资源结构。
关键点在于：MPI 作业的每个 Worker Pod 必须属于同一个 PodGroup，且该 PodGroup 的 minMember 必须等于期望的 Pod 数量；否则 kube-batch 会拒绝调度部分 Pod。
立即学习“go语言免费学习笔记（深入）”；
-
PodGroup对象需设置spec.minMember: 4（若启 4 个 rank） - 每个 Worker
Pod模板里加注解：scheduling.k8s.io/group-name: "mpi-job-123" - 所有 Pod 的
spec.schedulerName都设为kube-batch - 避免在 Pod 中硬编码 IP 或主机名——应使用 Headless Service + DNS 解析（
mpi-worker-0.mpi-headless.default.svc.cluster.local）
示例片段（提交 PodGroup）：
pg := &podgroupv1alpha1.PodGroup{
ObjectMeta: metav1.ObjectMeta{
Name: "mpi-job-123",
Namespace: "default",
},
Spec: podgroupv1alpha1.PodGroupSpec{
MinMember: 4,
},
}
kube-batch 配置错误导致作业卡在 Pending 的常见原因
Go 程序提交资源后，作业长期处于 Pending 状态，90% 是因为 kube-batch 自身配置或资源定义不匹配。这不是 Go 代码的问题，但排查时容易误判。
-
kube-batch的--policy-configmap指向的 ConfigMap 不存在或格式错误 → 日志里会出现"failed to load policy config" - 未启用
PodGroup插件：默认配置中plugins列表不含podgroup→ 作业不会被纳入 gang 调度队列 - 节点没有打 label 匹配
PodGroup的spec.scheduleStrategy（如指定topologyKey: topology.kubernetes.io/zone，但节点没这个 label） - Go 提交的
PodGroup和Job不在同一 namespace →kube-batch默认只处理同 namespace 下的关联资源
Go 客户端如何安全等待 kube-batch 完成调度
不能轮询 Pod.Status.Phase == "Running" 就认为调度完成——kube-batch 调度成功只意味着 Pod 已绑定到节点，但容器可能还没拉镜像、InitContainer 可能失败、MPI 启动脚本可能卡住。真正的“就绪”需结合业务信号判断。
- 优先监听
PodGroup.Status.Phase == "Running"（表示所有成员 Pod 已调度成功） - 避免用
time.Sleep等固定时长——不同集群拉镜像速度差异极大 - 如果作业有输出日志或状态 endpoint，应在 Go 里实现轻量健康检查（如 HTTP GET
/status），而非依赖 Kubernetes 原生 Ready 探针（后者对 MPI 场景常不可靠） - 注意 context timeout：长时间等待需设上限，否则 Go 程序可能 hang 住（尤其在调试环境节点资源不足时）
复杂点在于：调度完成 ≠ 任务开始执行 ≠ 任务成功。很多 HPC 用户卡在这层语义混淆上，以为 Pod Running 就可以去取结果了——其实 MPI 进程可能根本没起来。
