schedule的调度算法
预算策略
过滤出合适的节点
优先策略
选择部署的节点
nodeName:硬匹配，不走调度策略。node01.
nodeSelector: 根据节点的标签选择，会走调度的算法。
只要是走调度算法，在不满足预算策略的情况下，所有pod都是pending。
node节点的亲和性:
硬策略：必须满足的条件。匹配原则也是根据节点的标签
软策略：尽量满足要求，不是一定满足
pod的亲和性和反亲和性
| 调度策略 | 匹配标签 | 操作符 | 拓扑域 | 调度目标 |
| node的亲和性 | 主机标签 | In/Notin/Exists/DoesNotExists/Gt/Lt | 不支持 | 指定主机 |
| pod的亲和性 | pod的标签 | In/Notin/Exists/DoesNotExists | 支持 | pod和指定标签的pod部署在同一拓扑域 |
| pod的反亲和性 | pod的标签 | In/Notin/Exists/DoesNotExists | 支持 | pod和指定标签的pod部署不在同一拓扑域 |
拓扑域：k8s集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分可以用来表示节点之间的空间关系，网络关系或者其他类型的关系。标签。主机标签。
pod
node1 ?node2 ??node3
nginx1 ?nginx2 ??nginx3
app1????app1 ???app1
app1 ?app2 ?app2 ?app3??app3 ?app4
topologyKey指定拓扑域的关键字段，表示正在使用test1作为拓扑域的关键字。test1一般是节点标签，表示希望把pod调度到包含有app标签的pod，值为nginx1的在test1的拓扑域上的节点。
注意点：
1、pod的亲和性策略，在配置时，必须要加上拓扑域的关键字topologyKey，指向的是节点标签
2、pod亲和性的策略分为硬策略和软策略
3、pod亲和性的notin可以替代反亲和性
4、pod亲和性把相关联的pod组件部署在同一节点
你在进行部署时怎么考虑node节点？
软硬策略、污点和容忍
污点和容忍可以配合node的亲和性一块使用
污点：是node的调度机制，不是pod
被设置为污点的节点不会部署pod
污点和亲和性相反，亲和性是尽量或者一定选择。
污点的节点一定不被选择（真否？答案如下）
taint三种：
1、NoScheduler
k8s不会把pod调度到这个节点上
2、PreferNoSchedule
如果污点类型是这个，那么就是尽量避免把pod部署在该节点上，而不是一定(master节点的污点就是这个)
3、NoExecute
如果污点类型是这个，那么K8S会把这个节点上的pod全部驱逐出去，而且不会调度到这个节点
基于控制器创建的pod虽然被驱逐，但是会在其他节点重新部署
自主pod会被直接杀死
**?注意点：节点服务器需要维护的，服务器关机，节点上pod将会失效，在工作中我们主要部署pod的方式控制器部署。deployment最多的。一旦节点设置为驱逐，控制器创建的pod会在其他节点重新部署。
所有的pod都会被驱逐，和命名空间无关。所有的一切都会被驱逐
不论你的创建方式是什么，都会被驱逐
系统集群组件不会被驱逐?**
容忍：即使节点上设置了污点，有了容忍机制，依然可以在设置为污点的节点上部署pod
特殊情况: NOExecute依然可以部pod,但是有生命周期，时间一到，pod会被销毁,生命周期结束之后，会驱逐一部分pod到其他节点。
*有的节点还是会保留在污点节点上。
该节点维护完毕，测试一下节点的工作是否正常
tolerations:
- key: key??
operator : Exists
指定key的值，指标节点的标签值，但是不指定污点的类型，那么所有节点上只要包含了这个指定的标签名，可以容忍所有的污点
tolerations:
- operator: Exists
- effect: Noschedule
没有key,不匹配节点标签，容忍所有污点，但是类型是指定的类型
node的亲和性
pod的亲和性和反亲和性
污点和容忍
如何选择node节点部署pod.
选择一个期望的节点来部署pod
多个master节点：
kubectl taint node master书点名称 node-role.kubernetesio/master=:PreferNoSchedule
尽量不往master节点上部署pod,但是不是一定的。防止资源浪费。也可以自定义标签
业务维护：
node02需要维护2个小时。但是这个节点还有业务pod在运行。就需要把这个节点的污点设置为NoExcute
我们部署pod一般都使用deployment部署，会在其他的重新部署，并不是被杀死。自主式的pod会被杀死。
一旦节点恢复，一定要把污点去除
cordon和drain
cordon:可以直接把节点标记为不可用状态
drain: 排水。把该节点下的pod全部转移到其他的node节点上运行
1、一旦执行drain之后，被执行的节点会变成不可调度状态
2、会驱逐该节点上的所有pod
kubectl drain node02 --ignore-daemonsets --delete-local-data --force
drain：为不可调度，然后驱逐pod
--ignore-daemonsets：无视daemonsets部署的pod,一并驱逐
--delete-local-data：有本地挂载卷的pod会被强制杀死
--force：强制释放不是控制器管理的pod
还是如何来管理和部署pod
pod的亲和性和反亲和性
污点：驱逐
NoExecute
cordon
drain
-ignore-daemonsets daemonset部罢的一股是重要后台运行的，系统pod。所以不动。
node亲和性 ?????????软硬策略
pod亲和性
pod反亲和性
污点 NoExecute
容忍
cordon
drain
如何部署pod是比较重要的集群资源的调度机制，合理的配置pod的调度机制可以使资源最大化利用