p3

README.md

@@ -1,6 +1,10 @@
 ## 前言
 在熟悉kubernetes及常用组件、插件的管理使用后，总还觉得差了些什么，不够通透，是时候来读一读源码了，结合代码与实际使用场景来互相印证，有助于对kubernetes的理解更为透彻。这里将会分多篇介绍kubernetes各核心组件的工作模式、调度管理算法等。
-注:本系列文章，全部基于最近部署的v1.14.3版本的源码
+
+
+## 版本
+
+Kubernetes v1.14.3 ,最新部署的一套环境是此版本，代码版本保持一致，方便后续测试调试
 
 ## 核心组件
 - [Scheduler](https://github.com/yinwenqin/kubeSourceCodeNote/tree/master/scheduler)
@@ -44,5 +48,5 @@ Kubernetes这一整个项目颇为庞大，一般情况下，如果熟悉kuberne
 1.官方开发者向导md文档: https://github.com/kubernetes/community/tree/master/contributors/devel
 
 2.http://hutao.tech/k8s-source-code-analysis/
- 
+
  

scheduler/P2-调度器框架.md

@@ -1,4 +1,4 @@
-调度器框架
+# 调度器框架
 
 ## 前言
 
@@ -10,7 +10,7 @@
 
 ## 框架流程
 
-让回到我们上一篇篇末找到的调度逻辑入口位置，`pkg/scheduler/scheduler.go:435`, `scheduleOne()`函数内部，定位在`pkg/scheduler/scheduler.go:457`位置,是通过这个`sched.schedule(pod)`方法来获取与pod匹配的node的，我们直接跳转2次,来到了这里`pkg/scheduler/core/generic_scheduler.go:107`
+回顾上一篇篇末，我们找到了调度框架的实际调度工作逻辑的入口位置，`pkg/scheduler/scheduler.go:435`, `scheduleOne()`函数内部，定位在`pkg/scheduler/scheduler.go:457`位置,是通过这个`sched.schedule(pod)`方法来获取与pod匹配的node的，我们直接跳转2次,来到了这里`pkg/scheduler/core/generic_scheduler.go:107`
 
 ![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/schedule.jpg)
 
@@ -22,7 +22,29 @@
 
 ![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/genericSchedule.jpg)
 
-本篇我们不看Schedule方法内的具体调度算法细节，先来逆向回溯代码结构，找到哪里创建了scheduler，调度器的默认初始化配置，默认的调度算法来源等等框架相关的东西。`Schedule()`方法属于`genericScheduler`结构体，先查看`genericScheduler`结构体，再选中结构体名称，crtl + b组合键查看它在哪些地方被引用，找出创建结构体的位置:
+这个函数里面有4个重要的步骤:
+
+```go
+// 调度前预先检查pvc是否创建
+pkg/scheduler/core/generic_scheduler.go:166
+err := podPassesBasicChecks(pod, g.pvcLister)
+
+// 根据Predicate筛选node
+pkg/scheduler/core/generic_scheduler.go:184
+filteredNodes, failedPredicateMap, err := g.findNodesThatFit(pod, nodes)
+
+// 给筛选出的node排出优先级
+pkg/scheduler/core/generic_scheduler.go:215
+ PrioritizeNodes(pod, g.nodeInfoSnapshot.NodeInfoMap, metaPrioritiesInterface, g.prioritizers, filteredNodes, g.extenders)
+
+// 选出优先级最高的node作为fit node
+pkg/scheduler/core/generic_scheduler.go:226
+g.selectHost(priorityList)
+```
+
+本篇我们不看Schedule方法内的具体调度算法细节，在这里标记一下，下一篇我们将从这里开始.
+
+先来逆向回溯代码结构，找到哪里创建了scheduler，调度器的默认初始化配置，默认的调度算法来源等等框架相关的东西。`Schedule()`方法属于`genericScheduler`结构体，先查看`genericScheduler`结构体，再选中结构体名称，crtl + b组合键查看它在哪些地方被引用，找出创建结构体的位置:
 
 ![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/createGenSche.jpg)
 
@@ -60,4 +82,202 @@
 
 ![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/memPressure.jpg)
 
-`CheckNodeMemoryPressure`这个词相应熟悉kubernetes pod的朋友一定不会陌生，在node内存压力大无法调度的pod时，`kubectl describe pod xxx`就会在状态信息里面看到这个关键词。同时，该变量的定义位于`pkg/scheduler/algorithm/predicates/predicates.go:102`，`pkg/scheduler/algorithm/`这个目录在调度器的总览中已经讲过是调度算法相关的目录，`defaultPredicates(), defaultPriorities()`里面的内容都是位于这个目录中，具体调度器的断言过滤、优先级排序算法详情将在下篇中详解，本篇调度器框架结构梳理到此结束！
+`CheckNodeMemoryPressure`这个词相应熟悉kubernetes 应用的朋友一定不会陌生，例如在node内存压力大无法调度的pod时，`kubectl describe pod xxx`就会在状态信息里面看到这个关键词。
+
+让我们回到`pkg/scheduler/algorithmprovider/defaults/defaults.go:102`这个位置，查看`factory.RegisterAlgorithmProvider(factory.DefaultProvider, predSet, priSet)`方法的详情,可以看到`参数factory.DefaultProvider`值为字符串格式的`DefaultProvider`，**先记住这个关键值**，进入方法内部:
+
+`pkg/scheduler/factory/plugins.go:387`:
+
+```go
+func RegisterAlgorithmProvider(name string, predicateKeys, priorityKeys sets.String) string {
+	schedulerFactoryMutex.Lock()
+	defer schedulerFactoryMutex.Unlock()
+	validateAlgorithmNameOrDie(name)
+	algorithmProviderMap[name] = AlgorithmProviderConfig{
+		FitPredicateKeys:     predicateKeys,
+		PriorityFunctionKeys: priorityKeys,
+	}
+	return name
+}
+```
+
+可以看到，这个方法为DefaultProvider绑定了配置：筛选算法和优先级排序算法的key集合，这些key只是字符串，那么是怎么具体落实到计算的方法过程上去的呢？让我们看看`pkg/scheduler/algorithmprovider/defaults/`目录下的`register_predicates.go,register_priorities.go`这两个文件:
+
+![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/preinit.jpg)
+
+它们同样也在init()函数中初始化时使用`factory.RegisterFitPredicate()`方法做了一些注册操作,这个方法的两个参数，前一个是筛选/计算优先级 的关键key名，后一个是具体计算的功能实现方法，点击`factory.RegisterFitPredicate()`方法，深入一级，查看内部代码，
+
+```go
+// RegisterFitPredicateFactory registers a fit predicate factory with the
+// algorithm registry. Returns the name with which the predicate was registered.
+func RegisterFitPredicateFactory(name string, predicateFactory FitPredicateFactory) string {
+	schedulerFactoryMutex.Lock()
+	defer schedulerFactoryMutex.Unlock()
+	validateAlgorithmNameOrDie(name)
+	fitPredicateMap[name] = predicateFactory
+	return name
+}
+```
+
+可以看出，两者使用map[string]func()的方式关联在了一起，那么在后面实际调用的时候，必定是在map中基于key找出方法并执行。优先级先关的`factory.RegisterPriorityFunction2()`方法亦是同理。
+
+
+
+### 生成默认配置
+
+还记得刚刚重点圈出的`DefaultProvider`关键值吗？通过上面我们知道了，所有默认Predicate/priority算法的实现都是绑定在这个默认的`AlgorithmProvider`身上的，那么，启动scheduler的时候，究竟是如何将`DefaultProvider`作为默认`AlgorithmProvider`呢？让我们回到最初的调度器启动命令入口位置`cmd/kube-scheduler/app/server.go:62`:
+
+```go
+opts, err := options.NewOptions()
+// 点击NewOptions跳转进入内部,来到了这个位置:cmd/kube-scheduler/app/options/options.go:75
+
+func NewOptions() (*Options, error) {
+	cfg, err := newDefaultComponentConfig()
+	if err != nil {
+		return nil, err
+	}
+	... // 省略
+}
+// 这个newDefaultComponentConfig方法特别有意思，从字面看它是用来为组件填充默认配置的
+// 来看看它的内容，点击来到了cmd/kube-scheduler/app/options/options.go:132
+
+func newDefaultComponentConfig() (*kubeschedulerconfig.KubeSchedulerConfiguration, error) {
+	cfgv1alpha1 := kubeschedulerconfigv1alpha1.KubeSchedulerConfiguration{}
+	kubeschedulerscheme.Scheme.Default(&cfgv1alpha1)
+... // 省略
+}
+
+// 点击kubeschedulerscheme.Scheme.Default(&cfgv1alpha1)中的Default跳转进入
+// 来到了这里:vendor/k8s.io/apimachinery/pkg/runtime/scheme.go:389
+func (s *Scheme) AddTypeDefaultingFunc(srcType Object, fn func(interface{})) {
+	s.defaulterFuncs[reflect.TypeOf(srcType)] = fn
+}
+
+// Default sets defaults on the provided Object.
+func (s *Scheme) Default(src Object) {
+	if fn, ok := s.defaulterFuncs[reflect.TypeOf(src)]; ok {
+		fn(src)
+	}
+}
+
+// 看看defaulterFuncs的数据类型：
+	// defaulterFuncs is an array of interfaces to be called with an object to provide defaulting
+	// the provided object must be a pointer.
+	defaulterFuncs map[reflect.Type]func(interface{})
+
+// 不难看出，这个Default()方法是通过反射器，获取对象的类型，以类型作为map的key，从而获取该类型
+// 对应的defaulterFuncs，也即是该结构体填充默认配置的方法，最后执行该方法
+// 那么这个defaulterFuncs map[reflect.Type]func(interface{})，里面的元素时怎么填充的呢？
+// 作者很贴心地将添加map元素的方法写在了Default()方法的正上方:
+func (s *Scheme) AddTypeDefaultingFunc(srcType Object, fn func(interface{})) {
+	s.defaulterFuncs[reflect.TypeOf(srcType)] = fn
+}
+
+```
+
+我们选中然后ctrl+b，查找AddTypeDefaultingFunc()的引用，弹窗中你可以看到有非常非常多的对象都引用了该方法，这些不同类型的对象相信无一例外都是通过Default()方法来生成默认配置的，我们找到其中的包含scheduler的方法:
+
+![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/addDefaultFunc.jpg)
+
+跳转进去，来到了这个位置`pkg/scheduler/apis/config/v1alpha1/zz_generated.defaults.go:31`:
+
+![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/registerDefaults.jpg)
+
+进入`SetDefaults_KubeSchedulerConfiguration()`，来到`pkg/scheduler/apis/config/v1alpha1/defaults.go:42`:
+
+![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/SetDefaults_KubeSchedulerConfiguration.jpg)
+
+看到了`DefaultProvider`吗？是不是觉得瞬间豁然开朗，原来是在这里调用指定了scheduler配置的`AlgorithmSource.Provider`。
+
+
+
+### 调度功能实现的回溯
+
+让我们捋一捋调度器框架运行调度功能相关的流程:
+
+```
+// 1.获取AlgorithmSource.Provider(默认"DefaultProvider")，作为key从map中获取到pkg/scheduler/algorithmprovider包内为其初始化的两种算法key集合
+algorithmProviderMap[name] = AlgorithmProviderConfig{
+		FitPredicateKeys:     predicateKeys,
+		PriorityFunctionKeys: priorityKeys,
+	}
+	
+// 2.填充genericScheduler对象的predicates元素:
+// pkg/scheduler/factory/plugins.go:411
+
+func getFitPredicateFunctions(names sets.String, args PluginFactoryArgs) (map[string]predicates.FitPredicate, error) {
+	schedulerFactoryMutex.Lock()
+	defer schedulerFactoryMutex.Unlock()
+
+	fitPredicates := map[string]predicates.FitPredicate{}
+	for _, name := range names.List() {
+		factory, ok := fitPredicateMap[name]
+		if !ok {
+			return nil, fmt.Errorf("invalid predicate name %q specified - no corresponding function found", name)
+		}
+		fitPredicates[name] = factory(args)
+	}
+
+	// Always include mandatory fit predicates.
+	for name := range mandatoryFitPredicates {
+		if factory, found := fitPredicateMap[name]; found {
+			fitPredicates[name] = factory(args)
+		}
+	}
+
+	return fitPredicates, nil
+}
+
+// 3.对predicates内的每一个key，找到对应的检查方法，执行每一项检查,返回检查结果
+// pkg/scheduler/core/generic_scheduler.go:608
+
+func podFitsOnNode(
+	pod *v1.Pod,
+	meta predicates.PredicateMetadata,
+	info *schedulernodeinfo.NodeInfo,
+	predicateFuncs map[string]predicates.FitPredicate,
+	queue internalqueue.SchedulingQueue,
+	alwaysCheckAllPredicates bool,
+) (bool, []predicates.PredicateFailureReason, error) {
+	var failedPredicates []predicates.PredicateFailureReason
+
+	podsAdded := false
+	for i := 0; i < 2; i++ {
+		metaToUse := meta
+		nodeInfoToUse := info
+		if i == 0 {
+			podsAdded, metaToUse, nodeInfoToUse = addNominatedPods(pod, meta, info, queue)
+		} else if !podsAdded || len(failedPredicates) != 0 {
+			break
+		}
+		for _, predicateKey := range predicates.Ordering() {
+			var (
+				fit     bool
+				reasons []predicates.PredicateFailureReason
+				err     error
+			)
+			if predicate, exist := predicateFuncs[predicateKey]; exist {
+				fit, reasons, err = predicate(pod, metaToUse, nodeInfoToUse)
+				if err != nil {
+					return false, []predicates.PredicateFailureReason{}, err
+				}
+				... // 省略
+					}
+				}
+			}
+		}
+	}
+
+	return len(failedPredicates) == 0, failedPredicates, nil
+}
+```
+
+### 目录结构总结
+
+最后，对`pkg/scheduler`路径下的各子目录的功能来一个图文总结吧:
+
+![](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/image/p2/dir.jpg)
+
+
+
+如果有沉下心来阅读代码，结合上面的图文讲解，相信你对调度器框架包内的代码结构会有一个较为清晰的整体掌握，本篇框架篇到此结束，下一篇来谈谈详细的调度算法的细节

scheduler/P3-调度器算法.md

@@ -0,0 +1,12 @@
+# 调度器算法
+
+## 前言
+
+在上一篇文档中，我们找到调度器筛选node的`pkg/scheduler/core/generic_scheduler.Scheduler()` function，然后简单回溯了一遍调度器框架的代码结构:
+
+[**P2-调度器框架篇**]([https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/P2-%E8%B0%83%E5%BA%A6%E5%99%A8%E6%A1%86%E6%9E%B6.md](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/P2-调度器框架.md))
+
+那么在本篇，从此function展开，看一看调度算法的逻辑
+
+## 正文
+

scheduler/README.md

@@ -3,6 +3,8 @@
 ## 调度器源码分段阅读目录
 - [调度器入口](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/P1-%E8%B0%83%E5%BA%A6%E5%99%A8%E5%85%A5%E5%8F%A3%E7%AF%87.md)
 - [调度器框架](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/P1-%E8%B0%83%E5%BA%A6%E5%99%A8%E5%85%A5%E5%8F%A3%E7%AF%87.md)
+- [调度器算法](https://github.com/yinwenqin/kubeSourceCodeNote/blob/master/scheduler/P1-%E8%B0%83%E5%BA%A6%E5%99%A8%E5%85%A5%E5%8F%A3%E7%AF%87.md)
+- 待补充
 
 ## 概览
 首先列出官方md链接，讲解颇为生动：
@@ -43,7 +45,7 @@ Kubernetes scheduler独立运作与其他主要组件之外(例如API Server)，
                         |
                         v
     +-------------------+-------------------------+
-    |             剩余可选 nodes:                |
+    |             剩余可选nodes:                   |
     |   +--------+                 +--------+     |
     |   | node 1 |                 | node 2 |     |
     |   +--------+                 +--------+     |
@@ -54,8 +56,8 @@ Kubernetes scheduler独立运作与其他主要组件之外(例如API Server)，
                         v
     +-------------------+-------------------------+
 
-    优先级判断:           node 1: priority=2
-                          node 2: priority=5
+    优先级判断:     node 1: priority=2
+                   node 2: priority=5
 
     +-------------------+-------------------------+
                         |