K8s 自定义调度器 Part1：通过 Scheduler Extender 实现自定义调度逻辑
本文主要分享如何通过 Scheduler Extender 扩展调度器从而实现自定义调度策略。
1. 为什么需要自定义调度逻辑
什么是所谓的调度?
-
所谓调度就是指给 Pod 对象的 spec.nodeName 赋值
-
待调度对象则是所有 spec.nodeName 为空的 Pod
-
调度过程则是从集群现有的 Node 中为当前 Pod 选择一个最合适的
实际上 Pod 上还有一个平时比较少关注的属性： spec.schedulerName，用于指定该 Pod 要交给哪个调度器进行调度。
那么问题来了，平时用的时候也没给 spec.schedulerName 赋值过，怎么也能调度呢？
因为默认的 kube-scheduler 可以兼容 spec.schedulerName 为空或者为 default 的 Pod。
为什么需要自定义调度逻辑
自定义调度逻辑可以解决特定应用场景和需求，使集群资源使用更高效，适应特殊的调度策略。
比如：
- 不同的工作负载可能有特定的资源需求，比如 GPU 或 NPU，需要确保 Pod 只能调度到满足这些资源条件的节点上。
- 某些集群可能需要均衡资源消耗，避免将多个负载集中到某些节点上。
- 为了降低延迟，可能需要将Pod调度到特定地理位置的节点上。自定义调度器可以根据节点的地理位置标签进行调度决策。
- 某些应用需要与其他应用隔离运行，以避免资源争抢。通过自定义调度器，可以将特定类型的任务或工作负载隔离到专用的节点上。
- …
总之就是业务上有各种特殊的调度需求，因此我们需要通过实现自定义调度器来满足这些需求。
通过实现自定义调度器，可以根据具体的业务需求和集群环境，实现更灵活、更高效的资源管理和调度策略。
2.如何增加自定义调度逻辑
自定义调度器的几种方法
要增加自定义调度逻辑也并不复杂，K8s 整个调度流程都已经插件化了，我们并不需要重头开始实现一个调度器，而只需要实现一个调度插件，通过在调度过程中各个阶段加入我们的自定义逻辑，来控制最终的调度结果。
总体来说可以分为以下几个方向：
1）新增一个调度器
直接修改 kube-scheduler 源码，编译替换- 使用 调度框架（Scheduling Framework），我们可以使用 scheduler-plugins 作为模板，简化自定义调度器的开发流程。
- Kubernetes v1.15 版本中引入了可插拔架构的调度框架，使得定制调度器这个任务变得更加的容易。调库框架向现有的调度器中添加了一组插件化的 API，该 API 在保持调度程序“核心”简单且易于维护的同时，使得大部分的调度功能以插件的形式存在。
2）扩展原有调度器
- 通过 Scheduler Extender 可以实现对已有调度器进行扩展。单独创建一个 HTTP 服务并实现对应接口，后续就可以将该服务作为外置调度器使用。通过配置
KubeSchedulerConfiguration原 Scheduler 会以 HTTP 调用方式和外置调度器交互，实现在不改动原有调度器基础上增加自定义逻辑。
3）其他非主流方案
- 自定义 Webhook 直接修改未调度 Pod 的 spec.nodeName 字段，有点离谱但理论可行哈哈
二者都有自己的优缺点
| 优点 | 缺点 | |
|---|---|---|
| 新增调度器 | 性能好：由于不依赖外部插件或 HTTP 调用，调度流程的延迟相对较低，适合对性能要求较高的场景复用性高：可复用现有的调度插件，如 scheduler-plugins，大大降低了开发难度，提升了开发效率。 | 多个调度器可能会冲突：比如多个调度器同时调度了一个 Pod 到节点上，先启动的 Pod 把资源占用了，后续的 Pod 无法启动。 |
| 扩展调度器 | 实现简单：无需重新编译调度器，通过配置 KubeSchedulerConfiguration 创建一个外部 HTTP 服务来实现自定义逻辑。零侵入性：不需要修改或重构调度器的核心代码，可快速上线新的调度逻辑。灵活性较高：原有调度器和自定义逻辑相对独立，方便维护与测试。 | 性能差：调度请求需要经过 HTTP 调用，增加了调用延迟，对性能可能有影响。 |
一般在我们要改动的逻辑不多时，直接使用 Scheduler Extender 是比较简单的。
Scheduler 配置
调度器的配置有一个单独的对象：KubeSchedulerConfiguration，不过并没有以 CRD 形式存在，而是存放到 Configmap 中的。
以下是一个完整 KubeSchedulerConfiguration 的 yaml：
apiVersion: v1
data:config.yaml: |apiVersion: kubescheduler.config.k8s.io/v1beta2kind: KubeSchedulerConfigurationleaderElection:leaderElect: falseprofiles:- schedulerName: hami-schedulerextenders:- urlPrefix: "https://127.0.0.1:443"filterVerb: filterbindVerb: bindnodeCacheCapable: trueweight: 1httpTimeout: 30senableHTTPS: truetlsConfig:insecure: truemanagedResources:- name: nvidia.com/gpuignoredByScheduler: true- name: nvidia.com/gpumemignoredByScheduler: true- name: nvidia.com/gpucoresignoredByScheduler: true
一般分为基础配置和 extenders 配置两部分。
基础配置
基础配置一般就是配置调度器的名称，Demo 如下：
apiVersion: v1
kind: ConfigMap
metadata:name: my-scheduler-confignamespace: kube-system
data:my-scheduler-config.yaml: |apiVersion: kubescheduler.config.k8s.io/v1beta2kind: KubeSchedulerConfigurationprofiles:- schedulerName: my-schedulerleaderElection:leaderElect: false
通过 schedulerName 来指定该调度器的名称，比如这里就是 my-scheduler 。
创建 Pod 时除非手动指定 spec.schedulerName 为 my-scheduler，否则不会由该调度器进行调度。
扩展调度器：extenders 配置
extenders 部分通过额外指定一个 http 服务器来实现外置的自定义的调度逻辑。
一个简单的 Scheduler Extender 配置如下：
apiVersion: v1
kind: ConfigMap
metadata:name: i-scheduler-extendernamespace: kube-system
data:i-scheduler-extender.yaml: |apiVersion: kubescheduler.config.k8s.io/v1kind: KubeSchedulerConfigurationprofiles:- schedulerName: i-scheduler-extenderleaderElection:leaderElect: falseextenders:- urlPrefix: "http://localhost:8080"enableHTTPS: falsefilterVerb: "filter"prioritizeVerb: "prioritize"bindVerb: "bind"weight: 1nodeCacheCapable: true
核心部分为
extenders:- urlPrefix: "http://localhost:8080"enableHTTPS: falsefilterVerb: "filter"prioritizeVerb: "prioritize"bindVerb: "bind"weight: 1nodeCacheCapable: true
几个核心参数含义如下：
-
urlPrefix: http://127.0.0.1:8080用于指定外置的调度服务访问地址 -
filterVerb: "filter"：表示 Filter 接口在外置服务中的访问地址为 filter，即完整地址为http://127.0.0.1:8080/filter -
prioritizeVerb: "prioritize"：同上，Prioritize(Score) 接口的地址为 prioritize -
bindVerb: "bind"：同上，Bind 接口的地址为 bind
这样该调度器在执行 Filter 接口逻辑时，除了内置的调度器插件之外，还会通过 HTTP 方式调用外置的调度器。
这样我们只需要创建一个 HTTP 服务，实现对应接口即可实现自定义的调度逻辑，而不需要重头实现一个调度器。
ManagedResources 配置
在之前的配置中是所有 Pod 都会走 Extender 的调度逻辑，实际上 Extender 还有一个 ManagedResources 配置，用于限制只有申请使用指定资源的 Pod 才会走 Extender 调度逻辑，这样可以减少无意义的调度。
一个带 managedResources 的 KubeSchedulerConfiguration 内容如下
apiVersion: v1
data:config.yaml: |apiVersion: kubescheduler.config.k8s.io/v1kind: KubeSchedulerConfigurationleaderElection:leaderElect: falseprofiles:- schedulerName: hami-schedulerextenders:- urlPrefix: "https://127.0.0.1:443"filterVerb: filterbindVerb: bindnodeCacheCapable: falseenableHTTPS: falsemanagedResources:- name: nvidia.com/gpuignoredByScheduler: true- name: nvidia.com/gpumemignoredByScheduler: true- name: nvidia.com/gpucoresignoredByScheduler: true- name: nvidia.com/gpumem-percentageignoredByScheduler: true- name: nvidia.com/priorityignoredByScheduler: true
在原来的基础上增加了 managedResources 部分的配置
managedResources:- name: nvidia.com/gpuignoredByScheduler: true- name: nvidia.com/gpumemignoredByScheduler: true- name: nvidia.com/gpucoresignoredByScheduler: true- name: nvidia.com/gpumem-percentageignoredByScheduler: true
只有 Pod 申请这些特殊资源时才走 Extender 调度逻辑，否则使用原生的 Scheduler 调度即可。
ignoredByScheduler: true 的作用是告诉调度器忽略指定资源，避免将它们作为调度决策的依据。也就是说，虽然这些资源（如 GPU 或其他加速硬件）会被 Pod 请求，但调度器不会在选择节点时基于这些资源的可用性做出决定。
ps：因为这些资源可能是虚拟的，并不会真正的出现在 Node 上，因此调度时需要忽略掉，否则就没有任何节点满足条件了,但是这些虚拟资源则是我们的自定义调度逻辑需要考虑的事情。
Scheduler 中的判断逻辑如下，和之前说的一样，只有当 Pod 申请了这些指定的资源时，Scheduler 才会调用 Extender。
// IsInterested returns true if at least one extended resource requested by
// this pod is managed by this extender.
func (h *HTTPExtender) IsInterested(pod *v1.Pod) bool {if h.managedResources.Len() == 0 {return true}if h.hasManagedResources(pod.Spec.Containers) {return true}if h.hasManagedResources(pod.Spec.InitContainers) {return true}return false
}func (h *HTTPExtender) hasManagedResources(containers []v1.Container) bool {for i := range containers {container := &containers[i]for resourceName := range container.Resources.Requests {if h.managedResources.Has(string(resourceName)) {return true}}for resourceName := range container.Resources.Limits {if h.managedResources.Has(string(resourceName)) {return true}}}return false
}
3. Scheduler Extender 规范
Scheduler Extender 通过 HTTP 请求的方式，将调度框架阶段中的调度决策委托给外部的调度器，然后将调度结果返回给调度框架。
我们只需要实现一个 HTTP 服务，然后通过配置文件将其注册到调度器中，就可以实现自定义调度器。
通过 Scheduler Extender 扩展原有调度器一般分为以下两步：
- 1）创建一个 HTTP 服务，实现对应接口
- 2）修改调度器配置 KubeSchedulerConfiguration，增加 extenders 相关配置
外置调度器可以影响到三个阶段：
-
Filter：调度框架将调用 Filter 函数，过滤掉不适合被调度的节点。
-
Priority：调度框架将调用 Priority 函数，为每个节点计算一个优先级，优先级越高，节点越适合被调度。
-
Bind：调度框架将调用 Bind 函数，将 Pod 绑定到一个节点上。
Filter、Priority、Bind 三个阶段分别对应三个 HTTP 接口，三个接口都接收 POST 请求，各自的请求、响应结构定义在这里：#kubernetes/kube-scheduler/extender/v1/types.go
在这个 HTTP 服务中，我们可以实现上述阶段中的任意一个或多个阶段的接口，来定制我们的调度需求。
每个接口的请求和响应值请求如下。
Filter
请求参数
// ExtenderArgs represents the arguments needed by the extender to filter/prioritize
// nodes for a pod.
type ExtenderArgs struct {// Pod being scheduledPod *v1.Pod// List of candidate nodes where the pod can be scheduled; to be populated// only if Extender.NodeCacheCapable == falseNodes *v1.NodeList// List of candidate node names where the pod can be scheduled; to be// populated only if Extender.NodeCacheCapable == trueNodeNames *[]string
}
响应结果
// ExtenderFilterResult represents the results of a filter call to an extender
type ExtenderFilterResult struct {// Filtered set of nodes where the pod can be scheduled; to be populated// only if Extender.NodeCacheCapable == falseNodes *v1.NodeList// Filtered set of nodes where the pod can be scheduled; to be populated// only if Extender.NodeCacheCapable == trueNodeNames *[]string// Filtered out nodes where the pod can't be scheduled and the failure messagesFailedNodes FailedNodesMap// Filtered out nodes where the pod can't be scheduled and preemption would// not change anything. The value is the failure message same as FailedNodes.// Nodes specified here takes precedence over FailedNodes.FailedAndUnresolvableNodes FailedNodesMap// Error message indicating failureError string
}
Prioritize
请求参数
// ExtenderArgs represents the arguments needed by the extender to filter/prioritize
// nodes for a pod.
type ExtenderArgs struct {// Pod being scheduledPod *v1.Pod// List of candidate nodes where the pod can be scheduled; to be populated// only if Extender.NodeCacheCapable == falseNodes *v1.NodeList// List of candidate node names where the pod can be scheduled; to be// populated only if Extender.NodeCacheCapable == trueNodeNames *[]string
}
响应结果
// HostPriority represents the priority of scheduling to a particular host, higher priority is better.
type HostPriority struct {// Name of the hostHost string// Score associated with the hostScore int64
}// HostPriorityList declares a []HostPriority type.
type HostPriorityList []HostPriority
Bind
请求参数
// ExtenderBindingArgs represents the arguments to an extender for binding a pod to a node.
type ExtenderBindingArgs struct {// PodName is the name of the pod being boundPodName string// PodNamespace is the namespace of the pod being boundPodNamespace string// PodUID is the UID of the pod being boundPodUID types.UID// Node selected by the schedulerNode string
}
响应结果
// ExtenderBindingResult represents the result of binding of a pod to a node from an extender.
type ExtenderBindingResult struct {// Error message indicating failureError string
}
4. Demo
这部分则是手把手实现一个简单的扩展调度器,完整代码见：lixd/i-scheduler-extender
功能如下：
- 1）过滤阶段：仅调度到带有 Label
priority.lixueduan.com的节点上 - 2）打分阶段：直接将节点上 Label
priority.lixueduan.com的值作为得分- 比如某节点携带 Label
priority.lixueduan.com=50则打分阶段该节点则是 50 分
- 比如某节点携带 Label
代码实现
main.go
比较简单，直接通过内置的 net.http 包启动一个 http 服务即可。
var h *server.Handlerfunc init() {h = server.NewHandler(extender.NewExtender())
}func main() {http.HandleFunc("/filter", h.Filter)http.HandleFunc("/filter_onlyone", h.FilterOnlyOne) // Filter 接口的一个额外实现http.HandleFunc("/priority", h.Prioritize)http.HandleFunc("/bind", h.Bind)http.ListenAndServe(":8080", nil)
}
由于 Priority 阶段返回的得分 kube-Scheduler 会自行汇总后重新计算，因此扩展调度器的 priority 接口并不能安全控制最终调度结果，因此额外实现了一个 filter_onlyone 接口。
Filter 实现
filter 接口用于过滤掉不满足条件的接口，这里直接过滤掉没有指定 label 的节点即可。
// Filter 过滤掉不满足条件的节点
func (ex *Extender) Filter(args extenderv1.ExtenderArgs) *extenderv1.ExtenderFilterResult {nodes := make([]v1.Node, 0)nodeNames := make([]string, 0)for _, node := range args.Nodes.Items {_, ok := node.Labels[Label]if !ok { // 排除掉不带指定标签的节点continue}nodes = append(nodes, node)nodeNames = append(nodeNames, node.Name)}// 没有满足条件的节点就报错if len(nodes) == 0 {return &extenderv1.ExtenderFilterResult{Error: fmt.Errorf("all node do not have label %s", Label).Error()}}args.Nodes.Items = nodesreturn &extenderv1.ExtenderFilterResult{Nodes: args.Nodes, // 当 NodeCacheCapable 设置为 false 时会使用这个值NodeNames: &nodeNames, // 当 NodeCacheCapable 设置为 true 时会使用这个值}
}
具体返回 Nodes 还是 NodeNames 决定了后续 Scheduler 部署的 NodeCacheCapable 参数的配置，二者对于即可。
Prioritize 实现
Prioritize 对应的就是 Score 阶段，给 Filter 之后留下来的节点打分，选择一个最适合的节点进行调度。
这里的逻辑就是之前说的：解析 Node 上的 label ，直接将其 value 作为节点分数。
// Prioritize 给 Pod 打分
func (ex *Extender) Prioritize(args extenderv1.ExtenderArgs) *extenderv1.HostPriorityList {var result extenderv1.HostPriorityListfor _, node := range args.Nodes.Items {// 获取 Node 上的 Label 作为分数priorityStr, ok := node.Labels[Label]if !ok {klog.Errorf("node %q does not have label %s", node.Name, Label)continue}priority, err := strconv.Atoi(priorityStr)if err != nil {klog.Errorf("node %q has priority %s are invalid", node.Name, priorityStr)continue}result = append(result, extenderv1.HostPriority{Host: node.Name,Score: int64(priority),})}return &result
}
Bind 实现
就是通过 clientset 创建一个 Binding 对象，指定 Pod 和 Node 信息。
// Bind 将 Pod 绑定到指定节点
func (ex *Extender) Bind(args extenderv1.ExtenderBindingArgs) *extenderv1.ExtenderBindingResult {log.Printf("bind pod: %s/%s to node:%s", args.PodNamespace, args.PodName, args.Node)// 创建绑定关系binding := &corev1.Binding{ObjectMeta: metav1.ObjectMeta{Name: args.PodName, Namespace: args.PodNamespace, UID: args.PodUID},Target: corev1.ObjectReference{Kind: "Node", APIVersion: "v1", Name: args.Node},}result := new(extenderv1.ExtenderBindingResult)err := ex.ClientSet.CoreV1().Pods(args.PodNamespace).Bind(context.Background(), binding, metav1.CreateOptions{})if err != nil {klog.ErrorS(err, "Failed to bind pod", "pod", args.PodName, "namespace", args.PodNamespace, "podUID", args.PodUID, "node", args.Node)result.Error = err.Error()}return result
}
Filter OnlyOne 实现
Extender 仅作为一个额外的调度插件接入， 接口返回得分最终 Scheduler 会将其和其他插件打分合并之后再选出最终节点，因此 extender 中无法通过 prioritie 接口的分数完全控制调度结果。
不过也不是没有办法！
想要完全控制调度结果，我们可以在 Filter 接口中特殊处理。
Filter 接口先过滤掉不满足条件的节点，然后对剩余节点进行打分，最终只返回得分最高的那个节点，这样就一定会调度到该接口，从而实现完全控制调度结果。
具体实现如下：
// FilterOnlyOne 过滤掉不满足条件的节点,并将其余节点打分排序，最终只返回得分最高的节点以实现完全控制调度结果
func (ex *Extender) FilterOnlyOne(args extenderv1.ExtenderArgs) *extenderv1.ExtenderFilterResult {// 过滤掉不满足条件的节点nodeScores := &NodeScoreList{NodeList: make([]*NodeScore, 0)}for _, node := range args.Nodes.Items {_, ok := node.Labels[Label]if !ok { // 排除掉不带指定标签的节点continue}// 对剩余节点打分score := ComputeScore(node)nodeScores.NodeList = append(nodeScores.NodeList, &NodeScore{Node: node, Score: score})}// 没有满足条件的节点就报错if len(nodeScores.NodeList) == 0 {return &extenderv1.ExtenderFilterResult{Error: fmt.Errorf("all node do not have label %s", Label).Error()}}// 排序sort.Sort(nodeScores)// 然后取最后一个，即得分最高的节点，这样由于 Filter 只返回了一个节点，因此最终肯定会调度到该节点上m := (*nodeScores).NodeList[len((*nodeScores).NodeList)-1]// 组装一下返回结果args.Nodes.Items = []v1.Node{m.Node}return &extenderv1.ExtenderFilterResult{Nodes: args.Nodes,NodeNames: &[]string{m.Node.Name},}
}
部署
构建镜像
Dockerfile 如下：
# syntax=docker/dockerfile:1# Build the manager binary
FROM golang:1.22.5 as builder
ARG TARGETOS
ARG TARGETARCHENV GOPROXY=https://goproxy.cnWORKDIR /workspace
# Copy the go source
COPY . /workspace
# cache deps before building and copying source so that we don't need to re-download as much
# and so that source changes don't invalidate our downloaded layer
RUN go mod download# Build
# the GOARCH has not a default value to allow the binary be built according to the host where the command
# was called. For example, if we call make docker-build in a local env which has the Apple Silicon M1 SO
# the docker BUILDPLATFORM arg will be linux/arm64 when for Apple x86 it will be linux/amd64. Therefore,
# by leaving it empty we can ensure that the container and binary shipped on it will have the same platform.
RUN CGO_ENABLED=0 GOOS=${TARGETOS:-linux} GOARCH=${TARGETARCH} go build -a -o extender main.go# Use distroless as minimal base image to package the manager binary
# Refer to https://github.com/GoogleContainerTools/distroless for more details
#FROM gcr.io/distroless/static:nonroot
FROM busybox:1.36
WORKDIR /
COPY --from=builder /workspace/extender .
USER 65532:65532ENTRYPOINT ["/extender"]
部署到集群
部分也是分为两步：
-
1）部署 Extender：由于 Extender 只是一个 HTTP 服务器，只需要使用 Deployment 将其部署到集群即可。
-
2）配置 Extender：修改调度器的 KubeSchedulerConfiguration 配置，在其中 extender 部分指定 url 以及对应的 path，进行接入。
这里为了不影响到默认的 kube-scheduler，我们使用 kube-scheduler 镜像单独启动一个 Scheduler，然后为该调度器配置上 Extender，同时为了降低网络请求的影响，直接将 kube-scheduler 和 Extender 直接运行在同一个 Pod 里，通过 localhost 进行访问。
完整 yaml 如下：
apiVersion: v1
kind: ServiceAccount
metadata:name: i-scheduler-extendernamespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: i-scheduler-extender
subjects:- kind: ServiceAccountname: i-scheduler-extendernamespace: kube-system
roleRef:kind: ClusterRolename: cluster-adminapiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ConfigMap
metadata:name: i-scheduler-extendernamespace: kube-system
data:i-scheduler-extender.yaml: |apiVersion: kubescheduler.config.k8s.io/v1kind: KubeSchedulerConfigurationprofiles:- schedulerName: i-scheduler-extenderleaderElection:leaderElect: falseextenders:- urlPrefix: "http://localhost:8080"enableHTTPS: falsefilterVerb: "filter"prioritizeVerb: "prioritize"bindVerb: "bind"weight: 1nodeCacheCapable: true
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:component: i-scheduler-extendertier: control-planename: i-scheduler-extendernamespace: kube-system
spec:replicas: 1selector:matchLabels:component: i-scheduler-extendertier: control-planetemplate:metadata:labels:component: i-scheduler-extendertier: control-planespec:serviceAccountName: i-scheduler-extendercontainers:- name: kube-schedulerimage: registry.k8s.io/kube-scheduler:v1.29.0command:- kube-scheduler- --config=/etc/kubernetes/i-scheduler-extender.yamllivenessProbe:httpGet:path: /healthzport: 10259scheme: HTTPSinitialDelaySeconds: 15readinessProbe:httpGet:path: /healthzport: 10259scheme: HTTPSresources:requests:cpu: '0.1'volumeMounts:- name: config-volumemountPath: /etc/kubernetes- name: i-scheduler-extenderimage: lixd96/i-scheduler-extender:v1ports:- containerPort: 8080volumes:- name: config-volumeconfigMap:name: i-scheduler-extenderkubectl apply -f deploy
确认服务正常运行
[root@scheduler-1 ~]# kubectl -n kube-system get po|grep i-scheduler-extender
i-scheduler-extender-f9cff954c-dkwz2 2/2 Running 0 1m
接下来就可以开始测试了。
测试
创建 Pod
创建一个 Deployment 并指定使用上一步中部署的 Scheduler，然后测试会调度到哪个节点上。
apiVersion: apps/v1
kind: Deployment
metadata:name: test
spec:replicas: 1selector:matchLabels:app: testtemplate:metadata:labels:app: testspec:schedulerName: i-scheduler-extendercontainers:- image: busybox:1.36name: nginxcommand: ["sleep"] args: ["99999"]
创建之后 Pod 会一直处于 Pending 状态
[root@scheduler-1 lixd]# k get po
NAME READY STATUS RESTARTS AGE
test-58794bff9f-ljxbs 0/1 Pending 0 17s查看具体情况
[root@scheduler-1]# k describe po test-58794bff9f-ljxbs
Events:Type Reason Age From Message---- ------ ---- ---- -------Warning FailedScheduling 99s i-scheduler-extender all node do not have label priority.lixueduan.comWarning FailedScheduling 95s (x2 over 97s) i-scheduler-extender all node do not have label priority.lixueduan.com
可以看到，是因为 Node 上没有我们定义的 Label，因此都不满足条件，最终 Pod 就一直 Pending 了。
添加 Label
由于我们实现的 Filter 逻辑是需要 Node 上有priority.lixueduan.com 才会用来调度，否则直接会忽略。
理论上，只要给任意一个 Node 打上 Label 就可以了。
[root@scheduler-1 install]# k get node
NAME STATUS ROLES AGE VERSION
scheduler-1 Ready control-plane 4h34m v1.27.4
scheduler-2 Ready <none> 4h33m v1.27.4
[root@scheduler-1 install]# k label node scheduler-1 priority.lixueduan.com=10
node/scheduler-1 labeled
再次查看 Pod 状态
[root@scheduler-1 lixd]# k get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-58794bff9f-ljxbs 1/1 Running 0 104s 172.25.123.201 scheduler-1 <none> <none>
已经被调度到 node1 上了，查看详细日志
[root@scheduler-1 install]# k describe po test-7f7bb8f449-w6wvv
Events:Type Reason Age From Message---- ------ ---- ---- -------Warning FailedScheduling 116s i-scheduler-extender 0/2 nodes are available: preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod.Warning FailedScheduling 112s (x2 over 115s) i-scheduler-extender 0/2 nodes are available: preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod.Normal Scheduled 26s i-scheduler-extender Successfully assigned default/test-58794bff9f-ljxbs to scheduler-1
可以看到，确实是 i-scheduler-extender 这个调度器在处理，调度到了 node1.
多节点排序
我们实现的 Score 是根据 Node 上的 priority.lixueduan.com 对应的 Value 作为得分的，因此调度器会优先考虑调度到 Value 比较大的一个节点。
因为 Score 阶段也有很多调度插件，Scheduler 会汇总所有得分，最终才会选出结果，因此这里的分数也是仅供参考，不能完全控制调度结果。
给 node2 也打上 label，value 设置为 20
[root@scheduler-1 install]# k get node
NAME STATUS ROLES AGE VERSION
scheduler-1 Ready control-plane 4h34m v1.27.4
scheduler-2 Ready <none> 4h33m v1.27.4
[root@scheduler-1 install]# k label node scheduler-2 priority.lixueduan.com=20
node/scheduler-2 labeled
然后更新 Deployment ，触发创建新 Pod ，测试调度逻辑。
[root@scheduler-1 lixd]# kubectl rollout restart deploy test
deployment.apps/test restarted
因为 Node2 上的 priority 为 20，node1 上为 10，那么理论上会调度到 node2 上。
[root@scheduler-1 lixd]# k get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-84fdbbd8c7-47mtr 1/1 Running 0 38s 172.25.0.162 scheduler-1 <none> <none>
结果还是调度到了 node1，为什么呢？
这就是前面提到的：因为 Extender 仅作为一个额外的调度插件接入，Prioritize 接口返回得分最终 Scheduler 会将其和其他插件打分合并之后再选出最终节点，因此 Extender 想要完全控制调度结果，只能在 Filter 接口中实现，过滤掉不满足条件的节点，并对剩余节点进行打分，最终 Filter 接口只返回得分最高的那个节点，从而实现完全控制调度结果。
ps：即之前的 Filter OnlyOne 实现，可以在 KubeSchedulerConfiguration 中配置不同的 path 来调用不同接口进行测试。
修改 KubeSchedulerConfiguration 配置，
apiVersion: v1
kind: ConfigMap
metadata:name: i-scheduler-extendernamespace: kube-system
data:i-scheduler-extender.yaml: |apiVersion: kubescheduler.config.k8s.io/v1kind: KubeSchedulerConfigurationprofiles:- schedulerName: i-scheduler-extenderleaderElection:leaderElect: falseextenders:- urlPrefix: "http://localhost:8080"enableHTTPS: falsefilterVerb: "filter_onlyone"prioritizeVerb: "prioritize"bindVerb: "bind"weight: 1nodeCacheCapable: true
修改点：
filterVerb: "filter_onlyone"
Path 从 filter 修改成了 filter_onlyone，这里的 path 和前面注册服务时的路径对应：
http.HandleFunc("/filter", h.Filter)http.HandleFunc("/filter_onlyone", h.FilterOnlyOne) // Filter 接口的一个额外实现
修改后重启一下 Scheduler
kubectl -n kube-system rollout restart deploy i-scheduler-extender
再次更新 Deployment 触发调度
[root@scheduler-1 install]# k rollout restart deploy test
deployment.apps/test restarted
这样应该是调度到 node2 了，确认一下
[root@scheduler-1 lixd]# k get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-849f549d5b-pbrml 1/1 Running 0 12s 172.25.0.166 scheduler-2 <none> <none>
现在我们更新 Node1 的 label，改成 30
k label node scheduler-1 priority.lixueduan.com=30 --overwrite
再次更新 Deployment 触发调度
[root@scheduler-1 install]# k rollout restart deploy test
deployment.apps/test restarted
这样应该是调度到 node1 了，确认一下
[root@scheduler-1 lixd]# k get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-69d9ccb877-9fb6t 1/1 Running 0 5s 172.25.123.203 scheduler-1 <none> <none>
说明修改 Filter 方法实现之后，确实可以直接控制调度结果。
**【Kubernetes 系列】**持续更新中，搜索公众号【探索云原生】订阅，文章。
5. 小结
本文主要分享了如何通过 Scheduler Extender 方式实现自定义调度逻辑。
Extender 具体为一个 http 服务器，可以实现 Filter、Prioritize(调度中的 Score 阶段)、Bind 三个接口。
通过修改 KubeSchedulerConfiguration 配置，为 Scheduler 指定了一个外部的调度器插件。
因此通过 Scheduler Extender 扩展原有调度器一般分为以下两步：
- 1）创建一个 HTTP 服务，实现对应接口
- 2）修改调度器配置 KubeSchedulerConfiguration，增加 extenders 相关配置
此外还可以通过 ManagedResources 配置实现只让部分 Pod 走 Extender 调度逻辑。
需要注意的是：Extender 仅作为一个额外的调度插件接入，Prioritize 接口返回得分最终 Scheduler 会将其和其他插件打分合并之后再选出最终节点，因此 Extender 想要完全控制调度结果，只能在 Filter 接口中实现，过滤掉不满足条件的节点，并对剩余节点进行打分，最终 Filter 接口只返回得分最高的那个节点，从而实现完全控制调度结果。
最佳实践：
-
如果只是要实现普通调度插件：可以正常实现 Filter、Prioritize、Bind 三个接口。
-
如果要由 Extender 完全控制调度结果：只需要实现Filter、Bind 接口，且 Filter 结果只能返回一个得分最高的节点作为最终选定的节点，即：将 FIlter 和 Score 逻辑都合并到 Filter 接口中。
完整代码见：lixd/i-scheduler-extender