一、pod亲和性
Pod亲和性指的是满足特定条件的的Pod对象运行在同一个node上, 而反亲和性调度则要求它们不能运行于同一node 。
1.1、pod硬亲和性
Pod强制约束的亲和性调度也使用requiredDuringSchedulinglgnoredDuringExecution属性进行定
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy
labels:
app: web
spec:
replicas: 6
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx-deploy
image: nginx:latest
imagePullPolicy: IfNotPresent
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: kubernetes.io/hostname
######启动pod
[root@node1 ~]# kubectl apply -f deploy-pod-Affinity.yaml
deployment.apps/deploy created
######查看如下,所有pod会在一台node上启动
[root@node1 ~]# kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-5b9d5b8b48-2h6qb 1/1 Running 0 6s 172.25.166.150 node1 <none> <none>
deploy-5b9d5b8b48-8dbtf 1/1 Running 0 6s 172.25.166.151 node1 <none> <none>
deploy-5b9d5b8b48-9b895 1/1 Running 0 6s 172.25.166.154 node1 <none> <none>
deploy-5b9d5b8b48-cngp7 1/1 Running 0 6s 172.25.166.149 node1 <none> <none>
deploy-5b9d5b8b48-qpp9n 1/1 Running 0 6s 172.25.166.152 node1 <none> <none>
deploy-5b9d5b8b48-ww7jk 1/1 Running 0 6s 172.25.166.153 node1 <none> <none>
在调度示例中的Deployment控制器创建的Pod资源时,调度器首先会基于标签选择器 查询拥有标签app=db的所有Pod资源,接着获取到它们分别所属 的节点的zone标签值,接下来再查询拥有匹配这些标签值的所有节点,从而完成节点预选。而后根据优选函数计算这些节点的优先级,从而挑选出运行新建Pod对象的节点。
1.2、pod软亲和性
类似于节点亲和性机制,Pod也支持使用preferredDuringSchedulinglgnoredDuringExecution属性定义柔性亲和机制,调度器会尽力确保满足亲和约束的调度逻辑,然而在约束条 件不能得到满足时,它也允许将Pod对象调度至其他节点运行。下面是一个使用了Pod软亲和性调度机制的资源配置清单示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-affinity
spec:
replicas: 5
selector:
matchLabels:
app: myapp
template:
metadata:
name: myapp
labels:
app: myapp
spec:
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 80
podAffinityTerm:
labelSelector:
matchExpressions:
- {key: app, operator: In, values: ["nginx"]}
topologyKey: zone
- weight: 20
podAffinityTerm:
labelSelector:
matchExpressions:
- {key: app, operator: In, values: ["apach"]}
topologyKey: zone
containers:
- name: nginx
image: nginx
######启动pod
[root@node1 ~]# kubectl apply -f pod-soft.yaml
deployment.apps/app-affinity created
#####如下:
[root@node1 ~]# kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
app-affinity-66fbb677c7-2kwjf 1/1 Running 0 3s 172.25.166.158 node1 <none> <none>
app-affinity-66fbb677c7-5thfw 1/1 Running 0 3s 172.25.166.155 node1 <none> <none>
app-affinity-66fbb677c7-drdml 1/1 Running 0 3s 172.25.166.159 node1 <none> <none>
app-affinity-66fbb677c7-qq9fn 1/1 Running 0 3s 172.25.166.156 node1 <none> <none>
app-affinity-66fbb677c7-vq4jg 1/1 Running 0 3s 172.25.166.157 node1 <none> <none>
它定义了两组亲和性判定机制,一个是选择nginx Pod所在节点的zone标签,并赋予了较高的权重80,另一个是选择apach Pod所在节点的 zone标签,它有着略低的权重20。于是,调度器会将目标节点分为四类 :nginx Pod和apach Pod同时所属的zone、nginx Pod单独所属的zone、apach Pod单独所属的zone,以及其他所有的zone。
1.3、pod反亲和性
podAffinity用于定义Pod对象的亲和约束,对应地,将其替换为podAntiAffinty即可用于定义Pod对象的反亲和约束。不过,反亲和性调度一般用于分散同一类应用的Pod对象等,也包括将不同安全级别的Pod对象调度至不同的区域、机架或节点等。下面的资源配置清单中定义了由同一Deployment创建但彼此基于节点位置互斥的Pod对象:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
replicas: 4
template:
metadata:
labels:
app: nginx
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: "kubernetes.io/hostname"
containers:
- name: nginx-server
image: nginx:latest
######如下:启动了4个副本,只有三台node,只有一个pod无法调度,其他pod都是分布在不同node上。
[root@node1 yaml]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-86d6477c48-7mmt2 1/1 Running 0 2m18s 172.25.104.61 node2 <none> <none>
nginx-86d6477c48-f2z2c 1/1 Running 0 2m18s 172.25.135.38 node3 <none> <none>
nginx-86d6477c48-nv5x2 1/1 Running 0 2m18s 172.25.166.143 node1 <none> <none>
nginx-86d6477c48-wsw4x 0/1 Pending 0 2m18s <none> <none> <none> <none>