k8s的集群调度
scheduler:负责调度资源，把pod调度到node节点
预算策略
优先策略
1、list-watch
k8s集群当中，通过list-watch的机制进行每个组件的协作，保持数据同步，每个组件之间解耦
kubectl配置文件，向APIserver发送命令----apiserver把命令发送到各个组件
kubectl run nginx --image=nginx:1.22 ---- apiserver -----controller manager ---scheduler ---- kubelet管理容器生命周期
创建成功之后，kubectl get pod describe pod nginx----保存在etc的数据库当中
list-watch 会在每一步把监听的消息(监听APIserver:6443)-----每个组件contrlller manager， scheduler， kubelet，etcd都要监听apiserver:6443端口
如何把pod分配到node
2、调度的过程和策略：
scheduler是k8s集群的调取器，把pod分配到集群节点
一下几个问题：
1、公平，每个节点都能够分配资源
2、资源高效利用，集群当中的资源可以被最大化使用
3、效率：调度的性能要好，能够尽快的完成大批量的pod的调度工作
4、灵活:用户允许用户根据自己的需求，控制和改变调度的逻辑
scheduler是一个单独运行的程序，启动之后就会一直监听APIserver 获取报文中的字段:spec.nodeName
创建pod时候，为每个pod创建一个binding，表示该往哪个节点上部署。
创建pod到节点时，有两个策略，先执行预算策略，在执行优先策略，这两步的操作都必须成功，否则立刻返回报错
也就是说，部署的node，必须满足这两个策略
预算策略
predicate自带一些算法，选择node节点(scheduler自带的算法策略，不需要人工干预)
算法：
1、podfitsresources:pod适应资源，检查节点上的剩余资源是否满足pod请求的资源，主要是cpu和内存
2、podfitshost:pod适应主机，如果pod指定了node的name， nginx1pod检测node01是否存在，检测主机名是否存在，存在要和pod指定的名称匹配，之才能调度过去
3、podselectormatches:pod选择器匹配，创建pod的时候也可以根据node节点的标签来进行匹配，查找指定的node节点上标签是否存在，存在的标签是否匹配
4、nodiskconflict:无磁盘冲突,确保已经挂载的卷于pod的卷不发生冲突，除非目录是只读
如果预算策略都不满足，pod将始终处于pending状态，还在不断重启调度，直到有节点满足为止
node1 node2 node3
经过预算策略，上诉三个节点都满足条件 >优选
优先策略
leastrequestedpriority:最低请求优先级，通过算法计算节点上的cpu和内存使用率。确定节点的权重，使用率越低的节点相应的权重越高。调度时会更倾向于使用率低的节点，实现资源合理的利用
balanceresourceallocation:平衡资源分配，cpu和内存使用率,给节点赋予一个权重，权重算的是cpu和内存使用率接近。使用率越接近权重越高
和上面的leastrequestedpriority最低请求优先级一起使用
比如 node1：cpu用了20%内存60%
node2:cpuyongle 50%内存50%
node2在被调度时会被优先选择,node2的有优先级更高
imagelocalitypriority:节点上是否已经有了要部署的镜像。和镜像的总数成正比，满足的镜像数越多，权重越高。
以上这些策略都是scheduler自带的算法。通过预算策略选择出合适的节点，再通过优选策略选择出来最好的节点，以上都是自带的算法，k8s集群自己来选择
指定节点和指定标签
指定节点:
spec参数设置当中
加上nodeName:node02
指定了节点，再参数中设置了nodeName，指定了节点的名称，会跳过scheduler的调度策略。这个规则是强制匹配
指定标签
spec
nodeSelector:
kubectl get nodes --show-labels 查看节点的标签
自定义标签 kubectl lable nodes master01 test1=a
kubectl lable nodes node01 test1=b
kubectl lable nodes node02 test3=c
指定节点标签部署pod，是要经过schedluler的算法，如果节点不满足条件，pod会进入pending状态，直到节点满足条件为止
亲和性:
F
软策略和硬策略
node节点亲和性:
preferredDuringSchedulingIgnoredDuringExecution 软策略:选择node节点时，我声明了最好能部署在node01，软策略会尽量满足这个条件，不一定会完全部署在node01节点上。
requiredDuringSchedulinglgnoredDuringExeution硬策略:选择pod时，声明了node01，如果是硬策略，必须必须部署在node01，也可以理解为强制性要求。
pod的亲和性
preferredDuringSchedulingIgnoredDuringExecution 软策略:要求调度器将pod调度到其他pod的亲和性匹配的节点上，可以是，也可以不是，尽量满足
两个pod nginx1和nginx2 nginx2希望和nginx1部署在一个节点上，会尽量满足
requiredDuringSchedulinglgnoredDuringExeution硬策略
两个pod nginx1和nginx2 必须要和nginx的亲和性匹配，只能部署在node01
键值的运算关系
根据标签选择亲和性
In:在，选择的标签值在node节点上存在
Notin:不在，选择标签的值不在node节点上
Gt:大于，大于选择的标签值
Lt:小于，小于选择的标签纸
只能比较整数值
亲和性策略更具标签来进行选择
Exists:存在，选择标签对象，不考虑值
DoesNotExist:不存在，选择不具有指定标签的对象，值不考虑。
怎么删除标签
kubectl label nodes master01 test1-
Gt:大于，大于选择的标签值
Lt:小于，小于选择的标签纸
只能比较整数值
亲和性策略更具标签来进行选择
指定键值对的算法为Exists' or 'DoesNotExist不能使用values字段
软策略
多个软策略看的是权重，权重高执行指定的软策略
硬策略先满足策略，在满足软策略
例子
你在部署pod时如何选择策略:
node的亲和性:性能不一致时，我尽量把pod把性能高的多部署，选择软策略
如果节点故障或者维护中，只能选择硬策略，要把故障或者维护的节点剔除。
node01：4核8g
node02: 4核8g
node03: 2核4g
看性能 选择一个软策略，尽量把pod部署在node01和node02上
如果其中一台node03挂了，我会选择硬策略排除挂了的节点
