摘要：代碼的組織結構中，仍然是作為一個放在代碼中，在根目錄下的目錄中，目錄是其編譯入口，目錄是其主要核心代碼。而如果通過指定啟動，參數中的算法都來自的方法。登記時會提供自己本身包含的兩類算法的集合。

1.9中，kube-scheduler仍然是作為一個“plugin”放在k8s代碼中，在k8s根目錄下的plugin目錄中，cmd/kube-scheduler目錄是其編譯入口，pkg/scheduler目錄是其主要核心代碼。如圖：

在即將發布的1.10中，社區將kube-scheduler從plugin中移出，嵌入到與api-server、kubelet等組件平級的目錄。也即根目錄下的cmd、pkg目錄：

調度器可以在啟動時指定其算法的來源。算法來源有三種：a)本地policy文件；b)policy configMap；c)指定提供者。

對象*scheduler.Config記錄了算法來源，當啟動參數中policy相關參數不為空時，會從相應的文件或者configMap中讀取調度策略；否則檢查algorithm-provider參數，這個參數會列出當前可用的provider，如果沒有明確指定，那么代碼將啟動默認的provider：default

從policy讀取的調度策略，其內容是一個policy結構

type Policy struct {
     metav1.TypeMeta
       // Holds the information to configure the fit predicate functions
     Predicates []PredicatePolicy
       // Holds the information to configure the priority functions
     Priorities []PriorityPolicy
       // Holds the information to communicate with the extender(s)
     ExtenderConfigs []ExtenderConfig
       // RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule
 // corresponding to every RequiredDuringScheduling affinity rule.
 // HardPodAffinitySymmetricWeight represents the weight of implicit PreferredDuringScheduling affinity rule, in the range 1-100.
     HardPodAffinitySymmetricWeight int32
}

代碼會直接根據policy的內容，調用CreateFromKeys 方法去構建最終的scheduler

當沒有指定policy時，如果沒有指定provider，最后會執行下面這個函數

// Create creates a scheduler with the default algorithm provider.
func (f *configFactory) Create() (*scheduler.Config, error) {
    return f.CreateFromProvider(DefaultProvider)
}

隨后也會調用CreateFromKeys 方法構建最終的genericScheduler

上面的過程中，會最終都調用到func (f *configFactory) CreateFromKeys。 這個函數將參數中的predicate算法、priority算法等注入到調用鏈中，這個調用鏈中的函數，會在每次調度pod時被調用。兩個調用鏈分別是genericScheduler結構中的：

type genericScheduler struct {
    ...
    predicates            map[string]algorithm.FitPredicate
    ...
    prioritizers          []algorithm.PriorityConfig
    ...
}

當通過policy啟動時，CreateFromKeys 方法的參數中的算法都記錄到了policy對象中的成員變量里。而如果通過指定provider啟動，參數中的算法都來自provider 的init方法。

我們通過閱讀provider的init方法，以及init過程中引用到的plugins.go的一些方法，就能知道大概的流程是：

1.調度器的algorithmprovider目錄下存放了一個defaults provider，以及一個plugins.go的文件，plugins.go提供了provider登記需要的一些方法。

2.plugins.go 中維護了一個全局的map：algorithmProviderMap， 這個map的key即provider的名字，value是一個結構,維護了兩個string集合，用于記錄該provider需要的prodicate算法名和priority算法名:

type AlgorithmProviderConfig struct {

FitPredicateKeys     sets.String
PriorityFunctionKeys sets.String

}
3.provider的init方法中調用factory.RegisterAlgorithmProvider方法，向上文的map中登記自己。登記時會提供自己本身包含的兩類算法的集合。可參考defaults/defaults.go 中的：

registerAlgorithmProvider(defaultPredicates(), defaultPriorities())

defaultPredicates()、defaultPriorities()兩個函數返回的就是兩個集合，只有集合中的字符串對應的算法才會注入到genericScheduler ，從而被調用。而這里字符串和真實算法function的映射關系，分別記錄在兩個全局map：

fitPredicateMap 和priorityFunctionMap中，defaults.go中 調用的RegisterFitPredicate、RegisterMandatoryFitPredicate等許多方法均會將算法名和算法方法的映射記錄到map中。

這里注意到，并不是所有的算法都會登記到集合中的，這里PodFitsPorts、PodFitsHostPorts、PodFitsResources等算法只是記錄到map中，并沒有登記到set中，但是也被調用了，這是因為這些算法都屬于GeneralPredicates算法，在GeneralPredicates算法中被調用。而代碼中下文我們會看到在default provider 中登記了GeneralPredicates算法

總結下來就是：要將predicate算法或prioirity算法的映射關系注冊到全局map中，然后將算法名登記到provider中，再將provider登記到全局map中，在啟動scheduler時指定provider的name，就可以使用相應的provider名下登記的算法來構造genericScheduler。

上文中提及的plugins.go中， 還提供了一些額外的方法，比如：InsertPredicateKeyToAlgoProvider方法，可以將某個算法登記到指定的provider中。

因此，我們只要在init時將自定義的算法先注冊到全局map中：

func init() {
   factory.RegisterFitPredicate("PodFitsNeteaseResources", predicates.PodFitsNeteaseResources))
}

然后在defaults/defaults.go 的init方法尾部，調用InsertPredicateKeyToAlgoProvider將帶有自定義算法的名字的set加入default provider即可:

factory.InsertPredicateKeyToAlgoProvider(factory.DefaultProvider, sets.NewString("PodFitsNeteaseResources"))

上述是一個比較規范的注冊方式，也有投機取巧的方式，比如在default provider 的func defaultPredicates() 方法尾部增加一行：

factory.RegisterFitPredicate("PodFitsNeteaseResources", predicates.PodFitsNeteaseResources))