1、scheduler：负责调度资源，把pod调度到指定的node节点
（1）预算策略
（2）优先策略
2、List-watch
（1）在k8s集群中，通过List-watch的机制进行每个组件的协作，保持数据同步，每个组件之间的解耦（减少每个组件之间的关联性）
（2）kubectl配置文件，向APIserver发送命令，apiserver把命令发送到各个组件
①kubectl run xx——apiserver——controller manager——scheduler——kubelet
②创建成功之后，kubectl get/describe/ pod——保存etcd的数据库中
（3）List-watch会在每一步把监听的消息（APIserver：6443），每个组件（controller manager、scheduler、kubelet、etcd）都会监听apiserver的6443端口
4、调度的过程和策略
（1）scheduler是k8s集群的调度器，把pod分配到集群的节点
①公平：每个节点都能分配到资源
②资源高效利用：集群中的资源可以被最大化使用
③效率：调度的性能要好，能够尽快的完成大批量的pod的调度工作
④灵活：允许用户根据自己的需求，控制和改变调度的逻辑
（2）scheduler是一个单独运行的程序，启动之后就会一直监听apiserver，获取报文中的字段：spec.node name，创建pod时，会为每一个pod创建一个binding（表示该往哪个节点上部署）
（3）创建pod到节点时，有两个策略，先执行预算策略，再执行优先策略，这两步的操作都必须成功，否则立即返回报错，也就是，部署的node必须满足这两个策略
| 预算策略：predicate自带一些算法，选择node节点（scheduler自带的算法策略，不需要人工干预） | ||
| podfitsresources | pod的适应资源：检测节点上的剩余资源，是否满足pod请求的资源（主要是CPU和内存） | |
| podfitshost | pod适应主机：如果pod指定了一个node的name，指定节点后，来检测主机名是否存在，存在要和pod指定的名称相匹配，这才能调度过去 | |
| podselectormatches | pod选择器匹配：创建pod的时候可以根据node节点的标签来进行匹配，查找指定的node节点上标签是否存在，存在的标签是否匹配 | |
| nodiskconflict | 无磁盘冲突：确保已挂载的卷和pod的卷不发生冲突。如发生冲突，会重新选择一个节点部署，除非目录是只读目录，只读目录会直接覆盖 | |
| 如果预算策略无法满足，pod将始终处于pending状态，不断的重试调度，直到有节点满足条件为止 | ||
| 优先策略： | ||
| leastrequestedpriority | 最低请求优先级：通过算法计算节点上的CPU和内存使用率，确定节点的权重，使用率越低的节点相应的权重越高，调度时会更倾向于使用率低的节点，实现资源合理的利用 | |
| balanceresourceallocation | 平衡资源分配：CPU和内存的使用率，给节点赋予去昂走动，权重是CPU和内存的使用率接近，权重越高，和上面的leastrequestedpriority最低请求优先级一起使用 | |
| imagelocalitypriority | 节点上是否己经有了要部署的镜像：镜像的总数成正比，满足的镜像数越多，权重越好，调度时优先级就越高 | |
| 通过预算选择可以部署的节点，再通过优先选择出最好的节点，以上的策略都是自动的，scheduler自带的算法，k8s集群自己来选择 | ||
5、指定节点和标签
（1）指定节点（不经过scheduler调度算法、强制匹配）
①spec参数设置：nodeName:node2
②指定了节点，在参数中设置了nodeName，指定了节点的名称，会跳过scheduler的调度策略，这个规则是强制匹配
（2）指定标签（经过scheduler调度算法）
* 只要是走调度算法，在不满足预算策略的情况下，所有pod都是pending
①spec参数设置：nodeSelector:node2
②查看所有节点的标签：kubectl get nodes --show-labels
③创建节点标签：kubectl label nodes master test1=a
④查看已经部署的服务选择的标签：kubectl get deployments.apps -o wide
⑤根据指定标签部署pod：
⑥指定节点标签部署pod，要经过scheduler的调度算法，如果节点不满足条件，pod会进入pending状态，直到节点满足条件为止
⑦修改标签值：kubectl label nodes node1 test=3
⑧删除标签值：kubectl label nodes node1 test-
6、亲和性
（1）节点亲和性
（2）pod亲和性
①软策略和硬策略
②软策略：多个软策略看权重，权重高，执行指定的软策略
③软硬策略结合：先满足硬策略，再满足软策略
（3）node节点的亲和性
| preferredDuringSchedulingIgnoredDuringExecution：软策略 选择node节点是，声明了最好能部署在node1，软策略会尽量满足这个条件，不一定会完全部署在node1节点上 |
| requiredDuringSchedulingIgnoredDuringExecution：硬策略 选择pod时，声明了node1，选择硬策略，必须满足硬策略的条件，必须部署在node1，强制性要求，根据节点的标签匹配 |
（4）pod的亲和性
| preferredDuringSchedulingIgnoredDuringExecution：软策略 要求调度器将pod调度到其他pod的亲和性匹配的节点上，可以是，也可以不是，尽量满足，不是一定满足 |
| requiredDuringSchedulingIgnoredDuringExecution：硬策略 要求调度器将pod调度到其他pod的亲和性匹配的节点上，必须是 |
（5）键值的运算关系
| 标签，都是根据标签来选择亲和性 | |
| In | 在，选择的标签值在node节点上存在 |
| Notin | 不在，选择label的值不在node节点上的 |
| Gt | 大于，大于选择的标签值（只能比较整数值） |
| Lt | 小于，小于选择的标签值（只能比较整数值） |
| Exists | 存在，选择标签对象，值不考虑（不能使用value字段） |
| DoseNotExist | 不存在，选择不具有指定标签的对象，值不考虑（不能使用value字段） |
（6）node节点的亲和性之硬策略
①In策略
②Notin策略（不能有标签为test1的节点）
③Gt策略
④Lt策略
⑤Exists策略
⑥DoseNotExist策略
（7）node的亲和性之软策略
（8）node的亲和性之多个软策略、看权重
（9）node的亲和性之软策略和硬策略结合
①第一种
②第二种
③第三种
④第四种
⑤第五种
⑥第六种
⑦第七种
7、pod的亲和性和反亲和性
（1）pod和node的亲和性
①拓扑域：k8s集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分，可以用来表示节点之间的空间关系，网络关系或者其他类型的关系
| pod和node的亲和性 | |||
| 调度策略 | node的亲和性 | pod的亲和性 | pod的反亲和性 |
| 匹配标签 | 主机标签 | pod的标签 | pod的标签 |
| 操作符 | In NotIn Exists DoesNotExsit Gt Lt | In NotIn Exists DoesNotExsit | In NotIn Exists DoesNotExsit |
| 拓扑域 | 不支持 | 支持 | 支持 |
| 调度目标 | 指定主机 | pod和指定标签的pod部署在同一拓扑域 | pod和指定标签的pod部署在不同拓扑域 |
（2）pod的亲和性
①创建pod标签
②创建节点标签
③配置deployment
④第二种
⑤第三种
* 基于deployment创建的pod修改标签，不可以直接apply -f，要把前一个标签的资源对象删除，再创建新的deployment
⑥软策略：preferredDuringSchedulingIgnoredDuringExecution
（3）pod的反亲和性（使用较少，类似于亲和性的NotIn）
（4）总结
①pod的亲和性策略，在配置时，必须要加上拓扑域的关键字topologykey（指向的是节点标签）
②pod亲和性的策略分为硬策略和软策略
③pod亲和性的notin可以替代反亲和性
④pod亲和性的作用主要是为了把相关联的pod部署在同一节点（类似lnmp）
8、污点
（1）在进行部署的时候，如何考虑node节点：软硬策略、污点和容忍
①污点和容忍可以配合node的亲和性一起使用，污点是node调用机制，不是pod
被设为污点的节点，不会部署pod
②污点和亲和性相反，亲和性是尽量选择和一定选择，污点的节点一定不被选择？
（2）污点（taint）的类型
| NoSchedule | k8s不会把pod调度到这个节点上 |
| PreferNoSchedule | 此类型的污点，尽量避免把pod部署在改节点上，不是一定（master节点的污点一般就是PerferNoSchedule） |
| NoExecute | 此类型的污点，k8s将会把该节点上的pod全部驱逐，而且也不会调度到这个节点 |
| ①基于控制器创建的pod，虽然被驱逐，会在其他节点重新部署 ②自主创建的pod会被直接杀死 | |
（3）查看污点：kubectl describe nodes master | grep -i taints
（4）设置污点：kubectl taint node master key=1:NoSchedule
（5）删除污点：
①kubectl taint node node2 key:PreferNoSchedule-
（6）NoExecute（驱逐、慎重）
①NoExecute的使用场景：资源回收或节点维护
| * 节点服务器需要维护的，服务器关机，节点上pod将会失效。在工作中，主要部署pod的方式是控制器部署、deployment部署最多。一旦节点设置为驱逐，控制器创建的pod会在其他节点重新部署，NoExecute主要用于：资源回收或节点维护 |
| * 使用NoExecute，所有的pod都会被驱逐，所有的一切都会被驱逐，kube-proxy属于组件pod，依旧存在 |
| * 不论创建方式是什么，都会被驱逐，系统集群组件不会被驱逐 |
9、容忍机制：表示可以部署pod在有污点的节点上
（1）配置容忍机制
①设置污点
②配置容忍
（2）NoExecute的容忍机制：设置时间限制
①NoExecute依然可以部署pod，但是有生命周期，pod会被销毁，生命周期结束后会驱逐一部分pod到其他节点
②NoExecute的容忍机制：该节点维护完毕，测试一下该节点的工作是否正常
（3）污点的容忍机制
①不指定节点标签key，指定污点类型effect
②指定节点标签key，不指定污点类型effect：所有节点上只要有key，都容忍
（4）总结
①指定key的值、节点的标签值，但是不指定污点的类型，那么所有节点上只要包含这个指定的标签名，可以容忍所有的污点
②不指定key的值，不匹配节点的标签，但是指定污点类型，容忍所有指定类型的污点
（5）node的亲和性、pod的亲和性和反亲和性、污点和容忍：作用：如何选择node节点部署pod，选择一个期望的节点部署pod
| ①多个master节点:kubectl taint node master节点名称 ： node-role.kubernetes.io/master=:PreferNoSchedule尽量不往master节点上部署pod,但是不是一定的，防止资源浪费，自定义一个标签。 |
| ②业务维护： node2需要维护2小时，但是这个节点还有业务pod在运行，就需要把这个节点的污点设置为：noexecute，部署pod一般都是使用deployment部署，会在其他的节点重新部署，并不是被杀死，自主式的pod会被杀死。一旦节点恢复，一定要把污点删除 |
10、cordon和drain
（1）cordon：可以直接把节点标记为不可用状态
①设置cordon：kubectl cordon master node1
②取消cordon：kubectl uncordon master node1
（2）drain：把该节点下的pod全部转移到其他的node节点上运行
①一旦指定drain，被执行的节点不会变成不可调度状态
②会驱逐该节点上的所有pod
③kubectl drain node1 --ignore-daemonsets --delete-local-data --force
| drain | 驱逐，标记node节点为不可调度，然后驱逐pod |
| --ignore-daemonsets | 无视daemonset部署的pod，此类pod还在节点上 daemonset部署的一般是重要的后台运行的、系统pod，所以不动 |
| --delete-local-data | 有本地挂载卷的pod会被强制杀死 |
| --force | 强制释放不是控制器管理的pod（不是控制器管理的pod会被杀死） |
④删除drain：kubectl uncordon node1
