1.前言
k8s的亲和性和反亲和性都是通过标签来影响pod的调度,在此基础上亲和性又分为硬亲和性和软亲和性,required为硬亲和性即标签内容必须要符合才能调度,preferred为软亲和性即标签内容不一定要符合也能调度,除此之外还有node亲和性和pod亲和性,接下来都使用一下这些亲和性的功能
2.node亲和性
2.1node软亲和性
先编辑一个yaml文件
vi deployment-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: default
spec:
replicas: 5
progressDeadlineSeconds: 600
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
affinity: #亲和性配置项
nodeAffinity: #node亲和性配置项
preferredDuringSchedulingIgnoredDuringExecution: #软亲和性配置项
- weight: 70 #配置权重
preference:
matchExpressions:
- key: key1 #配置标签key的值
operator: In #配置操作符
values: #配置标签values的值
- value1
- weight: 30 #配置权重
preference:
matchExpressions:
- key: key2
operator: In
values:
- value2
配置一下node节点的标签,给node01节点打上权重高的标签,node02节点打上权重低的标签
kubectl label node k8s-node01 key1=value1
kubectl label node k8s-node02 key2=value2
执行yaml文件
kubectl create -f deployment-nginx.yaml
查看一下pod再node上的分配情况
kubectl get pod -o wide -n default -l app=nginx
可以看到node01上分配的pod比node02节点多,这就是权重导致的,软亲和性是不强制要求调度到特定节点的,可以把node节点的label标签删掉,再重新创建delpoyment,pod依然能正常调度,我这里只贴一下效果,就不展示过程了
2.2node硬亲和性
编辑一下yaml文件
vi deployment-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: default
spec:
replicas: 5
progressDeadlineSeconds: 600
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: #硬亲和性配置项
nodeSelectorTerms: #通过 nodeSelectorTerms,可以指定多个节点标签的匹配规则,从而更加灵活地控制 Pod 的调度,再有多个nodeSelectorTerms时,他们的关系为或,即node节点满足任意一个nodeSelectorTerms中的规则时,就可以把pod调度到该节点上
- matchExpressions: #通过 matchExpressions,可以精确地指定一个节点标签的匹配规则,从而更加精细地控制 Pod 的调度,在使用多个matchExpressions的情况下,他们的关系为且,即node节点需要满足所有matchExpressions项的规则才可以把pod调度到该节点上
- key: key1
operator: In
values: #这里配置了两个values值,因为控制项使用的是In,只要node满足其中一个即可调度
- value1
- value2
我现在的node节点上是没有标签的,先来测试一下pod的调度情况
可以看到因为设置了硬亲和性的原因pod调度不到任何一个node节点上,状态为pending,接下来我们给node01打上符合yaml文件硬亲和性的标签看看效果
kubectl label node k8s-node01 key1=value1
可以看到给node01节点打上标签后,所有pod都调度到了node01节点上了
3.pod亲和性和反亲和性
3.1pod软亲和性
编辑一下yaml文件
vi deployment-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: default
spec:
replicas: 5
progressDeadlineSeconds: 600
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
affinity:
podAffinity: #pod亲和性配置项
preferredDuringSchedulingIgnoredDuringExecution: #软亲和性配置项
- weight: 70 #配置权重
podAffinityTerm:
labelSelector:
matchExpressions:
- key: key1
operator: In
values:
- value1
topologyKey: zone #在 PodAffinity 中,topologyKey 配置项用于指定 Pod 应该调度到哪些节点上。例如,可以将 topologyKey 设置为 kubernetes.io/hostname,这样 Pod 将调度到与它在同一主机上的节点上
- weight: 30
podAffinityTerm:
labelSelector:
matchExpressions:
- key: key2
operator: In
values:
- value2
topologyKey: zone
执行以下yaml文件看一下效果
kubectl create -f deployment-nginx.yaml
pod软亲和性表示Pod将尽可能被调度到与它们亲和的pod所在的节点上,但如果没有符合条件的pod,Pod仍然可以被调度到其他节点上
3.2pod硬亲和性
编辑一下yaml文件
vi deployment-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: default
spec:
replicas: 5
progressDeadlineSeconds: 600
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution: #硬亲和性配置项
- labelSelector:
matchExpressions:
- key: key1
operator: In
values:
- value1
topologyKey: kubernetes.io/hostname
执行以下yaml文件看一下效果
kubectl create -f deployment-nginx.yaml
现在集群中是没有pod的,没有可以满足pod硬性亲和条件的pod,所以pod无法调度,现在创建两个不符合以上条件标签的pod看看效果
vi web1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: web
name: web1
spec:
replicas: 2
selector:
matchLabels:
key3: value3
template:
metadata:
labels:
key3: value3 #这里pod使用的标签和上面亲和性的标签不一致
spec:
containers:
- image: nginx:1.19
name: nginx1
kubectl create -f web1.yaml
kubectl get pod -o wide
可以看到依旧没有满足硬亲和性调度的条件,pod还是pending状态,接下来创建一个符合以上条件标签的pod看看效果
vi web.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: web
name: web
spec:
replicas: 1
selector:
matchLabels:
key1: value1
template:
metadata:
labels:
key1: value1 #此处使用与硬亲和性条件一样的label
spec:
containers:
- image: nginx:1.19
name: nginx
kubectl create -f web.yaml
kubectl get pod -o wide
可以看到有满足硬亲和性条件标签的pod后,所有pod都调度到了与该pod相同的节点上
pod硬亲和性表示Pod必须被调度到与它们亲和的pod的节点上,否则它们将无法被调度
3.3pod硬反亲和性
编辑一下yaml文件
vi deployment-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: default
spec:
replicas: 5
progressDeadlineSeconds: 600
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
affinity:
podAntiAffinity: #反亲和性配置项
requiredDuringSchedulingIgnoredDuringExecution: #硬反亲和性配置项
- labelSelector:
matchExpressions:
- key: key1
operator: In
values:
- value1
topologyKey: zone #避免pod调度到故障节点上
上一个试验创建的web和web1的pod还没删除,使用他们来验证一下硬反亲和性,web使用的标签是符合硬反亲和性的条件,执行一下这个yaml看看效果
kubectl create -f deployment-nginx.yaml
kubectl get pod -o wide
可以看到因为硬反亲和性的原因,所有创建的nginx pod都和web pod不在同一个节点上
3.4pod软反亲和性
编辑一下yaml文件
vi deployment-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: default
spec:
replicas: 5
progressDeadlineSeconds: 600
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
affinity:
podAntiAffinity: #反亲和性配置项
preferredDuringSchedulingIgnoredDuringExecution: #软反亲和性配置项
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: key1
operator: In
values:
- value1
topologyKey: zone
依然使用带有符合反亲和性条件的web pod,执行一下yaml看看效果
kubectl create -f deployment-nginx.yaml
kubectl get pod -o wide
可以看到因为软反亲和性的原因,有一些nginx pod调度到了和web pod相同的节点上
亲和性和反亲和性的使用展示就这么多,接来下所以下上面使用到的配置项的补充
operator:用于指定匹配规则的操作符,operator参数可以设置为In、NotIn、Exists、DoesNotExist、Gt、Lt、Gte、Lte、DoubleEqual、NotEqual等值中的一种
In:表示标签的值必须包含在给定的值列表中
NotIn:表示标签的值不能包含在给定的值列表中
Exists:表示标签必须存在
DoesNotExist:表示标签必须不存在
Gt:表示标签的值必须大于给定的值
Lt:表示标签的值必须小于给定的值
Gte:表示标签的值必须大于或等于给定的值
Lte:表示标签的值必须小于或等于给定的值
DoubleEqual:表示标签的值必须等于给定的值
NotEqual:表示标签的值不能等于给定的值