标签：无法 ica 通过 算法 高效 balancer names 硬件 har
调度器选择策略：
预选策略(Predicate)
1. 根据运行Pod的资源限制来排除不符合要求的Node
2. 根据运行Pod时，是否要求共享宿主机的网络名称空间来判断，如: 某Pod启动要共享宿主机的网络名称空间,启动80端口，而某些Node的80已经被占用，那它就不符合,就也要不排除。
优选策略(Priority)：
此阶段会经过一系列函数，会把预选出来的节点的相关属性都输入到这些函数中，通过计算来获取每个节点的优先分值，然后在倒序排序，取得分最高者，作为运行Pod的节点，若计算后，发现有多个Node得分相同，此时将随机选取一个Node作为该Pod运行的Node。
选定(Select):
当优选选出一个Node后，该Pod将会被绑定到该Node上运行。
我们在定义一个Pod要运行在那个Node，是有一定偏向性的，比如有些Pod需要运行的有SSD硬盘的Node上，而有些Pod则需要运行在有GPU的节点上等，这时就需要我们给Node上打上不同的标签，来标识整个集群中不同Node的特性，这些特性包括，特有硬件标识，地理位置标识，不同机房标识等。
我们使用kubectl explain pod.spec 可以看到其中有nodeName 和 nodeSelector 两个属性，第一个是明确指定Node节点名，我就要运行在这个Node上，第二个就是通过匹配Node标签，来选择运行的Node。
调度方式有以下几类:
1. 节点倾向性（或叫 节点亲和性调度）
这种调度通常会采用 nodeSelector 来完成调度。
2. Pod倾向性 和 Pod非倾向性（这也称为Pod亲和性和非亲和性）
有时候我们需要让某些Pod能运行在同一处时，就需要使用Pod亲和性来定义，如：我们要定义一个NMT(Nginx+Tomcat+MySQL),若这三个Pod分别被调度三个不同地域的机房中，比如北京，上海，深圳等地，那肯定不是我们所希望的，这时我们就需要使用Pod亲和性来定义这三个Pod能运行在相同的Node 或 相邻的Node上。
而在另外一些情况下，我们又希望某些Pod一定不能运行在相同Node上，这时就需要使用Pod的非亲和性了。
3. 污点 和 污点容忍调度
Taints(污点)：是定义在Node上的
Tolerations(容忍): 是定义在Pod上的
污点：指有时我们希望不将某些Pod调度到某些Node上，这时我们可对某些Node上打上污点，然后，当我们创建Pod时，我们可定义此Pod能容忍的污点范围。
假如：NodeA上有5个污点: "吃喝嫖赌抽"，而此次要调度的Pod比较大度，能容忍5个污点，而NodeA的污点正好是Pod能容忍污点的范围内，于是Pod就能"嫁入"该NodeA。
假如，Pod运行到NodeA上后，后期我们又给该NodeA打上了新污点如："坑蒙拐骗偷"，此时Pod发现NodeA的恶性原来有这么多，怎么办？通常有两种选择策略：
1. Pod继续运行在NodeA上"艰苦度日"
2. Pod被驱逐，或者叫Pod逃离。
默认调度器的调度规则是：根据Node最大资源空闲率来进行均衡调度。
调度器：
预选策略
【注意：下面这些预选策略仅是其中一部分，并且k8s在进行预选时，它会是综合评估的，即所有启用的策略规则都要做判断，所得结果越符合就越会被挑选出来，进入优选策略中】：
CheckNodeCondition: 检查节点是否符合调度条件
GeneralPredicates:
HostName: 这种是判断Pod是否定义了pod.spec.hostname属性，若定义了，就在预选时，看看这些Node上是否存在相同主机名的Pod，若有，就排除该Node; 这可能是因为，某些Pod是需要有固定主机名,才会使用。
PodFitsHostPorts: 此预选策略是判断 pods.spec.containers.ports.hostPort 属性是否定义了，若定义了就表示该Pod要绑定到Node上指定的Port上，这时在进行预选时，就要判断这个端口是否被占用了，若占用就会排除该Node。
MatchNodeSeletctor：此预选策略会判断 pods.spec.nodeSelector 属性是否定义了，若定义了就根据Pod所定义的NodeSelector来选出匹配指定标签的Node。
PodFitsResources： 此预选策略会判断 Node上是否符合运行Pod所需的最小空闲资源。
NoDiskConfict: 用于判断若Pod定义了存储卷，则要检查该存储卷在该Node上是否可用，若Node能满足Pod存储卷的使用需求，则表示此Node可用。
PodToleratesNodeTaints：检查Pod上的spec.tolerations可容忍的污点是否完全包含Node上定义的污点，若完全包含，则表示Pod能容忍该Node节点的污点，否则该Node不会通过预选。
PodToleratesNodeNoExecuteTaints：
#首先，污点并非单一属性，它有三种属性，NoExcute是污点的一种属性。
#此检查是，若Pod被调度到某Node上时，最初Node上没有Pod不能容忍的污点，但后来Node的污点改变了,多了Pod不能容忍的污点，这时要怎么处理那？默认是继承既定事实，继续在该Node上运行。
# 第二种是不接受，也就是检查此属性，此时Node会驱逐该Pod，让该Pod重新调度到新Node上。
CheckNodeLabelPresence：这是定义在选择Node时，检查Node上是否存在指定的标签，若存在则可调度。此规则默认不启用。
CheckServiceAffinity： 当我们需要创建一些Pod时，这些Pod都使用相同的Serivce，这时，若启用该预选策略，则将这些Pod优先调度到 已存在较多该Service下的Pod的Node上。
#下面三个默认启用，因为这三个是最大的三个云运营商
MaxEBSVolumeCount：此预选策略是指若Pod需要使用亚马逊的EBS(弹性块存储服务)，则检查该EBS是否已经达到最大运行挂载数39个,若没有，则表示还有存储空间可用。
MaxGCEPDVolumeCount: GCEPD:是Google的云环境中的持久存储，默认是16个
MaxAzureDiskVolumeCount: 最大是16个
CheckVolumeBinding：检查Node上是否存在以绑定 和 未绑定的PVC，若Node上有PVC，并且没有被绑定则能满足Pod运行的需求。
NoVolumeZoneConflict：它是在给定了区域限制的情况下，Zone在IDC机房是有限制的，他们通常会按房间，机柜，机架来划分范围，假如机架上有20台服务器，每2台一个区域，这个就是一个逻辑区域，此配置项的含义就是检查区域中Node上是否存在逻辑卷冲突。
CheckNodeMemoryPressure：检查Node上是否存在内存压力，即若某Node上已经出现内存紧张的情况了，那就不要在往它上面调度了。
CheckNodePIDPressure：检查Node上是否存在PID压力过大的情况，即若某Node上运行的进程过多，导致PID可能紧张，这时在选择调度时，也不会选择它。
CheckNodeDiskPressure：检查Node上是否存在磁盘使用压力过大的情况
MatchInterPodAffinity：检查Node上是否满足Pod的亲和性，假如Pod是Nginx，它是要为Tomcat Pod做代理的，那么在调度tomcat Pod时，就会检查Node上是否有Nginx Pod，若有这个非常亲和的Pod则优先调度到该Node上。
优选函数：
默认启用了7个红色的优选函数，它们的得分相加值越高，该节点越优选被选中。
LeastRequested： 【与它相反对一个优选函数：MostRequested，它是Node资源占用越高得分越高，有点像是,先将某Node的资源先全部占满的意味，然后空出部分Node.】
计算得分的算法公式=（cpu((capacity - sum(requested))*10 / capacity) + memory((capacity - sum(requested))*10 / capacity)）/2
此公式的含义：
假如当前有16个核心，已经用了8个核心，那么总的使用率就是 (16-8)/16 = 0.5 ，而乘以10，是为了计算得分方便，将其转化为0～10之间的数,
而内存的计算含义一样，假如内存32G，已经用了8G，则使用率为 (32-8)/32 = 0.75 ,乘以10
将CPU + Memory/2 就可以得到一个平均值。该平均值越高，表示该节点的资源空闲率越高。
BalanceResourceAllocation:
它表示CPU和内存资源占用率的相近程度，作为评估标准，越接近也优选选择，比如: Node1的CPU和内存使用率一个48%一个50%，而Node2的CPU和内存使用率都是50%，则Node2胜出。
#它通常要和LeastRequested 结合来评估Node的资源利用率的。
#两个组合主要是为了平衡各Node上资源的利用率。
NodePreferAvoidPods：
根据Node节点上是否定义了注解信息"scheduler.alpha.kubernetes.io/preferAvoidPods"，若没有则该Node得分为10，而且权重为1万，有此注解则说明该Node是适合运行Pod的。而对于那些有Replicas Controller的控制器则，该Node的得分为0，此时则表示Pod不能运行在该Node上，但这不能决定Pod一定不能运行在该Node上，因为最终是要看总体得分的。
注解信息：
# kubectl describe node node1.zcf.com
Name: node1.zcf.com
Roles: node
..........
Annotations: node.alpha.kubernetes.io/ttl: 0 #这就是所谓的node上的注解信息。
volumes.kubernetes.io/controller-managed-attach-detach: true
TaintToleration：
基于Pod对调度Node上的污点容忍度来评估是否可调度到该Node上。
简单说：就是取出Pod对象中定义的spec.tolerations列表，查看其中能容忍的污点，然后，一个一个去对比Node上存在的污点，若匹配的越多，则该Node的得分越低，就越不会调度到该Node上。
SelectorSpreading：
此优化函数是希望将相同标签选择器选取的Pod尽可能的散开到多个Node上。因此假如：ReplicaSet控制器，已经在B上创建了一个Pod，那么它要再创建一个Pod时，此优选函数在计算A，B，C三个Node的得分时，会根据那个Node上拥有此ReplicaSet控制器的标签选择器所匹配的Pod数量，来评分，数量越少，分数越高，反之越低。
而使用标签选择器的资源对象有：Service，Replication Controller，ReplicaSet，StatefulSet。
InterPodAffinity：
遍历对象的亲和性条目，并将能够匹配到给定节点的条目的条目数相加结果值越大得分越高。
简单说：NodeA上运行了3个Pod，NodeB上运行了6个Pod，NodeC上运行了5个Pod，现在要调度一个Pod到其中一个Node上，而该Pod的比较亲和某类Pod，此优选函数就会将这些Node上，所有匹配该Pod亲和条目的数量相加，值越大，则越得分越高。其中条目的理解，我还不是很懂。
NodeAffinity：
它是根据pod中定义的nodeSeletor来对Node做亲和性检查， 能成功匹配的数量越多，则得分越高。
NodeLabel:
根据Node是否有某些标签来做评估，然后计算得分的，此优选函数只关注标签，不关注值，只有Node上有这个标签就可以得分。
ImageLocality：
它评分的标准是，判断Node上是否有运行该Pod的镜像，若有则得分，否则不得分。
但它评估镜像是根据镜像总的体积大小来计算得分的，例如：NodeA上有1个镜像1G，NodeB上有2镜像，NodeC上有3个镜像，而运行此Pod需要4个镜像，其中一个镜像1G，其它都是比较小，这时NodeA的得分会最高。
#实验：
1. 定义一个Pod，并设置其nodeSelector，若指定的nodeSeletor标签没有匹配到任何Node，则Pod将处于Pinding状态，只有你给某个Node打上指定的标签和值后，该Pod才会被调度上去。
#实验2：
kubectl explain pods.spec.affinity
nodeAffinity: 定义Node的亲和性
podAffinity： 定义Pod的亲和性
podAntiAffinity：定义Pod非亲和性
nodeAffinity:
# 软亲和性，即若能满足则一定运行在满足条件的Node上,否则运行在其它Node上也不是不可以。
preferredDuringSchedulingIgnoredDuringExecution
#硬亲和性，若不能满足运行条件，则不运行Pod。
requiredDuringSchedulingIgnoredDuringExecution
nodeSelectorTerms:
matchExpressions : 这是更强大的一种方式，它是配表达式的。
matchFields：
key： 要对那个label key做匹配操作
operator：指定你是做什么比较操作，支持: In/NotIn（包含/不包含）, Exists/DoesNotExist（存在/不存在） , Gt/Lt(大于/小于)
values：若操作符为Exists/DoesNotExists则，values必须为空。
vim pod-node-required-affinity.yaml apiVersion: v1 kind: Pod metadata: name: pod-node-affinity-1 labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: zone operator: In values: - foo - bar #默认node上没有打上zone=foo 或 zone=bar的标签，此时是硬亲和,若不能满足条件,则无法调动. vim pod-node-affinity.yaml apiVersion: v1 kind: Pod metadata: name: pod-node-affinity-1 labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1 affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - preference: matchExpressions: - key: zone operator: In values: - foo - bar weight: 60 # 此为软亲和，若node上有zone=foo 或 zone=bar，则优先调度上去，若全部都没有，勉强选一个调度上去也不是不可以
为啥有了节点亲和性，还要有Pod亲和性？
假如我们有一个分布式跨地域的大集群，现在想构建一个NMT的架构，为了实现这个目的，我完全可以给Node上打标签，然后，让NMT这些Pod都匹配这些标签，然后被调度到这些Node上去运行，这不是也可以实现我们的目的吗？
看上去没有问题，但问题是，假如你跨地域的分布式K8s集群，分别分布在北京，上海，深圳，杭州等地，你就不得不精心规划不同地域，不同IDC，不同机房，不同机柜的Node标签规划，否则你很可能在将来实现这个目的是变得困难不堪，你可以想象一下，你希望让一组NMT运行在北京某IDC的某机房中，这样一个NMT架构在工作时，才能更加高效的通信，你想实现这样的控制，你不规划Node的标签，你让预选策略如何按照你的想法去调度那？这还仅是一方面，你为了NMT架构能分离开，北京一套，上海一套.....你也要配置Pod的在选择Node标签时，设定它亲和哪些标签，所以工作量你可自己评估。
Pod亲和性的逻辑时，我要部署NMT环境，我的MySQL Pod第一个被调用，我不管调度器会把MySQL Pod调度到哪里，反正只要调度完成，并且运行了，我后续的Nginx，Tomcat的Pod是亲和MySQL Pod的，MySQL Pod在哪个Node上，那在调度NT时，就更加优先调度到那个Node上。
这样说看上去很简单，但仔细想想，MySQL被调度到某Node上，要是将NT也调度到那个Node上合适吗？若那个Node没有这么多资源运行它们怎么办？能不能将NT调度到M所在Node旁边的Node上，或同机房的Node中？那这算亲和吗？ 其实也算，但怎么知道运行MySQL Pod的Node ，它旁边的Node是否那个主机？这其实还是需要借助于Node标签来实现，因此为集群标签的规划是在所难免的，因为你必须给预选策略一种判断标准，哪些是相同机柜，哪些是不同机房对吧，否则鬼知道集群中那么多Node那个和那个是邻居对吧，当然若你靠主机名来判断也不是不可以，你就要定义根据主机名的判断标准了。所以，比较通用的方法是，给每个Node打上不同的标签，如：北京机房1 机柜20 机架号等等来定义，这样根据这些标签值，就可以判断Node和Node之间的临近关系了。
打个比方： MySQL Pod被调度到 rack=bjYZ1 ，那后续调度NT时，就会优选rack=bjYZ1的Node，只要有这个标签值得Node会被优选调度，这样NMT它们就都可以运行在北京亦庄的机房中了。
kubectl pods.spec.affinity.podAffinity.
requiredDuringSchedulingIgnoredDuringExecution : 硬限制
labelSelector： 指定亲和Pod的标签
namespaces： 你要指定亲和Pod，你就需要指定你亲和的Pod属于哪个名称空间，否则默认是Pod创建在那个名称空间，就匹配那个名称空间的Pod
Pod亲和性示例: vim pod-required-affinity.yaml apiVersion: v1 kind: Pod metadata: name: web1-first labels: app: web1 tier: frontend spec: containers: - name: myapp image: harbor.zcf.com/k8s/myapp:v1 --- apiVersion: v1 kind: Pod metadata: name: db1-second labels: app: db1 tier: db1 spec: containers: - name: busybox image: busybox: latest imagePullPolicy: IfNotPresent command: ["sh", "-c", "sleep 3600"] affinity: podAffinity: #若需要测试Pod的反亲和性，只需要修改podAffinity为 podAntiAffinity 即可测试 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - {key: app, operator: In, values: ["web1","web2"]} topologyKey: kubernetes.io/hostname #通过默认Node上主机名标签来临时代表地区标签,即:只有主机名相同,就认为是在相同位置的。 #Pod反亲和测试： Pod亲和性示例: vim pod-required-affinity.yaml apiVersion: v1 kind: Pod metadata: name: web1-first labels: app: web1 tier: frontend spec: containers: - name: myapp image: harbor.zcf.com/k8s/myapp:v1 --- apiVersion: v1 kind: Pod metadata: name: db1-second labels: app: db1 tier: db1 spec: containers: - name: busybox image: busybox: latest imagePullPolicy: IfNotPresent command: ["sh", "-c", "sleep 3600"] affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - {key: app, operator: In, values: ["web1","web2"]} topologyKey: kubernetes.io/hostname #第一次测试: 使用存在的标签来测试,web1会运行在一个节点上,db1一定不会运行在web1所在的Node上。 topologyKey: zone #第二次测试: 使用此key，因为两个Node上都没有此标签key,因此预选策略将认为,没有找到不同区域的Node，因此db1将处于Pinding状态，无法启动。
vim myapp-toleration.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-toler1 spec: replicas: 2 selector: matchLabels: app: myapp release: canary template: metadata: labels: app: myapp release: canary spec: containers: - name: myapp image: ikubernetes/myapp:v2 ports: - name: http containerPort: 80 tolerations: - key: "node-type" operator: "Equal" value: "production" effect: "NoSchedule" #说明： 在定义Pod的容忍度时，若指定为NoSchedule，则不能定义tolerationSeconds，即容忍不了时,可宽限多久被驱逐。 # 若定义为NoExecute 则可以定义tolerationSeconds。 # Equal：做等值比较，即node-type标签 和 其值必须完全匹配。 # Exists ：做存在性比较，即只要node-type标签存在，即可匹配，不看其标签值是否相同。 #测试NoExecute影响 #目前node2.zcf.com 上定义了node-type污点的影响为: NoExecute ............ tolerations: - key: "node-type" operator: "Exists" value: "" #设置node-type的值为空，因为Exists是做标签判断,只要node-type标签存在,即可. effect: "NoSchedule" #定义污点影响度为NoSchedule,即若Node上没有这个node-type污点标签,就不调度到其上. #若Node上污点影响(effect)为NoExecute，它是不包含NoSchedule的,即Node是不允许不能容忍NoExecute的Pod调度到自己上面的。 #若Pod能容忍node-type标签的污点，无论它是什么值，什么影响，都可以容忍 ............... tolerations: - key: "node-type" operator: "Exists" value: "" effect: "" #删除节点上的污点： kubectl taint node node01.zcf.com node-type- #注意：node-type是：node01上的标签，最后的“-”是删除该标签的意思。
标签：无法 ica 通过 算法 高效 balancer names 硬件 har
原文地址：https://www.cnblogs.com/wn1m/p/11290733.html
