亲和性
- Node节点亲和性
- 硬亲和实践
- 软亲和性实践
- Pod节点亲和性和反亲和性
- pod亲和性
- 硬亲和实践
- pod反亲和性
Pod 的yaml文件里 spec 字段中包含一个 affinity 字段,使用一组亲和性调度规则,指定pod的调度约束。
kubectl explain pods.spec.affinity
配置说明
- nodeAffinity: node节点亲和性,pod倾向于哪个node
- podAffinity: pod亲和性,pod倾向于哪个pod
- podAntiAffinity: pod的反亲和性,pod排斥于哪个pod
Node节点亲和性
Node节点亲和性 是针对 pod和node 的关系,Pod调度到node节点的时候匹配的条件
node节点亲和性调度字段:nodeAffinity
看nodeAffinity下的配置字段
kubectl explain pods.spec.affinity.nodeAffinity
- preferredDuringSchedulingIgnoredDuringExecution 表示有节点尽量满足这个位置定义的亲和性,这不是一个必须的条件,软亲和性
- requiredDuringSchedulingIgnoredDuringExecution 表示必须有节点满足这个位置定义的亲和性,这是个硬性条件,硬亲和性
硬亲和实践
使用requiredDuringSchedulingIgnoredDuringExecution硬亲和性
Node节点硬亲和性选择匹配方式有2种:
- matchFields: 匹配字段的
- matchExpressions:匹配表达式的 (用的多)
对matchExpressions做进一步解读
matchExpressions——匹配表达式的写法:
kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions
字段配置:
- key:匹配节点标签的KEY(必填)
- operator:表示键与一组值的关系(必填),可选的枚举值如下:
- In (包含)
- NotIn(不包含)
- Exists (存在)
- DoesNotExist (不存在)
- Gt (大于)
- Lt (小于)
- values:给定值
示例 :把pod调度到集群中 拥有zone标签 并且值是foo或者bar的node节点上
创建pod资源文件
vim pod-nodeaffinity-demo.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-node-affinity-demonamespace: default
spec:affinity: # 设置亲和性调度规则nodeAffinity: # 设置node亲和性requiredDuringSchedulingIgnoredDuringExecution: # 使用硬亲和性nodeSelectorTerms: # 配置节点选择器规则- matchExpressions: # 匹配表达式的- key: zone # 节点标签的keyoperator: In # 使用表达式为包含values: # 包含的值有(foo或者bar)- foo- barcontainers:- name: myappimage: docker.io/ikubernetes/myapp:v1imagePullPolicy: IfNotPresent
创建资源
kubectl apply -f pod-nodeaffinity-demo.yaml
查看pod
kubectl get pods -o wide
status的状态是pending,上面说明没有完成调度,因为没有一个节点拥有zone的标签
值是foo或者bar,而且使用的是硬亲和性,必须满足条件才能完成调度
给k8s-node1节点打上标签zone=foo,再查看
kubectl label nodes k8s-node1 zone=foo
kubectl get pods -o wide
pod调度到了k8s-node1节点上
软亲和性实践
使用preferredDuringSchedulingIgnoredDuringExecution软亲和性
示例
创建pod资源文件
vim pod-nodeaffinity-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-node-affinity-demo-2namespace: default
spec:containers:- name: myappimage: docker.io/ikubernetes/myapp:v1imagePullPolicy: IfNotPresentaffinity: # 设置亲和性调度规则nodeAffinity: # 设置node亲和性preferredDuringSchedulingIgnoredDuringExecution: # 使用软亲和性- preference:matchExpressions: # 匹配表达式的- key: zone1 # 节点标签的keyoperator: In # # 使用表达式为包含values: # 包含的值有(foo1或者bar1)- foo1- bar1weight: 10 # 匹配度权重- preference:matchExpressions:- key: zone2operator: Invalues:- foo2- bar2weight: 20 # weight是相对权重,权重越高,pod调度的几率越大
创建资源
kubectl apply -f pod-nodeaffinity-demo-2.yaml
查看pod
kubectl get pods -o wide |grep pod-node-affinity-demo-2
上面说明软亲和性是可以运行这个pod的,尽管没有运行这个pod的节点定义的zone1标签
测试weight权重
先删除pod-node-affinity-demo-2
(ps. 执行强制删除的命令,加上“–force --grace-period=0”)
kubectl delete pod pod-node-affinity-demo-2 --force --grace-period=0
给k8s-node1和k8s-node2都打上标签
kubectl label nodes k8s-node1 zone1=foo1kubectl label nodes k8s-node2 zone2=foo2
再创建资源
kubectl apply -f pod-nodeaffinity-demo-2.yaml
查看pod
kubectl get pods -o wide
pod在定义node节点亲和性的时候,k8s-node1和k8s-node2都满足调度条件,但是k8s-node2具有的标签是zone2=foo2,pod在匹配zone2=foo2的权重高,那么pod就会优先调度到k8s-node2上
Pod节点亲和性和反亲和性
Pod节点亲和性 是针对 pod和pod 的关系
有两种表示形式
-
podAffinity:pod和pod更倾向在一起,把相近的pod结合到相近的位置。
这样的话pod和pod之间更好通信。比方希望把nginx和tomcat都部署同一个地方的node节点上,可以提高通信效率; -
podAntiAffinity:pod和pod不倾向在一起。如果部署两套程序,那么这两套程序更倾向于反亲和性,这样相互之间不会有影响。
运行方式
第一个pod随机选则一个节点,例如:节点A。做为 评判后续的pod 能否到达节点A上。到达 就称为pod亲和性,反之是反亲和性。
以节点名称为标准,这个节点名称相同的表示是同一个位置,节点名称不相同的表示不是一个位置。
pod亲和性
pod亲和性调度字段:podAffinity
看podAffinity下的配置字段
kubectl explain pods.spec.affinity.podAffinity
- requiredDuringSchedulingIgnoredDuringExecution 硬亲和性
- preferredDuringSchedulingIgnoredDuringExecution 软亲和性
硬亲和实践
使用requiredDuringSchedulingIgnoredDuringExecution硬亲和性
kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution
解释说明
- topologyKey:位置拓扑的键,节点的标签(必填)
怎么判断是不是同一个位置,例如:
rack=rack1 使用rack的键是同一个位置
row=row1 使用row的键是同一个位置 - labelSelector:判断pod跟别的pod亲和,通过labelSelector选则一组能作为亲和对象的pod资源
- namespace:指定匹配资源的命名空间,如果不指定namespaces,那么就是当前创建pod的名称空间
- namespaceSelector: :指定匹配资源的命名空间集合,空选择器({})匹配所有命名空间。
对labelSelector进一步解析:
labelSelector——对pod资源的标签查询
kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.labelSelector
字段配置:
- matchExpressions:匹配表达式
- matchLabels:匹配标签
示例1: 定义两个pod,第一个pod做为基准,第二个pod跟着它走
创建第一个pod资源文件
vim pod-required-affinity-demo-1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-firstlabels:app: myapp
spec:containers:- name: myappimage: ikubernetes/myapp:v1imagePullPolicy: IfNotPresent
创建第一个pod资源
kubectl apply -f pod-required-affinity-demo-1.yaml
创建第二个pod资源文件,让第二个pod和第一个pod做亲和性
vim pod-required-affinity-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-secondlabels:app: backend
spec:containers:- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentcommand: ["sh","-c","sleep 3600"]affinity:podAffinity: #使用pod亲和性requiredDuringSchedulingIgnoredDuringExecution: #使用硬亲和性- topologyKey: kubernetes.io/hostname # 设置位置拓扑的键labelSelector: # 设置对pod资源的标签查询matchExpressions: # 用匹配表达式:找pod标签中key是app 值包含myapp的- {key: app, operator: In, values: ["myapp"]}
上面表示新创建的pod必须与拥有 “app=myapp” 标签的pod在一个节点上
创建第二个pod资源
kubectl apply -f pod-required-affinity-demo-2.yaml
查看pod
kubectl get pods -o wide
上面说明第一个pod调度到哪,第二个pod也调度到哪,这就是pod节点亲和性
示例2 :接着上面的实验,调整一下pod2 ,让 labelSelector满足 pod1的标签,但是topologyKey不满足pod1所在的node的特点
调整第二个pod资源文件
vim pod-required-affinity-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-secondlabels:app: backend
spec:containers:- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentcommand: ["sh","-c","sleep 3600"]affinity:podAffinity: #使用pod亲和性requiredDuringSchedulingIgnoredDuringExecution: #使用硬亲和性- topologyKey: zone2 # 设置node1节点没有的标签keylabelSelector: matchExpressions: - {key: app, operator: In, values: ["myapp"]}
重建第二个pod资源
kubectl delete -f pod-required-affinity-demo-2.yamlkubectl apply -f pod-required-affinity-demo-2.yaml
查看pod
kubectl get pods -o wide
上面说明 labelSelector和topologyKey必须同时满足才能找到要调度的节点
pod反亲和性
一切配置都是反着来。
例如 硬亲和性
解释说明
- topologyKey:不去有位置拓扑的键的节点上(必填)
- labelSelector:判断pod跟别的pod反亲和
示例1: 定义两个pod,第一个pod做为基准,第二个pod跟它调度节点相反
创建第一个pod资源文件
vim pod-required-anti-affinity-demo-1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-firstlabels:app1: myapp1
spec:containers:- name: myappimage: ikubernetes/myapp:v1imagePullPolicy: IfNotPresent
创建第一个pod资源
kubectl apply -f pod-required-anti-affinity-demo-1.yaml
创建第二个pod资源文件
vim pod-required-anti-affinity-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-secondlabels:app: backend
spec:containers:- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentcommand: ["sh","-c","sleep 3600"]affinity:podAntiAffinity: #使用pod反亲和性requiredDuringSchedulingIgnoredDuringExecution: #使用硬亲和性- topologyKey: kubernetes.io/hostname labelSelector: # 设置对pod资源的标签查询matchExpressions: # 用匹配表达式:pod标签中key是app1 值包含myapp1的- {key: app1, operator: In, values: ["myapp1"]}
创建第二个pod资源
kubectl apply -f pod-required-anti-affinity-demo-2.yaml
查看pod
kubectl get pods -o wide
显示两个pod不在一个node节点上,这就是pod节点反亲和性
示例2: 看 topologykey + labelSelector同时满足时,第二个pod的情况
给节点都打上“zone=foo” 标签
kubectl label nodes k8s-node2 zone=fookubectl label nodes k8s-node1 zone=foo
创建第一个pod资源文件
vim pod-first-required-anti-affinity-demo-1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-firstlabels:app3: myapp3
spec:containers:- name: myappimage: ikubernetes/myapp:v1imagePullPolicy: IfNotPresent
创建第一个pod资源
kubectl apply -f pod-first-required-anti-affinity-demo-1.yaml
创建第二个pod资源文件
vim pod-second-required-anti-affinity-demo-1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-secondlabels:app: backendtier: db
spec:containers:- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentcommand: ["sh","-c","sleep 3600"]affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- {key: app3 ,operator: In, values: ["myapp3"]}topologyKey: zone
创建第二个pod资源
kubectl apply -f pod-second-required-anti-affinity-demo-1.yaml
查看pod
kubectl get pods -o wide
第二个pod是pending,因为两个节点是同一个位置,现在没有不是同一个位置的了,而且要求反亲和性,所以就会处于pending状态,如果在反亲和性这个位置把硬反亲和改成软反亲和,那么也会运行。