Golang打造K8s自定义调度器技巧分享

自定义K8s调度器的关键在于理解调度流程并用Go实现过滤和评分算法。1. 理解K8s调度流程：包括预选、优选和绑定三个阶段，自定义逻辑需插入这些阶段；2. 选择扩展点：推荐使用Scheduler Framework，提供更细粒度控制；3. 使用client-go和informer/lister与K8s交互并高效获取集群状态；4. 实现FilterPlugin和ScorePlugin接口，完成节点筛选与打分；5. 构建独立调度器二进制文件并注册到K8s。自定义调度器适用于特殊硬件调度、资源优化、多租户隔离等场景，核心组件包括client-go、informer、lister及插件接口，开发流程涵盖策略定义、模块创建、插件实现、注册与部署。设计高效算法需结合资源适配性、亲和性、数据本地性、成本等多维度指标，并动态调整权重以优化资源利用率。

想用Golang打造K8s自定义调度器？其实没那么玄乎，关键是摸透K8s调度框架的门道，然后用Go语言把那些预选、优选的逻辑写得既高效又聪明，这样才能真正玩转资源分配，让集群跑得更顺畅。自定义调度器，说白了，就是K8s提供的一个扩展点，让你能根据自己的业务需求，来决定Pod应该落在哪个节点上，而不是完全依赖K8s自带的默认调度器。秘诀嘛，就在于理解K8s的调度流程，并用Go实现你独有的过滤（Filter）和评分（Score）算法，从而实现极致的资源优化。

解决方案

要用Golang实现一个K8s自定义调度器，核心思路是利用K8s提供的调度器框架（Scheduler Framework）或者更早期的调度器扩展（Scheduler Extender）机制。在我看来，现在更推荐使用调度器框架，因为它提供了更细粒度的控制和更强大的扩展能力。

具体来说，你需要做几件事：

1. 理解K8s调度流程： K8s默认调度器的工作流程大致是：首先，预选（Predicates）阶段，过滤掉不符合条件的节点，比如资源不足、亲和性不匹配的节点；接着是优选（Priorities）阶段，对通过预选的节点进行打分，选出分数最高的节点；最后是绑定（Bind）阶段，将Pod分配到选定的节点上。自定义调度器就是要在这些阶段插入我们自己的逻辑。

2. 选择合适的扩展点：

   
   • Scheduler Extender (较旧)： 这种方式通过HTTP/HTTPS回调，将调度请求发送给外部服务进行预选、优选或绑定。好处是可以用任何语言实现，但性能开销相对大，且与K8s内部调度逻辑耦合度较低。
   • Scheduler Framework (推荐)： 这是K8s 1.15+引入的，它将调度器内部的各个阶段抽象为一系列“插件（Plugins）”，比如Filter、Score、PreBind等。我们只需要实现这些插件接口，然后注册到调度器框架中，就能与K8s原生调度器无缝集成。用Go语言实现自定义调度器，通常就是基于这个框架。

3. 使用Golang编写核心逻辑：

   • client-go： 这是K8s官方提供的Go客户端库，用于与K8s API服务器交互，比如获取Pod、Node信息，更新Pod状态等。
   • informer和lister： 为了高效地获取K8s集群的实时状态，你需要使用informer来监听资源变化（如Pod、Node的增删改），并用lister来缓存这些资源，避免频繁地查询API服务器。这是构建高性能调度器的基石。
   • 实现FilterPlugin和ScorePlugin： 这是自定义调度器的核心。
     • FilterPlugin负责实现预选逻辑，决定一个节点是否适合运行某个Pod。
     • ScorePlugin负责实现优选逻辑，给符合条件的节点打分，分数越高越优先。
   • 注册你的调度器： 你可以构建一个独立的调度器二进制文件，它会启动一个调度器实例，并加载你实现的插件。在Pod的spec.schedulerName字段中指定你的调度器名称，K8s就会将该Pod调度请求发送给你的调度器处理。

说实话，这套框架的灵活度非常高，几乎可以满足所有你能想到的调度场景。关键在于如何把你的业务逻辑巧妙地转换成过滤和打分的算法。

为什么我们需要自定义K8s调度器？

你可能会问，K8s自带的默认调度器不是挺好用吗？干嘛还要折腾自定义？嗯，这个问题问得好，在我看来，主要有几个场景是默认调度器力所不及，或者说，它无法完全满足我们对资源精细化控制的需求。

首先，最常见的就是特殊硬件的调度。比如，你的应用需要用到GPU、FPGA或者特定的AI加速芯片。K8s默认调度器可不知道这些东西，它只知道CPU、内存。这时候，我们就需要自定义调度器，去检查节点上是否有这些特殊硬件，并且确保Pod能正确地使用它们。我之前就遇到过一个场景，需要把特定的AI训练任务调度到带有特定型号GPU的节点上，并且要保证每个GPU只跑一个任务，默认调度器就完全搞不定。

其次，是高级的资源优化策略。K8s默认调度器虽然有“最少请求（LeastRequested）”或“最平衡（BalancedResource）”之类的策略，但这些是通用的。如果你想实现更激进的“装箱（Bin-Packing）”策略，尽可能把Pod塞满少数节点，以释放更多空闲节点来关机省钱；或者反过来，你想实现“分散（Spread）”策略，让Pod尽量分散到不同节点、可用区，提高容灾能力，这些都需要更细致的算法。特别是对于一些有严格SLA要求的服务，你可能需要根据业务优先级、成本预算来动态调整调度策略，这已经超出了默认调度器的范畴。

再来，多租户环境下的资源隔离与公平性。在共享集群中，不同的团队或用户可能对资源有不同的期望。你可能希望某个高优先级团队的Pod能优先调度，或者确保所有团队都能获得“公平”的资源份额，避免某个“大户”霸占资源。自定义调度器可以让你引入配额管理、优先级队列、甚至基于信用点数的调度机制，实现真正的资源公平分配。

还有一些比较小众但很重要的场景，比如数据本地性调度，让Pod尽量调度到与它所需数据更近的节点上，减少网络延迟；或者许可证管理，确保某些受限软件的Pod只调度到有足够许可证的节点上。这些都是默认调度器无法直接提供的能力。所以，自定义调度器并非是“炫技”，而是解决实际生产问题的“利器”。

Golang自定义调度器的核心组件与开发流程是怎样的？

用Golang来写K8s自定义调度器，核心就是围绕k8s.io/kubernetes/pkg/scheduler/framework这个包来展开。这套框架设计得非常精巧，它把调度过程拆解成了一系列可插拔的插件。

核心组件：

1. client-go 和 informer/lister： 这是基础中的基础。你的调度器需要知道集群里有哪些Pod、哪些Node，它们的状态如何。client-go负责和K8s API Server通信，而informer和lister则提供了一个高效、低延迟的本地缓存机制。informer会监听K8s资源的事件（创建、更新、删除），并把最新的状态同步到lister提供的本地缓存中。这样，你的调度器在做决策时，就不用每次都去查询API Server，大大提高了性能。

   // 简化的 informer 和 lister 示例
   factory := informers.NewSharedInformerFactory(kubeClient, 0) // 0 表示不重新同步
   podInformer := factory.Core().V1().Pods().Informer()
   nodeLister := factory.Core().V1().Nodes().Lister()
   // 启动 informer
   stopCh := make(chan struct{})
   factory.Start(stopCh)
   factory.WaitForCacheSync(stopCh)

2. Plugin 接口： 这是调度器框架中所有插件需要实现的通用接口。

   type Plugin interface {
       Name() string
   }

   你自定义的Filter、Score等都必须实现这个Name()方法，返回你的插件名称。

3. FilterPlugin 接口： 这是实现预选逻辑的关键。它有一个Filter方法，接收一个Pod和一个NodeInfo，返回这个节点是否适合该Pod，以及一个状态（比如错误信息）。

   type FilterPlugin interface {
       Plugin
       Filter(ctx context.Context, state *CycleState, pod *v1.Pod, nodeInfo *NodeInfo) *Status
   }

   比如，你要检查节点上是否有某个自定义标签，就可以在这里实现。

4. ScorePlugin 接口： 这是实现优选逻辑的关键。它有一个Score方法，接收一个Pod和一个NodeName，返回一个分数。分数越高，表示该节点越适合这个Pod。

   type ScorePlugin interface {
       Plugin
       Score(ctx context.Context, state *CycleState, p *v1.Pod, nodeName string) (int64, *Status)
   }

   这里你可以根据节点负载、剩余资源、亲和性等多种因素来打分。

5. 调度器主循环： 你的自定义调度器本质上也是一个Go程序，它会启动一个调度器实例，监听K8s中那些schedulerName设置为你自定义调度器名称的Pod。当发现有这样的Pod时，它就会调用你注册的Filter和Score插件，执行调度逻辑，然后通过client-go将Pod绑定到选定的节点上。

开发流程：

1. 定义你的调度策略： 明确你的调度器要解决什么问题，是资源利用率、成本优化、还是特殊硬件调度？这决定了你的Filter和Score算法。

2. 创建你的Go模块： 初始化一个新的Go模块，引入k8s.io/kubernetes（或者更精确的k8s.io/kube-scheduler）和k8s.io/client-go等依赖。

3. 实现自定义插件：

   • 创建一个结构体，比如MyCustomSchedulerPlugin。

   • 让这个结构体实现framework.FilterPlugin和/或framework.ScorePlugin接口。

   • 在Filter和Score方法中编写你的核心调度算法。

   • 举个Filter插件的例子，检查节点是否有特定标签：

     package myplugin
     
     import (
         "context"
         v1 "k8s.io/api/core/v1"
         "k8s.io/kubernetes/pkg/scheduler/framework"
     )
     
     const (
         Name = "MyCustomLabelFilter"
         RequiredLabel = "my.domain/special-node"
     )
     
     type MyCustomLabelFilter struct{}
     
     func (pl *MyCustomLabelFilter) Name() string {
         return Name
     }
     
     // Filter 检查节点是否有 RequiredLabel
     func (pl *MyCustomLabelFilter) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status {
         if _, ok := nodeInfo.Node().Labels[RequiredLabel]; !ok {
             return framework.NewStatus(framework.UnschedulableAndUnresolvable, "node does not have required label")
         }
         return framework.NewStatus(framework.Success)
     }
     
     // New 创建一个新的 MyCustomLabelFilter 插件实例
     func New(args runtime.Object, handle framework.Handle) (framework.Plugin, error) {
         return &MyCustomLabelFilter{}, nil
     }

4. 注册插件到调度器工厂： 你需要编写一个main函数，通过framework.NewFramework来构建调度器框架实例，并把你实现的插件注册进去。

5. 配置你的调度器： 创建一个policy.config文件，告诉K8s调度器你的插件名称和启用顺序。

6. 编译和部署： 将你的Go程序编译成二进制文件，并部署到K8s集群中，通常以Deployment的形式运行。别忘了给你的Deployment配置ServiceAccount和RBAC权限，让它能够操作Pod和Node资源。

整个过程下来，你会发现，虽然看起来步骤不少，但K8s调度器框架的模块化设计，让我们可以非常专注于核心调度算法的实现，而不用过多地操心K8s内部的复杂机制。

如何设计高效的调度算法来优化资源利用率？

设计高效的调度算法，这可真是个艺术活儿，也是自定义调度器的核心价值所在。它不单单是把Pod扔到某个节点上，更是要让整个集群的资源利用率达到最优，同时兼顾性能、成本和业务需求。

核心思想：过滤（Filter）与评分（Score）的艺术

我们前面提到了Filter和Score。它们就像是两道关卡：Filter是粗筛，快速排除不符合基本条件的节点；Score是精筛，在通过初筛的节点中，根据更复杂的指标进行打分，选出“最佳”的那个。

1. 精妙的过滤（Predicates/Filter）：

   • 资源适配性： 最基本的当然是检查节点的CPU、内存、存储等资源是否满足Pod的需求。但更高级的过滤，可以检查是否有特定的GPU型号、FPGA，甚至是不是在某个物理机架上。比如说，你的Pod需要一个NVIDIA A100 GPU，你就可以在Filter里检查node.Labels或者node.Status.Capacity有没有对应的信息。
   • 亲和性与反亲和性： K8s自带的节点亲和性和反亲和性已经很强大，但如果你有更复杂的业务逻辑，比如某些Pod必须和另一些Pod在同一个物理服务器上（数据本地性），或者绝不能在同一个服务器上（高可用），你可以在Filter中实现自定义的PodAffinity或PodAntiAffinity逻辑，甚至扩展到跨集群的亲和性判断。
   • 自定义条件： 比如，你有一些“维护中”的节点，或者“已达到最大租户数”的节点，这些都可以通过自定义标签或注解在Filter阶段直接排除掉。我之前就写过一个Filter，专门用来检查节点是否属于某个特定的“集群池”，不符合的直接踢掉。

2. 智能的评分（Priorities/Score）：

   • 资源均衡与集中：
     • “最少请求”： 倾向于将Pod调度到那些资源使用率最低的节点上。这有助于将工作负载分散到整个集群，避免少数节点过载，提高整体稳定性。
     • “最多请求”（Bin-Packing）： 倾向于将Pod调度到那些资源使用率相对较高的节点上，尽可能将节点“填满”。这样可以腾出更多的空闲节点，方便关机省电，或者为未来更大的工作负载预留空间。这两种策略各有优劣，取决于你的业务目标是追求稳定性还是资源成本。
     • “平衡资源”： 综合考虑CPU和内存的利用率，力求让节点在这两种资源上的使用率都相对均衡，避免出现“CPU利用率很高但内存空闲”或反之的情况。
   • 数据本地性： 如果你的Pod需要访问大量数据，那么把它调度到数据所在的节点或离数据源最近的节点，可以显著减少网络延迟，提高性能。你可以根据存储卷的拓扑信息（如PV的nodeAffinity）来打分。
   • 镜像本地性： 如果节点上已经缓存了Pod所需的容器镜像，那么调度到这个节点可以省去镜像下载的时间，加速Pod启动。这在CI/CD场景下特别有用。
   • 成本优化： 如果你的集群是混合了不同计费模式（如按需实例、竞价实例）的节点，你可以给竞价实例更高的分数，优先使用它们来降低成本，同时配合Pod中断处理机制。
   • 业务优先级与QoS： 对于不同业务线或不同服务等级的Pod，可以赋予不同的优先级。高优先级的Pod可以优先获得资源，甚至可以抢占低优先级的Pod（这涉及到调度器框架中的Preemption插件，比较复杂）。

一些设计上的思考点：

• 指标的选择： 你需要什么指标来指导调度？是CPU利用率、内存使用率、还是自定义的带宽、IOPS？这些指标如何获取？（通常通过Prometheus等监控系统拉取，或者直接从NodeStatus中获取）。
• 权重的分配： 在Score阶段，你可能有多个打分维度。比如，节点剩余资源、镜像本地性、成本，它们各自的权重是多少？是资源利用率最重要，还是成本最重要？这需要根据你的业务优先级来调整。
• 动态调整： 优秀的调度算法不应该是一成不变的。它可能需要根据集群的整体负载、业务高峰期、甚至外部市场价格（