k8s集群的调度
目录
自动调度的原则
调度约束机制：list-watch
apiserver和组件之间的watch机制
调度过程的默认算法
1.预算策略
预算的算法
2.优选策略
优选的算法
*用户定制节点部署
1.强制性节点部署
2.节点标签部署（匹配机制）
标签的增删改查
**亲和性
硬策略和软策略
匹配标签的运算符
节点亲和性 node Affinity
硬策略
软策略
多个软策略
pod亲和性 pod Affinity
硬策略
pod反亲和性 pod Anti-Affinity
硬策略
软策略
练习题
kube-scheduler是集群的调度器，主要任务就是把pod部署到节点上。
自动调度的原则
1.公平性：保证每个可用的节点都可以部署pod
2.资源的高效利用：就是集群当中的资源可以被最大化的使用
3.调度的性能要好：能够对大批量的pod完成调度工作
4.灵活性：用户可以根据自己的需求进行控制
调度约束机制：list-watch
list-watch机制进行每个组件的协作，保持数据同步、实现组件之间的解耦。
apiserver和组件之间的watch机制
kubelet、controller-manager、scheduler这些都是主动监听apiserver的信息，是根据监听到的信息来做出指定的动作，然后再传给apiserver，然后每一步的动作都会通过apiserver传到etcd里。
调度过程的默认算法
1.预算策略
预算策略就是先对节点的条件进行过滤
预算的算法
1. pod的资源适应性：节点上是否有资源能够满足pod请求的资源
2. pod的主机适应性：如果指定了节点，那么要检查集群当中是否有满足要求的节点可供部署
3. pod的主机端口适应性：它会检查节点上使用的端口是否与pod请求的端口冲突
4. pod与主机磁盘的适应性：就是每个pod之间的挂载不能冲突
如果预算条件不满足，pod会进入pending状态
2.优选策略
优选策略就是根据过滤出来的节点选择一个最优的节点
优选的算法
1. 最低请求优先级：它通过计算节点上的cpu和内存的使用率，来确定节点的权重。使用率越低权重就越大，那么就越会被选中作为部署节点。它倾向于选择资源利用率占用较少的节点。
2. 平衡资源分配：它也是根据节点上的cpu和内存的使用率，来确定节点的权重。它的权重是按照cpu和内存之间的使用率的比率，两个使用率越接近越好。（1:1）
3. 镜像本地性优先级：如果节点在本地已经有了需要的镜像，分配的概率更大。
*用户定制节点部署
1.强制性节点部署
nodeName：强制性的选择一个节点，不再需要调度器和算法，直接部署即可。
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx1name: nginx
spec:replicas: 3selector:matchLabels:app: nginx1template:metadata:labels:app: nginx1spec:containers:- name: nginximage: nginx:1.22nodeName: node01
2.节点标签部署（匹配机制）
就是只要标签匹配都可以部署。
kubectl get nodes --show-labels 查看节点标签
注：标签的格式是键值对形式，一个节点可以有多个标签，每个标签以 ，隔开
标签的增删改查
查看标签 kubectl get nodes --show-labels
创建标签 kubectl label nodes node01 test1=a
修改标签 kubectl label nodes node01 test1=b --overwrite
删除标签 kubectl label nodes node01 test1-
根据节点标签匹配部署：
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx1name: nginx
spec:replicas: 3selector:matchLabels:app: nginx1template:metadata:labels:app: nginx1spec:containers:- name: nginximage: nginx:1.22nodeSelector:test2: b
问题：标签选举节点是否需要调度器和算法？
是需要调度器和算法来进行分配的
**亲和性
所有的亲和性都是根据节点标签和pod的标签来进行选择
硬策略和软策略
软策略语法： preferredDuringSchedulingIgnoredDuringExecution
软策略：在选择节点的时候，尽量满足部署的条件，非条件也可以部署
软策略的应用场景：尽量把资源调度到需要的节点
硬策略语法： requiredDuringSchedulingIgnoredDuringExecution
硬策略：必须满足指定的节点条件，否则pending
硬策略应用场景：一般用于特殊场景，比如节点故障，但是有业务要更新，强制性的把资源调度到指定的节点
匹配标签的运算符
键值的运算关系：
1. In 表示在、匹配、= （这里是大写的 i ）
2. NotIn 表示不在、不等于 、逻辑非
3. Gt 表示大于
4. Lt 表示小于
5. Exists 表示存在
6. DoesNotExist 表示不存在
举例：
节点亲和性 node Affinity
是根据软策略和硬策略来分配的
硬策略
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx1name: nginx
spec:replicas: 3selector:matchLabels:app: nginx1template:metadata:labels:app: nginx1spec:containers:- name: nginximage: nginx:1.22affinity:
#选择亲和性的字段nodeAffinity:
#节点亲和性requiredDuringSchedulingIgnoredDuringExecution:
#硬策略nodeSelectorTerms:- matchExpressions:- key: test3operator: Invalues:- a
#节点亲和性的硬策略，表示必须选择带有标签的值是test3=a
然后kubectl get pod -o wide 就能查看部署到哪个节点了
注：1. 条件不满足，肯定pending
2. 条件满足时，调度器即刻生效，不需要手动调整
3. 需要调度器分配，不同节点可以有相同的标签
软策略
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx1name: nginx
spec:replicas: 3selector:matchLabels:app: nginx1template:metadata:labels:app: nginx1spec:containers:- name: nginximage: nginx:1.22affinity:
#选择亲和性的字段nodeAffinity:
#节点亲和性preferredDuringSchedulingIgnoredDuringExecution:
#软策略- weight: 1preference:matchExpressions:- key: test3operator: NotInvalues:- a
#节点亲和性的软策略，表示希望部署到不包含test3=a的标签节点
注：这里是尽量满足条件，不是必须，所以有可能部署到其他节点上。
多个软策略
affinity:
#选择亲和性的字段nodeAffinity:
#节点亲和性preferredDuringSchedulingIgnoredDuringExecution:- weight: 1preference:matchExpressions:- key: test3operator: NotInvalues:- apreferredDuringSchedulingIgnoredDuringExecution:- weight: 2preference:matchExpressions:- key: test3operator: Invalues:- a
#多个软策略以权重来进行分配，权重高的，优先级大
注：如果已经有硬策略，一般不需要声明软策略。
pod亲和性 pod Affinity
是根据软策略和硬策略来分配的
topologyKey ：定义节点的拓扑域，也就是用来反映pod和节点之间的关系
前提条件：首先要先在节点上创建app=nginx1的pod，得有这个pod才能匹配。
硬策略
affinity:
#选择亲和性的字段podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:#根据标签进行选择matchExpressions:- key: appoperator: Invalues:- nginx1topologyKey: test1
#匹配pod的标签是app=nginx1，且节点上有标签名是test1
注：实际上指向节点的还是topologyKey拓扑域，pod的标签只是倾向性
pod反亲和性 pod Anti-Affinity
注：如果节点上本身没有pod也可以直接创建反亲和性
硬策略
affinity:
#选择亲和性的字段podAntiAffinity:
#pod的反亲和性requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:#根据标签进行选择matchExpressions:- key: appoperator: Invalues:- nginx1topologyKey: test1
#只能部署在pod的标签不是app=nginx1且节点的标签名不能有test1的节点上
注：节点上不能有pod的标签是app=nginx1 且 节点的标签不能有test1
如果以上两个条件有一个满足时还能运行的原因？
答：1.能够部署的原因在于调度器，调度器的核心是为了部署pod，只要能够部署，调度器有可能会忽略规则进行部署，即使有规则，调度器依然会部署。
2. 资源不足的情况下，为了pod能够部署，调度器极有可能忽略所有的限制。
软策略
affinity:
#选择亲和性的字段podAntiAffinity:
#pod的反亲和性preferredDuringSchedulingIgnoredDuringExecution:- weight: 1podAffinityTerm:labelSelector:#根据标签进行选择matchExpressions:- key: appoperator: Invalues:- nginx1topologyKey: test1
总结：其实在pod的亲和性当中，起决定性作用的是拓扑域的标签。
练习题
1、实现pod的探针：就绪探针 用 tocScoket
2、做挂载卷，容器目录：/usr/share/nginx/html/ 、节点目录： /opt/html
3.node的亲和性：尽量部署在node01
4、pod的亲和性：尽量部署包含有app=nginx的pod且标签名是xy102的节点。
5、软策略选择标签名不包含xy102, xy102值小于100
