kube-scheduler深度剖析与开发（三）

原创

已于 2023-05-21 10:07:47 修改 · 368 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #云原生 #docker

于 2023-04-22 16:34:46 首次发布

为了深入学习 kube-scheduler，本系从源码和实战角度深度学习kube-scheduler，该系列一共分6篇文章，如下：

上一篇文章我们讲了一个 kube-scheduler 是怎么初始化出来的，有了调度器之后就得开始让他干活了这一篇文章我们来讲讲一个 Pod 是怎么被调度到某个 Node 的。

我把调度一个 Pod 分为3个阶段

获取需要被调度的 Pod
运行每个扩展点的所有插件，给 Pod 选择一个最合适的 Node
将 Pod 绑定到选出来的 Node

感知 Pod

要能够获取到 Pod 的前提是：kube-scheduler 能感知到有 Pod 需要被调度，得知有 Pod 需要被调度后还需要有地方存放被调度的 Pod 的信息。为了感知有 Pod 需要被调度，kube-scheduler 启动时通过 Informer watch Pod 的变化，它把待调度的 Pod 分了两种情况，代码如下

// pkg/scheduler/eventhandlers.go

func addAllEventHandlers(...) {
  
  //已经调度过的 Pod 则加到本地缓存，并判断是加入到调度队列还是加入到backoff队列
  informerFactory.Core().V1().Pods().Informer().AddEventHandler(
    cache.FilteringResourceEventHandler{
      FilterFunc: func(obj interface{}) bool {
        switch t := obj.(type) {
        case *v1.Pod:
          return assignedPod(t)
        case cache.DeletedFinalStateUnknown:
          if _, ok := t.Obj.(*v1.Pod); ok {
            // The carried object may be stale, so we don't use it to check if
            // it's assigned or not. Attempting to cleanup anyways.
            return true
          }
          utilruntime.HandleError(fmt.Errorf("unable to convert object %T to *v1.Pod in %T", obj, sched))
          return false
        default:
          utilruntime.HandleError(fmt.Errorf("unable to handle object in %T: %T", sched, obj))
          return false
        }
      },
      Handler: cache.ResourceEventHandlerFuncs{
        AddFunc:    sched.addPodToCache,
        UpdateFunc: sched.updatePodInCache,
        DeleteFunc: sched.deletePodFromCache,
      },
    },
  )

  // 没有调度过的Pod，放到调度队列
  informerFactory.Core().V1().Pods().Informer().AddEventHandler(
    cache.FilteringResourceEventHandler{
      FilterFunc: func(obj interface{}) bool {
        switch t := obj.(type) {
        case *v1.Pod:
          return !assignedPod(t) && responsibleForPod(t, sched.Profiles)
        case cache.DeletedFinalStateUnknown:
          if pod, ok := t.Obj.(*v1.Pod); ok {
            // The carried object may be stale, so we don't use it to check if
            // it's assigned or not.
            return responsibleForPod(pod, sched.Profiles)
          }
          utilruntime.HandleError(fmt.Errorf("unable to convert object %T to *v1.Pod in %T", obj, sched))
          return false
        default:
          utilruntime.HandleError(fmt.Errorf("unable to handle object in %T: %T", sched, obj))
          return false
        }
      },

      Handler: cache.ResourceEventHandlerFuncs{
        AddFunc:    sched.addPodToSchedulingQueue,
        UpdateFunc: sched.updatePodInSchedulingQueue,
        DeleteFunc: sched.deletePodFromSchedulingQueue,
      },
    },
  )

......
}

已经调度过的 Pod
区分是不是调度过的 Pod 是通过：len(pod.Spec.NodeName) != 0 来判断的，因为调度过的 Pod 这个字段总是会被赋予被选中的 Node 名字。但是，既然是调度过的 Pod 下面的代码中为什么还要区分：sched.addPodToCache 和 sched.updatePodInCache 呢？原因在于我们可以在创建 Pod 的时候人为给它分配一个 Node（即给 pod.Spec.NodeName 赋值），这样 kube-scheduler 在监听到该 Pod 后，判断这个 Pod 的该字段不为空就会认为这个 Pod 已经调度过了，但是这个字段不为空并不是 kube-scheduler 调度的结果，而是人为赋值的，那么 kube-scheduler 的 cache（可以参考上一篇 cache 相关的内容）中没有这个 Pod 的信息，所以就需要将 Pod 信息加入到 cache 中。至于在监听到 Pod 后 sched.addPodToCache 和 sched.updatePodInCache 哪个会被调用，这是 Informer 决定的，它会根据监听到变化的 Pod 和 Informer 的本地缓存做对比，要是缓存中没有这个 Pod，那么就调用 add 函数，否则就调用 update 函数。

加入或更新缓存后，还需要做一件事：去 unsched