深入理解k8s调度器与调度框架核心源码

k8s调度器kube-scheduler的核心实现在pkg/scheduler下

    algorithmprovider:调度算法的注册与获取功能,核心数据结构是一个字典类的结构
    apis:k8s集群中的资源版本相关的接口,和apiversion、type相关的一些内容
    core:调度器实例的核心数据结构与接口以及外部扩展机制的实现
    framework:定义了一套调度器内部扩展机制
    internal:调度器核心实例依赖的内部数据结构
    metrics:指标度量
    profile:基于framework的一套调度器的配置,用于管控整个调度器的运行框架
    testing:一些测试代码
    util:一些通用的工具

 

在pkg/scheduler/scheduler.go,定义了Scheduler:

type Scheduler struct {
    SchedulerCache internalcache.Cache
    Algorithm core.ScheduleAlgorithm
    NextPod func() *framework.QueuedPodInfo
    Error func(*framework.QueuedPodInfo, error)   //默认的调度失败处理方法
    StopEverything <-chan struct{}
    SchedulingQueue internalqueue.SchedulingQueue  //Pod的调度队列  
    Profiles profile.Map   //调度器配置
    client clientset.Interface
}

pkg/scheduler/internal/queue/scheduling_queue.go中定义了调度队列的接口SchedulingQueue:

type SchedulingQueue interface {
    framework.PodNominator
    Add(pod *v1.Pod) error
    AddUnschedulableIfNotPresent(pod *framework.QueuedPodInfo, podSchedulingCycle int64) error
    SchedulingCycle() int64
    Pop() (*framework.QueuedPodInfo, error)
    Update(oldPod, newPod *v1.Pod) error
    Delete(pod *v1.Pod) error
    MoveAllToActiveOrBackoffQueue(event string)
    AssignedPodAdded(pod *v1.Pod)
    AssignedPodUpdated(pod *v1.Pod)
    PendingPods() []*v1.Pod
    Close()
    NumUnschedulablePods() int  //不可调度的Pod数量
    Run()
}

AssignedPodAdded、AssignedPodUpdated、MoveAllToActiveOrBackoffQueue底层都会调用 movePodsToActiveOrBackoffQueue方法,主要用来设置资源(Pod、Node等)更新时的回调方法。即资源更新时,之前无法被调度的Pod,会有重试的机会。

PriorityQueue是接口的具体实现:

type PriorityQueue struct {
    framework.PodNominator  //调度的结果(Pod和Node的对应关系)
    stop chan struct{}    //外部控制队列的channel
    clock util.Clock
    podInitialBackoffDuration time.Duration    //backoff pod 初始的等待重新调度时间
    podMaxBackoffDuration time.Duration       //backoff pod 最大的等待重新调度时间
    lock sync.RWMutex
    cond sync.Cond     //并发场景下实现控制pop的阻塞
    activeQ *heap.Heap
    podBackoffQ *heap.Heap
    unschedulableQ *UnschedulablePodsMap
    schedulingCycle int64     //计数器,每pop一共pod,增加一次
    moveRequestCycle int64
    closed bool
}

其核心数据结构主要包含三个队列,高优先度的Pod排在前面。

(1)activeQ:存储所有等待调度的Pod的队列

默认是基于堆来实现,其中元素的优先级则通过对比Pod的创建时间和Pod的优先级来进行排序。

kube-scheduler发现某个Pod的nodeName是空后,就认为这个Pod处于未调度状态,将其放到调度队列里:

 

(2)podBackoffQ:存储运行失败的Pod的队列

func (p *PriorityQueue) podsCompareBackoffCompleted(podInfo1, podInfo2 interface{}) bool {
    pInfo1 := podInfo1.(*framework.QueuedPodInfo)
    pInfo2 := podInfo2.(*framework.QueuedPodInfo)
    bo1 := p.getBackoffTime(pInfo1)
    bo2 := p.getBackoffTime(pInfo2)
    return bo1.Before(bo2)
}
// getBackoffTime returns the time that podInfo completes backoff
func (p *PriorityQueue) getBackoffTime(podInfo *framework.QueuedPodInfo) time.Time {
    duration := p.calculateBackoffDuration(podInfo)
    backoffTime := podInfo.Timestamp.Add(duration)
    return backoffTime
}
 
// 计算backoff时间
func (p *PriorityQueue) calculateBackoffDuration(podInfo *framework.QueuedPodInfo) time.Duration {
    duration := p.podInitialBackoffDuration
    for i := 1; i < podInfo.Attempts; i++ {
        duration = duration * 2
        if duration > p.podMaxBackoffDuration {
            return p.podMaxBackoffDuration
        }
    }
    return duration
}

 

(3)unschedulableQ:其实是一个Map结构,存储暂时无法调度的Pod

type UnschedulablePodsMap struct {
    podInfoMap map[string]*framework.QueuedPodInfo
    keyFunc func(*v1.Pod) string
    metricRecorder metrics.MetricRecorder  //有Pod从Map中新增、删除时就会增加1
}
// 构造函数
func newUnschedulablePodsMap(metricRecorder metrics.MetricRecorder) *UnschedulablePodsMap {
    return &UnschedulablePodsMap{
        podInfoMap: make(map[string]*framework.QueuedPodInfo),
        keyFunc: util.GetPodFullName,
        metricRecorder: metricRecorder,    
    }
}

新建Scheduler的方法:

func New(client clientset.Interface,
    informerFactory informers.SharedInformerFactory,
    recorderFactory profile.RecorderFactory,
    stopCh <-chan struct{},
    opts ...Option) (*Scheduler, error) {
    stopEverything := stopCh
    if stopEverything == nil {
        stopEverything = wait.NeverStop
    }
    options := defaultSchedulerOptions    //获取默认的调度器选项,里面会给定默认的algorithmSourceProvider
    for _, opt := range opts {
        opt(&options)
    }
    schedulerCache := internalcache.New(30*time.Second, stopEverything)    //初始化调度缓存
    registry := frameworkplugins.NewInTreeRegistry()   //registry是一个字典,里面存放了插件名与插件的工厂方法
    if err := registry.Merge(options.frameworkOutOfTreeRegistry); err != nil {
        return nil, err
    }
    snapshot := internalcache.NewEmptySnapshot()
    configurator := &Configurator{    //基于配置创建configurator实例
        client:                   client,
        recorderFactory:          recorderFactory,
        informerFactory:          informerFactory,
        schedulerCache:           schedulerCache,
        StopEverything:           stopEverything,
        percentageOfNodesToScore: options.percentageOfNodesToScore,
        podInitialBackoffSeconds: options.podInitialBackoffSeconds,
        podMaxBackoffSeconds:     options.podMaxBackoffSeconds,
        profiles:                 append([]schedulerapi.KubeSchedulerProfile(nil), options.profiles...),
        registry:                 registry,
        nodeInfoSnapshot:         snapshot,
        extenders:                options.extenders,
        frameworkCapturer:        options.frameworkCapturer,
    }
    metrics.Register()
    var sched *Scheduler
    source := options.schedulerAlgorithmSource
    switch {
    case source.Provider != nil:
        // Create the config from a named algorithm provider.
        sc, err := configurator.createFromProvider(*source.Provider)
        if err != nil {
            return nil, fmt.Errorf("couldn't create scheduler using provider %q: %v", *source.Provider, err)
        }
        sched = sc
    case source.Policy != nil:
        // Create the config from a user specified policy source.
        policy := &schedulerapi.Policy{}
        switch {
        case source.Policy.File != nil:
            if err := initPolicyFromFile(source.Policy.File.Path, policy); err != nil {
                return nil, err
            }
        case source.Policy.ConfigMap != nil:
            if err := initPolicyFromConfigMap(client, source.Policy.ConfigMap, policy); err != nil {
                return nil, err
            }
        }
        // Set extenders on the configurator now that we've decoded the policy
        // In this case, c.extenders should be nil since we're using a policy (and therefore not componentconfig,
        // which would have set extenders in the above instantiation of Configurator from CC options)
        configurator.extenders = policy.Extenders
        sc, err := configurator.createFromConfig(*policy)
        if err != nil {
            return nil, fmt.Errorf("couldn't create scheduler from policy: %v", err)
        }
        sched = sc
    default:
        return nil, fmt.Errorf("unsupported algorithm source: %v", source)
    }
    // Additional tweaks to the config produced by the configurator.
    sched.StopEverything = stopEverything
    sched.client = client
    addAllEventHandlers(sched, informerFactory)
    return sched, nil
}
addAllEventHandlers方法会启动所有资源对象的事件监听,例如,新生成的Pod,spec.nodeName为空且状态是pending。kube-Scheduler会watch到这个Pod的生成事件。

 

kube-scheduler的调度流程为:

(1)Cobra命令行参数解析

通过options.NewOptions函数初始化各个模块的默认配置,例如HTTP或HTTPS服务等。

通过options.Validate函数验证配置参数的合法性和可用性

 

kube-scheduler启动时通过–config <filename>指定配置文件

对默认配置启动的调度器,可以用 –write-config-to把默认配置写到一个指定文件里面。

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
  provider: DefaultProvider
percentageOfNodesToScore: 0
schedulerName: default-scheduler
bindTimeoutSeconds: 600
clientConnection:
  acceptContentTypes: ""
  burst: 100
  contentType: application/vnd.kubernetes.protobuf
  kubeconfig: ""
  qps: 50
disablePreemption: false
enableContentionProfiling: false
enableProfiling: false
hardPodAffinitySymmetricWeight: 1
healthzBindAddress: 0.0.0.0:10251
leaderElection:
  leaderElect: true
  leaseDuration: 15s
  lockObjectName: kube-scheduler
  lockObjectNamespace: kube-system
  renewDeadline: 10s
  resourceLock: endpoints
  retryPeriod: 2s
metricsBindAddress: 0.0.0.0:10251
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

algorithmSource:算法提供者,即调度器配置(过滤器、打分器等一些配置文件的格式),目前提供三种方式:

Provider(DefaultProvider优先打散、ClusterAutoscalerProvider优先堆叠)、file、configMap

percentageOfNodesToscore:控制Node的取样规模;

SchedulerName:调度器名称,默认名称是default-scheduler;

bindTimeoutSeconds:Bind阶段的超时时间

ClientConnection:配置跟kube-apiserver交互的一些参数配置。比如contentType是用来跟kube-apiserver交互的序列化协议,这里指定为protobuf;

disablePreemption:关闭抢占协议;

hardPodAffinitySymnetricweight:配置PodAffinity和NodeAffinity的权重是多少。

profiles:可以定义多个。Pod通过spec.schedulerName指定使用的调度器(默认调度器是default-scheduler)

 

 

将cc对象(kube-scheduler组件的运行配置)传入cmd/kube-scheduler/app/server.go中的Run函数,Run函数定义了kube-scheduler组件启动的逻辑,它是一个运行不退出的常驻进程

(1)Configz registration

if cz, err := configz.New("componentconfig"); err == nil {       
    cz.Set(cc.ComponentConfig)
} else {
    return fmt.Errorf("unable to register configz: %s", err)
}

(2)运行EventBroadcaster事件管理器。

cc.EventBroadcaster.StartRecordingToSink(ctx.Done())

(3)运行HTTP服务

/healthz:用于健康检查

var checks []healthz.HealthChecker       // 设置健康检查
if cc.ComponentConfig.LeaderElection.LeaderElect {
    checks = append(checks, cc.LeaderElection.WatchDog)
}
if cc.InsecureServing != nil {    
    separateMetrics := cc.InsecureMetricsServing != nil
    handler := buildHandlerChain(newHealthzHandler(&cc.ComponentConfig, separateMetrics, checks...), nil, nil)
    if err := cc.InsecureServing.Serve(handler, 0, ctx.Done()); err != nil {
        return fmt.Errorf("failed to start healthz server: %v", err)
    }
}
var checks []healthz.HealthChecker
if cc.ComponentConfig.LeaderElection.LeaderElect {
    checks = append(checks, cc.LeaderElection.WatchDog)
}

/metrics:用于监控指标,一般用于Prometheus指标采集

if cc.InsecureMetricsServing != nil {
    handler := buildHandlerChain(newMetricsHandler(&cc.ComponentConfig), nil, nil)
    if err := cc.InsecureMetricsServing.Serve(handler, 0, ctx.Done()); err != nil {
        return fmt.Errorf("failed to start metrics server: %v", err)
    }
}

(4)运行HTTPS服务

if cc.SecureServing != nil {
    handler := buildHandlerChain(newHealthzHandler(&cc.ComponentConfig, false, checks...), cc.Authentication.Authenticator, cc.Authorization.Authorizer)
    // TODO: handle stoppedCh returned by c.SecureServing.Serve
    if _, err := cc.SecureServing.Serve(handler, 0, ctx.Done()); err != nil {
    // fail early for secure handlers, removing the old error loop from above
    return fmt.Errorf("failed to start secure server: %v", err)
    }
}

(5)实例化所有的Informer,运行所有已经实例化的Informer对象

包括Pod、Node、PV、PVC、SC、CSINode、PDB、RC、RS、Service、STS、Deployment

cc.InformerFactory.Start(ctx.Done())
cc.InformerFactory.WaitForCacheSync(ctx.Done())   // 等待所有运行中的Informer的数据同步到本地

(6)参与选主:

if cc.LeaderElection != nil {     //需要参与选主
    cc.LeaderElection.Callbacks = leaderelection.LeaderCallbacks{
        OnStartedLeading: func(ctx context.Context) {
            close(waitingForLeader)
            sched.Run(ctx)
        },
        OnStoppedLeading: func() {
            klog.Fatalf("leaderelection lost")
        },
    }
    leaderElector, err := leaderelection.NewLeaderElector(*cc.LeaderElection)  //实例化LeaderElector对象
        if err != nil {
            return fmt.Errorf("couldn't create leader elector: %v", err)
        }
    leaderElector.Run(ctx)    //调用client-go中tools/leaderelection/leaderelection.go中的Run()参与领导选举
    return fmt.Errorf("lost lease")
}

LeaderCallbacks中定义了两个回调函数:

OnStartedLeading函数是当前节点领导者选举成功后回调的函数,定义了kube-scheduler组件的主逻辑;

OnStoppedLeading函数是当前节点领导者被抢占后回调的函数,会退出当前的kube-scheduler协程。

 

 

(7)运行sched.Run调度器。

sched.Run(ctx)

其运行逻辑为:

func (sched *Scheduler) Run(ctx context.Context) {
    sched.SchedulingQueue.Run()
    wait.UntilWithContext(ctx, sched.scheduleOne, 0)
    sched.SchedulingQueue.Close()
}

首先调用了pkg/scheduler/internal/queue/scheduling_queue.go中PriorityQueue的Run方法:

func (p *PriorityQueue) Run() { 
    go wait.Until(p.flushBackoffQCompleted, 1.0*time.Second, p.stop) 
    go wait.Until(p.flushUnschedulableQLeftover, 30*time.Second, p.stop)

其逻辑为:

每隔1秒,检测backoffQ里是否有pod可以被放进activeQ里

每隔30秒,检测unschedulepodQ里是否有pod可以被放进activeQ里(默认条件是等待时间超过60 秒)

然后调用了sched.scheduleOne,它是kube-scheduler组件的调度主逻辑,通过wait.Until定时器执行,内部会定时调用sched.scheduleOne函数,当sched.config.StopEverythingChan关闭时,该定时器才会停止并退出。

kube-scheduler首先从activeQ里pop一个等待调度的Pod出来,并从NodeCache里拿到相关的Node数据

NodeCache横轴为zoneIndex(即Node按照zone进行分堆,从而保证拿到的Node按zone打散),纵轴为nodeIndex。

在filter阶段,每pop一个node进行过滤,zoneIndex往后自增一个位置,然后从该zone的node列表中取一个Node出来(如果当前zone的无Node,就会从下一个zone拿),取出后nodeIndex也要往后自增一个位置。

 

根据取样比例判断Filter到的Node是否足够。如果取样的规模已经达到了设置的取样比例,Filter就会结束。

取样比例通过percentageOfNodesToScore(0~100)设置

当集群中的可调度节点少于50个时,调度器仍然会去检查所有的Node

若不设置取样比例,默认的比例会随着节点数量的增多不断降低(最低到5%)

 

Scheduling Framework是一种可插入的架构,在原有的调度流程中定义了丰富的扩展点(extention point)接口

开发者可以通过实现扩展点所定义的接口来实现插件,从而将自身的调度逻辑集成到Scheduling Framework中。

 

pkg/scheduler/framework/plugins/names/names.go中记载了所有自带插件的插件名
需要启用的在pkg/scheduler/algorithmprovider/registry.go中进行注册

 

Scheduling Framework在执行调度流程运行到相应的扩展点时,会调用用户注册的插件,影响调度决策的结果。

核心调度流程在pkg/scheduler/core/generic_scheduler.go:

func (g *genericScheduler) Schedule(ctx context.Context, fwk framework.Framework, state *framework.CycleState, pod *v1.Pod) (result ScheduleResult, err error) {
    trace := utiltrace.New("Scheduling", utiltrace.Field{Key: "namespace", Value: pod.Namespace}, utiltrace.Field{Key: "name", Value: pod.Name})
    defer trace.LogIfLong(100 * time.Millisecond)
    if err := g.snapshot(); err != nil {
        return result, err
    }
    trace.Step("Snapshotting scheduler cache and node infos done")
    if g.nodeInfoSnapshot.NumNodes() == 0 {
        return result, ErrNoNodesAvailable
    }
    feasibleNodes, filteredNodesStatuses, err := g.findNodesThatFitPod(ctx, fwk, state, pod)
    if err != nil {
        return result, err
    }
    trace.Step("Computing predicates done")
    if len(feasibleNodes) == 0 {
        return result, &FitError{
            Pod:                   pod,
            NumAllNodes:           g.nodeInfoSnapshot.NumNodes(),
            FilteredNodesStatuses: filteredNodesStatuses,
        }
    }
    // When only one node after predicate, just use it.
    if len(feasibleNodes) == 1 {
        return ScheduleResult{
            SuggestedHost:  feasibleNodes[0].Name,
            EvaluatedNodes: 1 + len(filteredNodesStatuses),
            FeasibleNodes:  1,
        }, nil
    }
    priorityList, err := g.prioritizeNodes(ctx, fwk, state, pod, feasibleNodes)
    if err != nil {
        return result, err
    }
    host, err := g.selectHost(priorityList)
    trace.Step("Prioritizing done")
    return ScheduleResult{
        SuggestedHost:  host,
        EvaluatedNodes: len(feasibleNodes) + len(filteredNodesStatuses),
        FeasibleNodes:  len(feasibleNodes),
    }, err
}

下面为Scheduling Framework全流程,灰色插件默认不启用:

1、scheduling cycle

scheduling cycle是调度的核心流程,主要进行调度决策,挑选出唯一的节点。

scheduling cycle是同步执行的,同一个时间只有一个scheduling cycle,是线程安全的

 

 

扩展点1:Sort

用于排序调度队列中的Pod,接口只定义了一个函数Less,用于堆排序待调度Pod时进行比较

type QueueSortPlugin interface {
    Plugin
    Less(*PodInfo, *PodInfo) bool   
}

比较函数在同一时刻只有一个,所以Sort插件只能Enable一个,如果用户Enable了2个则调度器启动时会报错退出

  • PrioritySort:首先比较优先级,然后再比较timestamp:
type PrioritySort struct{}
func (pl *PrioritySort) Less(pInfo1, pInfo2 *framework.QueuedPodInfo) bool {
    p1 := corev1helpers.PodPriority(pInfo1.Pod)
    p2 := corev1helpers.PodPriority(pInfo2.Pod)
    return (p1 > p2) || (p1 == p2 && pInfo1.Timestamp.Before(pInfo2.Timestamp))
}
func PodPriority(pod *v1.Pod) int32 {
    if pod.Spec.Priority != nil {
        return *pod.Spec.Priority
    }
    return 0
}

预选阶段先并发运行PreFilter,只有当所有的PreFilter插件都返回success 时,才能进入Filter阶段,否则Pod将会被拒绝掉,标识此次调度流程失败;再并发运行Filter的所有插件,每个Node只要被任一Filter插件认为不满足调度要求就会被滤除。

为了提升效率,执行顺序可以被配置,这样用户就可以将过滤掉大量节点的策略(例如NodeSelector的Filter)放到前边执行,从而减少后边Filter策略执行的次数

扩展点2:PreFilter

PreFilter是调度流程启动之前的预处理,可以进行Pod信息的加工、集群或Pod必须满足的预置条件的检查等。

  • NodeResourcesFit
  • NodePorts
  • PodTopologySpread
  • InterPodAffinity
  • VolumeBinding:检查Pod挂载的PVC,如果其对应SC的VolumeBindingMode是Immediate模式,该PVC必须已经是bound,否则需要返回UnschedulableAndUnresolvable
  • NodeAffinity
  • ServiceAffinity

 

扩展点3:Filter

  • NodeUnschedulable:Node是否不允许调度
  • NodeResourcesFit:检查节点是否有Pod运行所需的资源
  • Nodename:Node是否符合Pod在spec.nodeSelector中的要求
  • NodePorts:若Pod定义了Ports.hostPort属性,则检查其值指定的端口是否已经被节点上其他容器或服务占用
  • NodeAffinity:Pod和Node的亲和和反亲和调度
  • VolumeRestrictions:检查挂载该Node上的卷是否满足存储提供者的要求
  • TainttToleration:检查Pod Tolerates和Node Taints是否匹配
  • NodeVolumeLimits、 EBSLimits、 GCEPDLimits、 AzureDiskLimits、 CinderVolume:校验PVC指定的Provision在CSI plugin或非CSI Plugin(后三个)上报的单机最大挂盘数(存储插件提供方一般对每个节点的单机最大挂载磁盘数是有限制的)
  • VolumeBinding:检查Pod挂载的PVC,如果其是bound状态,检查节点是否满足PV的拓扑要求;如果还没有bound,检查节点是否能有满足拓扑、存储空间要求的PV
  • VolumeZone:检查检查PV的Label,如果定义了zone的信息,则必须和Node的zone匹配
  • PodTopologySpread:检查Pod的拓扑逻辑
  • InterPodaffinity:检查Pod间的亲和、反亲和逻辑
  • NodeLabel
  • ServiceAffinity

 

扩展点4:PostFilter

主要用于处理Pod在Filter阶段失败后的操作,如抢占、Autoscale触发等。

  • DefaultPreemption:当高优先级的Pod没有找到合适的Node时,会执行Preempt抢占算法,抢占的流程:

 

①一个Pod进入抢占的时候,首先会判断Pod是否拥有抢占的资格,有可能上次已经抢占过一次。

②如果符合抢占资格,会先对所有的节点进行一次过滤,过滤出符合这次抢占要求的节点。然后

③模拟一次调度,把优先级低的Pod先移除出去,再尝试能否把待抢占的Pod放置到此节点上。然后通过这个过程从过滤剩下的节点中选出一批节点进行抢占。

④ProcessPreemptionWithExtenders是一个扩展的钩子,用户可以在这里加一些自己抢占节点的策略。如果没有扩展的钩子,这里面不做任何动作。

⑤PickOneNodeForPreemption,从上面选出的节点里挑选出最合适的一个节点,策略包括:

优先选择打破PDB最少的节点;

其次选择待抢占Pods中最大优先级最小的节点;

再次选择待抢占Pods优先级加和最小的节点;

接下来选择待抢占Pods数目最小的节点;

最后选择拥有最晚启动Pod的节点;

通过过滤之后,会选出一个最合适的节点。对这个节点上待抢占的Pod进行delete,完成抢占过程。

扩展点5:PreScore

获取到通过Filter阶段的节点列表后,进行一些信息预处理、生成日志或者监控信息。
  • SelectorSpread
  • InterPodaffinity
  • PodTopologySpread
  • TaintToleration

 

扩展点6:Score

对Filter过滤后的剩余节点进行打分。
  • SelectorSpread
  • NodeResourcesBalancedAllocation:碎片率(CPU 的使用比例和内存使用比例的差值)={ 1 – Abs[CPU(Request / Allocatable) – Mem(Request / Allocatable)] } * Score。如果这个差值越大,就表示碎片越大,优先不分配到这个节点上。
  • NodeResourcesLeastAllocated:优先打散,公式是 (Allocatable – Request) / Allocatable * Score
  • ImageLocality:如果节点里面存在镜像的话,优先把Pod调度到这个节点上。这里还会去考虑镜像的大小,会按照节点上已经存在的镜像大小优先级亲和
  • InterPodaffinity
  • NodeAffinity
  • NodePreferAvoidpods
  • PodTopologySpread:权重为2(因为是用户指定的)
  • TaintToleration
  • NodeResourcesMostAllocated:优先堆叠,公式是Request / Allocatable * Score
  • RequestedToCapacityRatio:指定比率。用户指定配置参数可以指定不同资源使用比率的分数,从而达到控制集群上每个节点上pod的分布。
  • nodeLabel
  • ServiceAffinity:替换了曾经的SelectorSpreadPriority(因为Service代表一组服务,只要能做到服务的打散分配就足够了)。

 

扩展点7:NormalizeScore

标准化完成后,Scheduler会综合PreScore+Score所有插件的打分。

 

扩展点8:Reserve

分配Pod到Node的时候,需要进行账本预占(Reserve),将调度结果放到调度缓存(Schedule Cache)。预占的过程会把Pod的状态标记为Assumed(处于内存态)、在Node的状态中添加该Pod的数据账本。
  • volumebinding:调用AssumePodVolumes方法,更改调度缓存中已经Match的PV的annotation[pv.kubernetes.io/bound-by-controller]=”yes”和未匹配到PV的PVC的 annotation[volume.kubernetes.io/selected-node]=所选节点。最后更改调度缓存中Pod的.spec.nodeName。
PS:未来可能会将UnReserve与Reserve统一到一起,即要求开发者在实现Reserve的同时定义UnReserve,保证数据能够有效的清理,避免留下脏数据

扩展点9:Permit

Pod在Reserve阶段完成资源预留后、Bind操作前,开发者可以定义自己的策略在Permit阶段进行拦截,根据条件对Pod进行 allow(允许Pod通过Permit阶段)、reject(Pod调度失败)和wait(可设置超时时间)这3种操作。
Schedule Theread周而复始的从activeQ拿出Pod,进入scheduling cycle的调度流水线。
scheduling cycle结束后,这个Pod会异步交给Wait Thread,Wait Thread如果等待成功了,就会交给binding cycle

 

2、Binding cycle

扩展点10:prebind
  • VolumeBinding:将之前Reserve阶段的volumebinding实际更新到apiserver中,等待PV Controller完成binding。最终所有PV都处于bound状态且NodeAffinity得到满足。

 

 

扩展点11:bind

进行最后实际的绑定,更新Pod和Node的数据
  • DefaultBinder

选中的节点在和待调度Pod进行Bind的时候,有可能会Bind失败,此时需要做回退,把Pod的Assumed状态退回Initial,从Node里面把Pod数据账本擦除掉,会把Pod重新丢回到unschedulableQ队列里面。在unschedulableQ里,如果一个Pod一分钟没调度过,就会重新回到activeQ。它的轮询周期是30s。

调度失败的Pod会放到backoffQ,在backoffQ里等待的时间会比在unschedulableQ里更短,backoffQ里的降级策略是2的指数次幂降级。假设重试第一次为1s,那第二次就是2s,第三次就是4s,但最大到10s。

 

最终,某个Node上的kubelet会watch到这个Pod属于自己所在的节点。kubelet会在节点上创建Pod,包括创建容器storage、network。等所有的资源都准备完成,kubelet会把Pod状态更新为Running

参考资料:

[1] https://kubernetes.io/docs/home/

[2] https://edu.aliyun.com/roadmap/cloudnative

[3] 郑东旭《Kubernetes源码剖析》

发表评论