了解kube-scheduler
由之前博客可知kube-scheduler是k8s中master的核心组件之一
scheduler：负责调度资源。把pod调度到node节点。他有两种策略：
预算策略：人为部署，指定node节点去部署新建的pod
优先策略：通过算法选择一个负载最小，资源最充沛的资源去部署。
k8s中List-watch
k8s集群当中，通过list-watch的机制进行每个组的写作，保持数据同步。这种设计可以实现每个组件之间的解耦（解耦：减少每个组件之间的关联性）。
kubectl来配置文件，向APIServer发送命令----apiserver把命令发送到各个组件。
kubectl run nginx --image=nginx:1.22-------apiserver------controller manager------scheduler-------kubelet.。
创建成功之后，kubectl get pod kubectl describe pod nginx-------保存到etcd当中
以上过程是list-watch会在每一步把监听的消息（APIserver:6443）-------controller manager，scheduler，kubelet，etcd都会监听apiserver:6443
工作流程图：
注意：在创建 Pod 的工作就已经完成了后，为什么 kubelet 还要一直监听呢？原因很简单，假设这个时候 kubectl 发命令，要扩充 Pod 副本数量，那么上面的流程又会触发一遍，kubelet 会根据最新的 Pod 的部署情况调整 Node 的资源。又或者 Pod 副本数量没有发生变化，但是其中的镜像文件升级了，kubelet 也会自动获取最新的镜像文件并且加载。
2.调度的过程和策略
scheduler是k8s集群的调取器，把pod分配到集群的节点。
以下几个问题需要考虑：
1.公平：每个节点都能够分配资源。
2.资源高效利用：集群当中的资源可以被最大化利用
3.效率：调度的性能要搞好。能够尽快的完成大批量的pod的调度工作。
4.灵活：允许用户根据自己的需求，控制和改变调度的逻辑。
scheduler是一个单独运行的程序，启动之后就会一直监听APIserver，获取报文中的字段：spec.modeName
创建pod时候，为每个pod创建一个binding，表示该往哪个节点上部署。
创建pod到节点时，有两个策略：先执行预算策略，再执行优先策略。这两步都必须成功，否则立刻返回报错。
也就是说，部署的node，必须满足这两个策略。
预算策略：
predicate自带一些算法来选择node节点（scheduler自带的算法策略。不需人工干预）
- 1.podfitsresoureces：Pod的适应资源，检测节点上剩余测资源是否满足pod请求的资源主要是cpu和内存。
- 2.podfitshost：pod适应主机，如果pod指定了node的name。
- nginx1 pod---> node01，检测主机名是否存在，存在要和pod指定的名称匹配，这才能调度过去。
- 3.podselectormatches：pod选择器匹配，创建pod的时候可以根据node的标签来进行匹配。查找指定的node节点上标签是否存在，存在的标签是否匹配。
- 4.nodiskconflict：无磁盘冲突，确保已挂载的卷与pod的卷不发生冲突，除非目录是只读。
只有上述策略完成，才回到优先策略。如果预算策略都不满足，pod将始终处于pending状态，不断地重试调度，直到有节点满足条件为止。
如果node1,node2,node3经过预算策略，上述三个节点都满足条件----》优先策略
优先策略
leastreaquestedpriority：
最低请求优先级，通过算法计算节点上的cpu和内存使用率，确定节点的权重。
使用率越低的节点相应的权重就越高。调度时会更倾向于使用率低的节点。实现资源合理的利用。
balancersourceallocation：
平衡资源分配，考虑cpu和内存的使用率，给节点赋予权重。权重算的是cpu和内存使用率接近。使用率越接近，权重越高。
和上面的leastreaquestedpriority最低请求优先级一起使用。
举个例子，有node1，node2两个节点，资源分别是：
node1 cpu和内存使用率： 20：60
node2 cpu和内存使用率： 50：50
node2再被调度时会被优先
imagelocalitypriority：
节点上是否已经有了要部署的镜像。镜像的总数成正比，满足的镜像数越多，权重越高。
以上这些策略scheduler自带的算法。
通过预算选择出可以部署的节点，再通过优先选择出来最好的节点，以上都是自带的算法。k8s集群自己来选择。
总的来说：
预选策略 ：通过调度算法过滤掉不满足条件的Node节点
优选策略 ：通过优先级选项给满足调度条件的Node节点进行优先级权重排序，最终选择优先级最高的Node节点来调度Pod
如何指定节点部署
指定节点配置需要在spec模块中参数设置：
nodeName:node02
首先，我们为了防止缩进错误，用生成的yaml文件修改：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx2
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx
nodeName: node02
如果指定了节点，在参数中设置了nodeName，指定了节点的名称，会跳过scheduler调度策略。这个规则是强制匹配
如何指定标签部署
我们可以通过以下命令查看node的标签
kubectl get nodes --show-labels
我们可以在命令行给node添加标签
kubectl label nodes node02 test3=c
已经部署的服务器的标签
已经部署的服务器的标签
节点资源不够会进入pending
指定节点标签部署pod，是要经过scheduler的算法，如果节点不满足条件，pod会进入penging状态，直到节点条件满足为止。
k8s集群的亲和性
软策略和硬策略
node节点亲和性：
preferredDuringSchedulingIgnoredDuringExecution软策略：
选择node节点时，我声明了我最好能部署在node01，软策略会尽量满足这个条件。不一定会完全部署在node01节点上。
requiredDuringSchedulingIgnoredDuringExecution硬策略：
选择pod时，声明了node01，我是硬策略，必须满足硬策略的条件。必须部署在node01，强制性要求
pod的亲和性
preferredDuringSchedulingIgnoredDuringExecution软策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是，也可以不是，尽量满足
pod nginx1 node01
pod nginx2 node02 希望和nginx1部署在一个节点，尽量满足
requiredDuringSchedulingIgnoredDuringExecution硬策略
pod nginx1 node01
pod nginx2 node02 必须要和nginx的亲和性匹配，只能往node01。
键值的运算关系
标签：都是根据标签开选择亲和性。
In：在
选择的标签值在node节点上存在。
Notin：不在
选择label的值不在node节点上
Gt：大于，大于选择的标签值
Lt：小于，小于选择标签值。
Exists：存在，选择标签对象，值不考虑。
DoesNotExit：选择不具有指定表
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx2
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
nodeSelector:
test01: a
containers:
- image: nginx:1.22
name: nginx
affinity:
#选择亲和性部署方式
nodeAffintity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
选择了亲和性nodeSelectorsTerms你要选择哪个nodez作为node为硬策略，匹配的节点标签
- matchExpressions:
定义一个符合我要选择的node节点的信息
- key: test3
operator: In(NotIn)
指定键值对的算法
values:
- c
wq
删除标签
kubectl label nodes node01 test2-
- key: memory
operator: Gt
values:
- "612"
wq
kubectl label nodes node02 memory=1000Gt：大于，大于选择的标签值
Lt：小于，小于选择标签值。
只能比较整数值
亲和性策略根据标签来选择。
Exists：存在，选择标签对象，值不考虑。
DoesNotExit：选择不具有指定表
- key: memory
operator: Exists
values:
- "612"
wq
kubectl apply -f test1.yaml
会报错，因为不能有值
所以：
- key: memory
operator: Exists
指定键值对的算法为Exists or DoesNotExists不能使用values字段。软策略
affinity:
#选择亲和性部署方式
nodeAffintity:
preferredDuringSchedulingIgnoredDuringExecution:
-weight: 1
选择软策略之后要加上权重
preference:
选择节点的倾向，尽量满足要求而不是一定。
选择了亲和性nodeSelectorsTerms你要选择哪个nodez作为node为硬策略，匹配的节点标签
- matchExpressions:
定义一个符合我要选择的node节点的信息
- key: memory
operator: DoesNotExist
wq多个软策略通过什么匹配？
affinity:
#选择亲和性部署方式
nodeAffintity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
选择软策略之后要加上权重
preference:
选择节点的倾向，尽量满足要求而不是一定。
选择了亲和性nodeSelectorsTerms你要选择哪个nodez作为node为硬策略，匹配的节点标签
- matchExpressions:
定义一个符合我要选择的node节点的信息
- key: memory
operator: DoesNotExist
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 10
preference:
matchExpressions:
- key: memory
operator: In
values:
- "500"
多个软策略以权重高的为标的
软硬策略结合的话结果是什么？
affinity:
nodeAffintity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
- matchExpressions:
- key: memory
operator: Exists
values:
- "1000"
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: memory
operator: In
values:
- "500"
wq
kubectl apply -f test1.yaml多个软策略看权重，权重高，执行指定的软策略。
硬策略：先满足硬策略，硬策略一个都不满足才会执行软策略。
你在部署的时候选择一个什么样的策略：
node亲和性：性能不一致，我尽量把pod往性能高的多部署，软策略
节点故障或者节点维护，只能选择硬策略，把节点故障剔除。
举例子：
4/8G 4/8G 2/4G
node1 node2 node3
性能不一致的时候最好使用软策略
如果其中一个node 挂了，可以使用硬策略来指定部署。
