K8s：pod调度

K8s pod调度

1、node级别

1、作用

与节点标签匹配的 nodeSelector
亲和性与反亲和性
nodeName 字段
Pod 拓扑分布约束（反亲和）

2、使用场景

看公司业务需求
普通场景：nodeSelector
复杂场景：亲和和反亲和

3、目的

基于node标签、去干预调度结果

4、使用案例

1、nodeSeelector
	
	1.1、先给node打上标签、然后pod去匹配就行了
	1.2、节点使用资源：就使用nodeSelector就可以了
		 写法：跟containers写法同级的

2、nodename（根据node的名称或者ip地址、这个方式很少用）
	2.1、在同一个k8s集群、nodename是不会重复的
	2.2、运行hostpash的容器（MySQL）

	2.3、写法：也是一样的、跟containers是同级的

	2.4、问题：如果node节点挂掉、pod就不会调度到别的节点上、就不会去匹配了、找不到就pending了

3、node affinity（分为必须满足和倾向满足）

	2.1、必须满足：必须满足pod调度匹配条件、如果不满足就不进行调度
	2.2、倾向满足：倾向满足pod调度匹配条件、不满足的情况下会调度到不符合条件的node上（选择一个接近满足）

注意：pod运行在一个node之后、修改pod标签、导致亲和请pod不能满足、也会继续运行pod、下次重新启动修改策略
	 pod有时候需要打散、redis集群、zookeeper集群

3.1、硬亲和（硬匹配）###case3-1.2-nodeAffinity-requiredDuring-matchExpressions.yaml（）
				  ###case3-1.1-nodeAffinity-requiredDuring-matchExpressions.yaml（调度）
affinity:###（这一行跟containers同级别）
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
1、调度到有标签的节点
2、如果有任意节点满足的话、就直接调度
3、如果没有任何一个节点匹配、就调度失败 pending
4、如果使用matchExpressions里面有多个key、都必须同时符合、有一个不符合就调度失败



总结：这个有两种写法：
		1、写一个matchExpressions 多个key、同时必须都满足才能调度、否者就pending
		2、如果写两个matchExpressions、任意一个matchExpressions里面的key对应的values、我只要匹配到一个values就调度到该节点。

3.2、软亲和
affinity:###（这一行跟containers同级别） case3-2.1-nodeAffinity-preferredDuring.yaml
    nodeAffinity:
	  preferredDuringSchedulingIgnoredDuringExecution:
	  - weight: 80
注意：不做强制要求、但是会优选调度到符合条件的节点上

	1、根据权重调度到不同的节点、先根据第一个软亲和配置的权重调度、不合适再根据第二个软亲和权重的调度、如果都不合适、最后还是会选择一个接近的调度。
	

3.3、软硬亲和混合使用###case3-2.2-nodeAffinity-requiredDuring-preferredDuring.yaml
	1、硬亲和取反（我的pod绝对不会调度到那个节点上去）（根据node标签去匹配）
	2、然后再软亲和、根据权重去匹配、调度pod


总结：就是搭配使用：先硬性反亲和（把不想调度的节点赛选掉）、再软亲和去匹配节点。

3.4、硬亲和取反（硬性反亲和）###case3-3.1-nodeantiaffinity.yaml
	NotIn（绝对不会把我这个pod调度到那个节点上、取反去调度）

运行结果

1、如果希望pod运行在一组服务器、能成功就成功、不成功就失败、就使用硬亲和。
2、如果希望一组pod尽可能运行在一组节点上面去、调度到别的资源、就使用软亲和。

5、命令

###获取节点标签（然后查看labels）
[root@k8s-31:~]# kubectl  describe  node 10.0.0.31
[root@k8s-31:~]# kubectl  describe  node  k8s-31


##打标签
kubectl label  node  k8s-33  disktype="hdd"

2、pod级别亲和及反亲和

1、使用场景

pod反亲和（就是打散pod、zookeeper、Kafka、etcd集群、不让它们运行在同一个node中）

故障域（以node节点、以可用区为故障域）
	公有云指定可用区（私有云一般都是）
	私有云一般都是node节点

2、注意

1、在pod硬亲和和反亲和中toplogKey都不允许为空
2、可以修改准入控制器、对于硬性的pod反亲和（对于公有云都是调正好的、私有云都是基于node调整）、可以理解成硬性反亲和的情况下就是hostname。使用其他的就去该控制器。

3、实战

###根据pod的标签去调度：

1、创建一个pod（基于一个nginx调度） ###case4-4.1-nginx.yaml
	注意：定义一个pod标签：如下
		app: python-nginx-selector
    	project: python

2、创建一个tomcat调度到同一个节点（把tomcat和nginx调度到一块、节省网络开销、实现不跨主机调用）


###实现方式：
1、软亲和:###case4-4.2-podaffinity-preferredDuring.yaml
    preferredDuringSchedulingIgnoredDuringExecution
	定义标签去匹配、匹配到就调度、匹配不到就选择其他节点调度。
	一定要指定那么ns去找pod的标签。
	软亲和即使没有匹配成功、也会被调度。（把副本数量调高、就会调度到别的节点）

2、硬亲和:###case4-4.3-podaffinity-requiredDuring.yaml
	requiredDuringSchedulingIgnoredDuringExecution
	一定要把tomcat的pod和nginx的pod调度到一块、如果调度失败就pending
	前提是以主机位颗粒度、
	不管多少个pod副本都会调度到一个节点
	作用：多个pod之间调用、降低pod资源开销、减少网络距离、提高网络性能。

3、反亲和:（硬性反亲和）###case4-4.4-podAntiAffinity-requiredDuring.yaml
	使用场景:	MySQL主从、ES、zookeeper集群、Kafka集群
	作用：将有状态、集群的服务打散、打散到不同的可用区或者不同的节点。
		 绝对不会将pod匹配到的标签调度到同一个节点。
		 两个pod绝对不会在一块
		 
4、反亲和:（软性反亲和）###case4-4.5-podAntiAffinity-preferredDuring.yaml
	作用：尽量和匹配到pod的标签的主机调度不到一块、如果说没有可用的主机、还是会调度到一块。
	限制：软性反亲和的限制不是很严格。