k8s调度器

k8s调度器

目录

[TOC]

前言

实验环境

实验环境：1、win10,vmwrokstation虚机；2、k8s集群：3台centos7.61810虚机，1个master节点,2个node节点k8sversion：v1.22.2containerd:$kubectlgetpoapisix-etcd-0-napisix-oyaml……schedulerName:default-scheduler……#也就是k8s集群默认使用的：$kubectlgetpo-A……kube-systemkube-scheduler-master11/1Running3(27d ago) 108d

kube-scheduler的主要作用就是根据特定的调度算法和调度策略将 Pod 调度到合适的 Node 节点上去，是一个独立的二进制程序，启动之后会一直监听 API Server，获取到 **PodSpec.NodeName**为空的 Pod，对每个 Pod 都会创建一个 binding。

这个过程在我们看来好像比较简单，但在实际的生产环境中，需要考虑的问题就有很多了：

• 如何保证全部的节点调度的公平性？要知道并不是所有节点资源配置一定都是一样的
• 如何保证每个节点都能被分配资源？
• 集群资源如何能够被高效利用？
• 集群资源如何才能被最大化使用？
• 如何保证 Pod 调度的性能和效率？(假设说有1w个节点，我是否可以在其中1k个节点上进行筛选呢，这样就可以大幅度提高调度效率了😀)
• 用户是否可以根据自己的实际需求定制自己的调度策略？

🍂 调度主要分为以下几个部分：

• 首先是预选过程，过滤掉不满足条件的节点，这个过程称为 Predicates（过滤）
• 然后是优选过程，对通过的节点按照优先级排序，称之为 Priorities（打分）
• 最后从中选择优先级最高的节点，如果中间任何一步骤有错误，就直接返回错误

Predicates阶段首先遍历全部节点，过滤掉不满足条件的节点，属于强制性规则，这一阶段输出的所有满足要求的节点将被记录并作为第二阶段的输入，如果所有的节点都不满足条件，那么 Pod 将会一直处于 Pending 状态，直到有节点满足条件，在这期间调度器会不断的重试。

所以我们在部署应用的时候，如果发现有 Pod 一直处于 Pending 状态，那么就是没有满足调度条件的节点，这个时候可以去检查下节点资源是否可用。

Priorities阶段即再次对节点进行筛选，如果有多个节点都满足条件的话，那么系统会按照节点的优先级(priorites)大小对节点进行排序，最后选择优先级最高的节点来部署 Pod 应用。

01、如果你的pod处于pending状态，那么一定就是调度器出现了问题，那么原因会很多，有可能是你的node资源不足，有可能是你的节点已经被占用了……(因此需要使用kubectl describle pod xxx来查看原因)

02、所谓的bing操作就是如下： $ kubectl get po apisix-etcd-0 -napisix -oyaml …… nodeName:node2 #将pod的配置清单的nodeName字段补充完成。 ……

🍂 下面是调度过程的简单示意图：

更详细的流程是这样的：

• 首先，客户端通过 API Server 的 REST API 或者 kubectl 工具创建 Pod 资源
• API Server 收到用户请求后，存储相关数据到 etcd 数据库中
• 调度器监听 API Server 查看到还未被调度(bind)的 Pod 列表，循环遍历地为每个 Pod 尝试分配节点，这个分配过程就是我们上面提到的两个阶段：
  • 预选阶段(Predicates)，过滤节点，调度器用一组规则过滤掉不符合要求的 Node 节点，比如 Pod 设置了资源的 request，那么可用资源比 Pod 需要的资源少的主机显然就会被过滤掉。
  • 优选阶段(Priorities)，为节点的优先级打分，将上一阶段过滤出来的 Node 列表进行打分，调度器会考虑一些整体的优化策略，比如把 Deployment 控制的多个 Pod 副本尽量分布到不同的主机上，使用最低负载的主机等等策略。
• 经过上面的阶段过滤后选择打分最高的 Node 节点和 Pod 进行 binding操作，然后将结果存储到 etcd 中， 最后被选择出来的 Node 节点对应的 kubelet 去执行创建 Pod 的相关操作（当然也是 watch APIServer 发现的）。

🍂 Predicates plugin工作原理

链式过滤器

🍂 调度插件

LeastAllocated：空闲资源多的分高  --使的node上的负载比较合理一点！ MostAllocated：空闲资源少的分高  -- 可以退回Node资源！

🍀 最简单的Scheduler实现

k8s 0.2版本的一个架构图，基本调度方式就是随机，轮询会稍微复杂一些；

随机

2.扩展调度器(extender)

包括很多时候，默认的调度器已经不能满足业务需求，需要对它做自定义的扩展和实现，具体该怎么做，背后的原理又是什么样的，业界有没有优秀案例可供参考，这些都是非常令人头疼的问题。(extender本身就是一个拉低性能的因素。)

🍂 考虑到实际环境中的各种复杂情况，kubernetes 的调度器采用插件化的形式实现，可以方便用户进行定制或者二次开发，我们可以自定义一个调度器并以插件形式和 kubernetes 进行集成。

开发人员注意即可：

kubernetes 调度器的源码位于 kubernetes/pkg/scheduler中，其中 Scheduler 创建和运行的核心程序，对应的代码在 pkg/scheduler/scheduler.go，如果要查看 kube-scheduler的入口程序，对应的代码在 cmd/kube-scheduler/scheduler.go。

https:funcgetDefaultConfig() *schedulerapi.Plugins{return&schedulerapi.Plugins{QueueSort:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:queuesort.Name},},},PreFilter:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:noderesources.FitName},{Name:nodeports.Name},{Name:podtopologyspread.Name},{Name:interpodaffinity.Name},{Name:volumebinding.Name},},},Filter:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:nodeunschedulable.Name},{Name:noderesources.FitName},{Name:nodename.Name},{Name:nodeports.Name},{Name:nodeaffinity.Name},{Name:volumerestrictions.Name},{Name:tainttoleration.Name},{Name:nodevolumelimits.EBSName},{Name:nodevolumelimits.GCEPDName},{Name:nodevolumelimits.CSIName},{Name:nodevolumelimits.AzureDiskName},{Name:volumebinding.Name},{Name:volumezone.Name},{Name:podtopologyspread.Name},{Name:interpodaffinity.Name},},},PostFilter:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:defaultpreemption.Name},},},PreScore:&schedulerapi.PluginSet{#打分Enabled:[]schedulerapi.Plugin{{Name:interpodaffinity.Name},{Name:podtopologyspread.Name},{Name:tainttoleration.Name},},},Score:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:noderesources.BalancedAllocationName,Weight:1},{Name:imagelocality.Name,Weight:1},{Name:interpodaffinity.Name,Weight:1},{Name:noderesources.LeastAllocatedName,Weight:1},{Name:nodeaffinity.Name,Weight:1},{Name:nodepreferavoidpods.Name,Weight:10000},{Name:podtopologyspread.Name,Weight:2},{Name:tainttoleration.Name,Weight:1},},},Reserve:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:volumebinding.Name},},},PreBind:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:volumebinding.Name},},},Bind:&schedulerapi.PluginSet{Enabled:[]schedulerapi.Plugin{{Name:defaultbinder.Name},},},}}

从上面我们可以看出调度器的一系列算法由各种插件在调度的不同阶段来完成，下面我们就先来了解下调度框架。

调度框架定义了一组扩展点，用户可以实现扩展点定义的接口来定义自己的调度逻辑（我们称之为扩展），并将扩展注册到扩展点上，调度框架在执行调度工作流时，遇到对应的扩展点时，将调用用户注册的扩展。调度框架在预留扩展点时，都是有特定的目的，有些扩展点上的扩展可以改变调度程序的决策方法，有些扩展点上的扩展只是发送一个通知。

我们知道每当调度一个 Pod 时，都会按照两个过程来执行：调度过程和绑定过程。

调度过程为 Pod 选择一个合适的节点，绑定过程则将调度过程的决策应用到集群中（也就是在被选定的节点上运行 Pod），将调度过程和绑定过程合在一起，称之为调度上下文（scheduling context）。需要注意的是调度过程是**同步**运行的（同一时间点只为一个 Pod 进行调度），绑定过程可异步运行（同一时间点可并发为多个 Pod 执行绑定）。

调度过程和绑定过程遇到如下情况时会中途退出：

• 调度程序认为当前没有该 Pod 的可选节点
• 内部错误

这个时候，该 Pod 将被放回到 待调度队列，并等待下次重试。

1.扩展点（Extension Points）

下图展示了调度框架中的调度上下文及其中的扩展点，一个扩展可以注册多个扩展点，以便可以执行更复杂的有状态的任务。

调度阶段： 1.predicate(预选)： 2.priority/score(优选)： 绑定阶段：

🍂 详细过程：

1. QueueSort扩展用于对 Pod 的待调度队列进行排序，以决定先调度哪个 Pod，QueueSort扩展本质上只需要实现一个方法 Less(Pod1,Pod2)用于比较两个 Pod 谁更优先获得调度即可，同一时间点只能有一个 QueueSort插件生效。
2. Pre-filter扩展用于对 Pod 的信息进行预处理，或者检查一些集群或 Pod 必须满足的前提条件，如果 pre-filter返回了 error，则调度过程终止。
3. Filter扩展用于排除那些不能运行该 Pod 的节点，对于每一个节点，调度器将按顺序执行 filter扩展；如果任何一个 filter将节点标记为不可选，则余下的 filter扩展将不会被执行。调度器可以同时对多个节点执行 **filter**扩展。
4. Post-filter是一个通知类型的扩展点，调用该扩展的参数是 filter阶段结束后被筛选为可选节点的节点列表，可以在扩展中使用这些信息更新内部状态，或者产生日志或 metrics 信息。
5. Scoring扩展用于为所有可选节点进行打分，调度器将针对每一个节点调用 Soring扩展，评分结果是一个范围内的整数。在 normalize scoring阶段，调度器将会把每个 scoring扩展对具体某个节点的评分结果和该扩展的权重合并起来，作为最终评分结果。
6. Normalize scoring扩展在调度器对节点进行最终排序之前修改每个节点的评分结果，注册到该扩展点的扩展在被调用时，将获得同一个插件中的 scoring扩展的评分结果作为参数，调度框架每执行一次调度，都将调用所有插件中的一个 normalize scoring扩展一次。
7. Reserve是一个通知性质的扩展点，有状态的插件可以使用该扩展点来获得节点上为 Pod 预留的资源，该事件发生在调度器将 Pod 绑定到节点之前，目的是避免调度器在等待 Pod 与节点绑定的过程中调度新的 Pod 到节点上时，发生实际使用资源超出可用资源的情况（因为绑定 Pod 到节点上是异步发生的）。这是调度过程的最后一个步骤，Pod 进入 reserved 状态以后，要么在绑定失败时触发 Unreserve 扩展，要么在绑定成功时，由 Post-bind 扩展结束绑定过程。
8. Permit扩展用于阻止或者延迟 Pod 与节点的绑定。Permit 扩展可以做下面三件事中的一项：
   • approve（批准）：当所有的 permit 扩展都 approve 了 Pod 与节点的绑定，调度器将继续执行绑定过程
   • deny（拒绝）：如果任何一个 permit 扩展 deny 了 Pod 与节点的绑定，Pod 将被放回到待调度队列，此时将触发 Unreserve扩展。
   • wait（等待）：如果一个 permit 扩展返回了 wait，则 Pod 将保持在 permit 阶段，直到被其他扩展 approve，如果超时事件发生，wait 状态变成 deny，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展
9. Pre-bind扩展用于在 Pod 绑定之前执行某些逻辑。例如，pre-bind 扩展可以将一个基于网络的数据卷挂载到节点上，以便 Pod 可以使用。如果任何一个 pre-bind扩展返回错误，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展。
10. Bind扩展用于将 Pod 绑定到节点上：

• 只有所有的 pre-bind 扩展都成功执行了，bind 扩展才会执行
• 调度框架按照 bind 扩展注册的顺序逐个调用 bind 扩展
• 具体某个 bind 扩展可以选择处理或者不处理该 Pod
• 如果某个 bind 扩展处理了该 Pod 与节点的绑定，余下的 bind 扩展将被忽略

11. Post-bind是一个通知性质的扩展：

• Post-bind 扩展在 Pod 成功绑定到节点上之后被动调用
• Post-bind 扩展是绑定过程的最后一个步骤，可以用来执行资源清理的动作

12. Unreserve是一个通知性质的扩展，如果为 Pod 预留了资源，Pod 又在被绑定过程中被拒绝绑定，则 unreserve 扩展将被调用。Unreserve 扩展应该释放已经为 Pod 预留的节点上的计算资源。在一个插件中，reserve 扩展和 unreserve 扩展应该成对出现。

🍂 如果我们要实现自己的插件，必须向调度框架注册插件并完成配置，另外还必须实现扩展点接口，对应的扩展点接口我们可以在源码 pkg/scheduler/framework/v1alpha1/interface.go文件中找到，如下所示：

typePlugininterface{Name() string}typeQueueSortPlugininterface{PluginLess(*PodInfo,*PodInfo) bool}typePreFilterPlugininterface{PluginPreFilter(pc*PluginContext,p*v1.Pod) *Status}typeFilterPlugininterface{PluginFilter(pc*PluginContext,pod*v1.Pod,nodeNamestring) *Status}typePostFilterPlugininterface{PluginPostFilter(pc*PluginContext,pod*v1.Pod,nodes[]*v1.Node,filteredNodesStatusesNodeToStatusMap) *Status}typeScorePlugininterface{PluginScore(pc*PluginContext,p*v1.Pod,nodeNamestring) (int,*Status)}typeScoreWithNormalizePlugininterface{ScorePluginNormalizeScore(pc*PluginContext,p*v1.Pod,scoresNodeScoreList) *Status}typeReservePlugininterface{PluginReserve(pc*PluginContext,p*v1.Pod,nodeNamestring) *Status}typePreBindPlugininterface{PluginPreBind(pc*PluginContext,p*v1.Pod,nodeNamestring) *Status}typePostBindPlugininterface{PluginPostBind(pc*PluginContext,p*v1.Pod,nodeNamestring)}typeUnreservePlugininterface{PluginUnreserve(pc*PluginContext,p*v1.Pod,nodeNamestring)}typePermitPlugininterface{PluginPermit(pc*PluginContext,p*v1.Pod,nodeNamestring) (*Status,time.Duration)}typeBindPlugininterface{PluginBind(pc*PluginContext,p*v1.Pod,nodeNamestring) *Status}

🍂 对于调度框架插件的启用或者禁用，我们可以使用安装集群时的 KubeSchedulerConfiguration资源对象来进行配置。下面的例子中的配置启用了一个实现了 reserve和 preBind扩展点的插件，并且禁用了另外一个插件，同时为插件 foo 提供了一些配置信息：

apiVersion:kubescheduler.config.k8s.io/v1alpha1kind:KubeSchedulerConfiguration...plugins:reserve:enabled:- name:foo- name:bardisabled:- name:bazpreBind:enabled:- name:foodisabled:- name:bazpluginConfig:- name:fooargs:>foo插件可以解析的任意内容

🍂 扩展的调用顺序如下：

• 如果某个扩展点没有配置对应的扩展，调度框架将使用默认插件中的扩展
• 如果为某个扩展点配置且激活了扩展，则调度框架将先调用默认插件的扩展，再调用配置中的扩展
• 默认插件的扩展始终被最先调用，然后按照 KubeSchedulerConfiguration中扩展的激活 enabled顺序逐个调用扩展点的扩展
• 可以先禁用默认插件的扩展，然后在 enabled列表中的某个位置激活默认插件的扩展，这种做法可以改变默认插件的扩展被调用时的顺序

假设默认插件 foo 实现了 reserve扩展点，此时我们要添加一个插件 bar，想要在 foo 之前被调用，则应该先禁用 foo 再按照 bar foo 的顺序激活。示例配置如下所示：

apiVersion:kubescheduler.config.k8s.io/v1beta1kind:KubeSchedulerConfiguration...plugins:reserve:enabled:- name:bar- name:foodisabled:- name:foo

在源码目录 pkg/scheduler/framework/plugins/examples中有几个示范插件，我们可以参照其实现方式。

2.示例(代码部分)

因为涉及到代码部分，本次这里不做演示，看下就好。

其实要实现一个调度框架的插件，并不难，我们只要实现对应的扩展点，然后将插件注册到调度器中即可，下面是默认调度器在初始化的时候注册的插件：

funcNewRegistry() Registry{returnRegistry{}}

但是可以看到默认并没有注册一些插件，所以要想让调度器能够识别我们的插件代码，就需要自己来实现一个调度器了，当然这个调度器我们完全没必要完全自己实现，直接调用默认的调度器，然后在上面的 NewRegistry()函数中将我们的插件注册进去即可。在 kube-scheduler的源码文件 kubernetes/cmd/kube-scheduler/app/server.go中有一个 NewSchedulerCommand入口函数，其中的参数是一个类型为 Option的列表，而这个 Option恰好就是一个插件配置的定义：

typeOptionfunc(framework.Registry) errorfuncNewSchedulerCommand(registryOptions...Option) *cobra.Command{......}

所以我们完全就可以直接调用这个函数来作为我们的函数入口，并且传入我们自己实现的插件作为参数即可，而且该文件下面还有一个名为 WithPlugin的函数可以来创建一个 Option实例：

funcWithPlugin(namestring,factoryframework.PluginFactory) Option{returnfunc(registryframework.Registry) error{returnregistry.Register(name,factory)}}

所以最终我们的入口函数如下所示：

funcmain() {rand.Seed(time.Now().UTC().UnixNano())command :=app.NewSchedulerCommand(app.WithPlugin(sample.Name,sample.New),)logs.InitLogs()deferlogs.FlushLogs()iferr :=command.Execute();err !=nil{_,_ =fmt.Fprintf(os.Stderr,"%v\n",err)os.Exit(1)}}

其中 app.WithPlugin(sample.Name,sample.New)就是我们接下来要实现的插件，从 WithPlugin函数的参数也可以看出我们这里的 sample.New必须是一个 framework.PluginFactory类型的值，而 PluginFactory的定义就是一个函数：

type PluginFactory =func(configuration *runtime.Unknown,f FrameworkHandle) (Plugin,error)

所以 sample.New实际上就是上面的这个函数，在这个函数中我们可以获取到插件中的一些数据然后进行逻辑处理即可，插件实现如下所示，我们这里只是简单获取下数据打印日志，如果你有实际需求的可以根据获取的数据就行处理即可，我们这里只是实现了 PreFilter、Filter、PreBind三个扩展点，其他的可以用同样的方式来扩展即可：

constName="sample-plugin"typeArgsstruct{FavoriteColor string`json:"favorite_color,omitempty"`FavoriteNumber int`json:"favorite_number,omitempty"`ThanksTo string`json:"thanks_to,omitempty"`}typeSamplestruct{args *Argshandle framework.FrameworkHandle}func(s *Sample) Name() string{returnName}func(s *Sample) PreFilter(pc*framework.PluginContext,pod*v1.Pod) *framework.Status{klog.V(3).Infof("prefilter pod:%v",pod.Name)returnframework.NewStatus(framework.Success,"")}func(s *Sample) Filter(pc*framework.PluginContext,pod*v1.Pod,nodeNamestring) *framework.Status{klog.V(3).Infof("filter pod:%v,node:%v",pod.Name,nodeName)returnframework.NewStatus(framework.Success,"")}func(s *Sample) PreBind(pc*framework.PluginContext,pod*v1.Pod,nodeNamestring) *framework.Status{ifnodeInfo,ok :=s.handle.NodeInfoSnapshot().NodeInfoMap[nodeName];!ok {returnframework.NewStatus(framework.Error,fmt.Sprintf("prebind get node info error:%+v",nodeName))} else{klog.V(3).Infof("prebind node info:%+v",nodeInfo.Node())returnframework.NewStatus(framework.Success,"")}}funcNew(configuration*runtime.Unknown,fframework.FrameworkHandle) (framework.Plugin,error) {args :=&Args{}iferr :=framework.DecodeInto(configuration,args);err !=nil{returnnil,err}klog.V(3).Infof("get plugin config args:%+v",args)return&Sample{args:args,handle:f,},nil}

完整代码可以前往仓库 https:apiVersion:rbac.authorization.k8s.io/v1metadata:name:sample-scheduler-clusterrolerules:- apiGroups:- ""resources:- endpoints- eventsverbs:- create- get- update- apiGroups:- ""resources:- nodesverbs:- get- list- watch- apiGroups:- ""resources:- podsverbs:- delete- get- list- watch- update- apiGroups:- ""resources:- bindings- pods/bindingverbs:- create- apiGroups:- ""resources:- pods/statusverbs:- patch- update- apiGroups:- ""resources:- replicationcontrollers- servicesverbs:- get- list- watch- apiGroups:- apps- extensionsresources:- replicasetsverbs:- get- list- watch- apiGroups:- appsresources:- statefulsetsverbs:- get- list- watch- apiGroups:- policyresources:- poddisruptionbudgetsverbs:- get- list- watch- apiGroups:- ""resources:- persistentvolumeclaims- persistentvolumesverbs:- get- list- watch- apiGroups:- ""resources:- configmapsverbs:- get- list- watch- apiGroups:- "storage.k8s.io"resources:- storageclasses- csinodesverbs:- get- list- watch- apiGroups:- "coordination.k8s.io"resources:- leasesverbs:- create- get- list- update- apiGroups:- "events.k8s.io"resources:- eventsverbs:- create- patch- update---apiVersion:v1kind:ServiceAccountmetadata:name:sample-scheduler-sanamespace:kube-system---kind:ClusterRoleBindingapiVersion:rbac.authorization.k8s.io/v1metadata:name:sample-scheduler-clusterrolebindingnamespace:kube-systemroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:sample-scheduler-clusterrolesubjects:- kind:ServiceAccountname:sample-scheduler-sanamespace:kube-system---apiVersion:v1kind:ConfigMapmetadata:name:scheduler-confignamespace:kube-systemdata:scheduler-config.yaml:|apiVersion:kubescheduler.config.k8s.io/v1beta1kind:KubeSchedulerConfigurationleaderElection:leaderElect:trueleaseDuration:15srenewDeadline:10sresourceLock:endpointsleasesresourceName:sample-schedulerresourceNamespace:kube-systemretryPeriod:2sprofiles:- schedulerName:sample-schedulerplugins:preFilter:enabled:- name:"sample-plugin"filter:enabled:- name:"sample-plugin"pluginConfig:- name:sample-pluginargs:# runtime.ObjectfavorColor:"#326CE5"favorNumber:7thanksTo:"Kubernetes"---apiVersion:apps/v1kind:Deploymentmetadata:name:sample-schedulernamespace:kube-systemlabels:component:sample-schedulerspec:selector:matchLabels:component:sample-schedulertemplate:metadata:labels:component:sample-schedulerspec:serviceAccountName:sample-scheduler-sapriorityClassName:system-cluster-criticalvolumes:- name:scheduler-configconfigMap:name:scheduler-configcontainers:- name:schedulerimage:cnych/sample-scheduler:v0.2.4imagePullPolicy:IfNotPresentcommand:- sample-scheduler- --config=/etc/kubernetes/scheduler-config.yaml- --v=3volumeMounts:- name:scheduler-configmountPath:/etc/kubernetes# livenessProbe:# httpGet:# path:/healthz# port:10251# initialDelaySeconds:15# readinessProbe:# httpGet:# path:/healthz# port:10251