[k8s源码分析][kube-scheduler]scheduler之启动run(2)

1. 前言

转载请说明原文出处, 尊重他人劳动成果!

在前文[k8s源码分析][kube-scheduler]scheduler之启动run(1)分析了kube-scheduler启动的流程, 本文将在其基础上继续分析各种informers的操作,将主要涉及pkg/scheduler/factory/factory.go文件.

因为在分析scheduling_queue的时候在[k8s源码分析][kube-scheduler]scheduler/internal/queue之优先队列scheduling_queue(2)就已经对此有所涉及, 但是当时主要只是涉及了podQueue, 所以本文将基于该文的基础上进行分析并主要关注与schedulerCache相关的操作, 对于一些重复的对象就不多说了.
所以关于cache部分可以参考[k8s源码分析][kube-scheduler]scheduler/internal/cache之node_tree和cache

源码位置: https://github.com/nicktming/kubernetes
分支: tming-v1.13 (基于v1.13版本)

2. NewConfigFactory

pkg/scheduler/factory/factory.go中的NewConfigFactory方法中添加了很多informersEventHandler.

3. PodInformer(scheduled pod cache)

是针对那些已经调度成功的pod.

func (c *configFactory) addPodToCache(obj interface{}) {
    pod, ok := obj.(*v1.Pod)
    ...
    if err := c.schedulerCache.AddPod(pod); err != nil {
        klog.Errorf("scheduler cache AddPod failed: %v", err)
    }
    ...
}

总结: 每当中有一个已调度成功的pod添加到集群时, 就会被缓存到c.schedulerCache中, 也就是会存到sched.Config.schedulerCache中并且为Added状态

func (c *configFactory) updatePodInCache(oldObj, newObj interface{}) {
    oldPod, ok := oldObj.(*v1.Pod)
    if !ok {
        klog.Errorf("cannot convert oldObj to *v1.Pod: %v", oldObj)
        return
    }
    newPod, ok := newObj.(*v1.Pod)
    if !ok {
        klog.Errorf("cannot convert newObj to *v1.Pod: %v", newObj)
        return
    }
    if err := c.schedulerCache.UpdatePod(oldPod, newPod); err != nil {
        klog.Errorf("scheduler cache UpdatePod failed: %v", err)
    }
       // 这个是equivlance部分 可以先不管 因为不影响
    c.invalidateCachedPredicatesOnUpdatePod(newPod, oldPod)
    c.podQueue.AssignedPodUpdated(newPod)
}

总结: 每当中有一个已调度成功的pod更新时, 对应的在sched.Config.schedulerCache也会更新, 并且状态还是Added

func (c *configFactory) deletePodFromCache(obj interface{}) {
    ...
    if err := c.schedulerCache.RemovePod(pod); err != nil {
        klog.Errorf("scheduler cache RemovePod failed: %v", err)
    }
    ...
}

总结: 每当中有一个已调度成功的pod被删除时, 对应的在sched.Config.schedulerCache也会删除该pod

4. PodInformer(unscheduled pod queue)

因为进入到该Handlerpod都是等待调度的, 所以无论是增加更新删除, schedulerCache都没有什么操作.

5. NodeInformer

func (c *configFactory) addNodeToCache(obj interface{}) {
    node, ok := obj.(*v1.Node)
    if !ok {
        klog.Errorf("cannot convert to *v1.Node: %v", obj)
        return
    }
    ...
    if err := c.schedulerCache.AddNode(node); err != nil {
        klog.Errorf("scheduler cache AddNode failed: %v", err)
    }
    ...
}
func (c *configFactory) updateNodeInCache(oldObj, newObj interface{}) {
    oldNode, ok := oldObj.(*v1.Node)
    if !ok {
        klog.Errorf("cannot convert oldObj to *v1.Node: %v", oldObj)
        return
    }
    newNode, ok := newObj.(*v1.Node)
    if !ok {
        klog.Errorf("cannot convert newObj to *v1.Node: %v", newObj)
        return
    }

    ...
    if err := c.schedulerCache.UpdateNode(oldNode, newNode); err != nil {
        klog.Errorf("scheduler cache UpdateNode failed: %v", err)
    }

    ...
}
func (c *configFactory) deleteNodeFromCache(obj interface{}) {
    var node *v1.Node
    switch t := obj.(type) {
    case *v1.Node:
        node = t
    case cache.DeletedFinalStateUnknown:
        var ok bool
        node, ok = t.Obj.(*v1.Node)
        if !ok {
            klog.Errorf("cannot convert to *v1.Node: %v", t.Obj)
            return
        }
    default:
        klog.Errorf("cannot convert to *v1.Node: %v", t)
        return
    }
    ...
    if err := c.schedulerCache.RemoveNode(node); err != nil {
        klog.Errorf("scheduler cache RemoveNode failed: %v", err)
    }
    ...
}

总结: 可以看到每当集群中有新节点加入/更新/删除时, sched.Config.schedulerCache也会增加/更新/删除该节点

6. pvInformer pvcInformer serviceInformer

这些informersschedulerCache没有影响.

7. 总结

本文主要是分析了一些informersschedulerCache的影响. 与[k8s源码分析][kube-scheduler]scheduler/internal/queue之优先队列scheduling_queue(2)会更完整.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容