如何通过Golang实现Kubernetes任务调度-Golang-PHP中文网

go程序不直接调度k8s任务，而是通过client-go提交job等对象，由kube-scheduler按规则调度；需用affinity/nodeselector声明意图，仅在必须覆盖默认行为时才开发自定义调度器。

如何通过golang实现kubernetes任务调度

Go 语言本身不直接调度 Kubernetes 任务，真正起作用的是你用 Go 编写的控制器（controller）或作业提交逻辑，通过 client-go 与 kube-apiserver 交互，让 K8s 自身的调度器（如 default-scheduler）去绑定 Pod 到 Node。搞不清这点，容易把“调度”误解为手动选节点、抢资源——实际绝大多数场景不该绕过调度器。

用 `client-go` 提交 Job 而不是手写调度逻辑

多数需求本质是“运行一次性任务”，比如定时数据清洗、CI 构建后清理。这时应创建 Job 对象，而非自己实现调度算法：

Job 会自动生成带唯一标签的 Pod，由 K8s 默认调度器按 nodeSelector、taints/tolerations、资源请求等规则分发
不要在 Go 代码里查 Node 列表、筛选空闲 CPU、再 PATCH Pod 的 spec.nodeName——这跳过调度器会导致资源视图不一致、抢占失败、无法触发 PriorityClass 行为
若需控制节点，优先用 affinity 或 nodeSelector 字段声明意图，而不是硬指定节点名

示例关键片段：

Golang Naming

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

下载

job := &batchv1.Job{
    ObjectMeta: metav1.ObjectMeta{
        GenerateName: "data-cleanup-",
        Namespace:    "prod",
    },
    Spec: batchv1.JobSpec{
        Template: corev1.PodTemplateSpec{
            Spec: corev1.PodSpec{
                RestartPolicy: "OnFailure",
                Containers: []corev1.Container{{
                    Name:  "runner",
                    Image: "my-registry/cleanup:v1.2",
                    Resources: corev1.ResourceRequirements{
                        Requests: corev1.ResourceList{
                            "cpu":    resource.MustParse("100m"),
                            "memory": resource.MustParse("256Mi"),
                        },
                    },
                }},
                // 声明调度偏好，而非强制绑定
                Affinity: &corev1.Affinity{
                    NodeAffinity: &corev1.NodeAffinity{
                        RequiredDuringSchedulingIgnoredDuringExecution: &corev1.NodeSelector{
                            NodeSelectorTerms: []corev1.NodeSelectorTerm{{
                                MatchExpressions: []corev1.NodeSelectorRequirement{{
                                    Key:      "node-role.kubernetes.io/batch",
                                    Operator: corev1.NodeSelectorOpIn,
                                    Values:   []string{"true"},
                                }},
                            }},
                        },
                    },
                },
            },
        },
    },
}
_, err := clientset.BatchV1().Jobs("prod").Create(ctx, job, metav1.CreateOptions{})

自定义调度器只在必须接管调度决策时才写

只有当你需要覆盖默认调度行为（例如：按磁盘 IO 延迟排序节点、跨 AZ 均匀分发任务、或集成外部资源池），才需开发独立调度器。此时核心是监听未调度 Pod（spec.nodeName == ""），计算最优 Node 后调用 Bind API：

必须监听 Pod 事件，过滤 PodScheduled==false 且 spec.nodeName=="" 的对象
绑定前要校验节点是否满足所有 PodSpec 约束（taints、resources、affinity），否则 Bind 会失败并返回 422 Unprocessable Entity
不要直接 PATCH Pod.spec.nodeName —— 必须走 /api/v1/namespaces/{ns}/pods/{name}/binding POST 接口，否则 Kubelet 不认
你的调度器需以 Deployment 运行，并配置 ClusterRole 允许 get/list/watch pods 和 create bindings

`client-go` 初始化和认证最容易出错

本地调试时用 kubeconfig，生产部署进集群要用 ServiceAccount，两者初始化方式不同，混淆会导致 401 Unauthorized 或 403 Forbidden：

本地开发：用 rest.InClusterConfig() 会失败，必须用 clientcmd.BuildConfigFromFlags("", kubeconfigPath)
集群内运行：禁用 kubeconfig 参数，直接调用 rest.InClusterConfig()，它会自动读取 /var/run/secrets/kubernetes.io/serviceaccount/ 下的 token 和 CA
ServiceAccount 必须绑定足够权限，最小集至少含：get/watch/list on pods、create on bindings、get on nodes
忘记设置 ctx 超时或取消机制，长期运行的 Watch 可能卡死在 TCP 连接上，建议用 context.WithTimeout(ctx, 30*time.Second)