k8s之亲和性、反亲和性
k8s中亲和性与反亲和性
Kubernetes的默认调度器以预选、优选、选定机制完成将每个新的Pod资源绑定至为其选出的目标节点上,不过,它只是Pod对象的默认调度器,默认情况下调度器考虑的是资源足够,并且负载尽量平均。
在使用中,用户还可以自定义调度器插件,并在定义Pod资源配置清单时通过spec.schedulerName指定即可。
一、node亲和性
NodeAffinity意为Node节点亲和性的调度策略,是用于替换NodeSelector的全新调度策略。
定义节点亲和性规则时有两种类型的节点亲和性规则 :硬亲和性required和软亲和性preferred。 硬亲和性实现的是强制性规则,它是Pod调度时必须要满足的规则,而在不存在满足规则的节点时 , Pod对象会被置为Pending状态。 而软亲和性规则实现的是一种柔性调度限制,它倾向于将Pod对象运行于某类特定的节点之上,而调度器也将尽量满足此需求,但在无法满足调度需求时它将退而求其次地选择一个不匹配规则的节点。
1.1、nodeSelector
对于最初的k8s实现pod指定node调度时使用nodeSelector来实现的,主要是通过定义node以及pod标签进行选择,具体实现如下:
为节点添加label标签
[root@node1 ~]# kubectl label node node2 app=web
node/node2 labeled
######
定义deployment启动pod,如下:
---
apiVersion: apps/v1
kind: Deployment
metadata:name: deploylabels:app: web
spec:replicas: 13selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:nodeSelector:app: web ###选择标签containers:- name: nginx-deployimage: nginx:latestimagePullPolicy: IfNotPresent[root@node1 ~]# kubectl apply -f deploy-pod.yaml
deployment.apps/deploy created
[root@node1 ~]#
########
查看pod启动所在的节点,如下:
[root@node1 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-6cb97b569b-292kw 1/1 Running 0 11s 172.25.104.62 node2 <none> <none>
deploy-6cb97b569b-2qbfm 1/1 Running 0 11s 172.25.104.52 node2 <none> <none>
deploy-6cb97b569b-58px4 1/1 Running 0 11s 172.25.104.54 node2 <none> <none>
deploy-6cb97b569b-7cmqv 1/1 Running 0 11s 172.25.104.56 node2 <none> <none>
deploy-6cb97b569b-cmq74 1/1 Running 0 11s 172.25.104.57 node2 <none> <none>
deploy-6cb97b569b-cpv8x 1/1 Running 0 11s 172.25.104.59 node2 <none> <none>
deploy-6cb97b569b-d9hwz 1/1 Running 0 11s 172.25.104.63 node2 <none> <none>
deploy-6cb97b569b-f2zwf 1/1 Running 0 11s 172.25.104.60 node2 <none> <none>
deploy-6cb97b569b-f6hbl 1/1 Running 0 11s 172.25.104.61 node2 <none> <none>
deploy-6cb97b569b-kz46f 1/1 Running 0 11s 172.25.104.58 node2 <none> <none>
deploy-6cb97b569b-mjmnv 1/1 Running 0 11s 172.25.104.55 node2 <none> <none>
deploy-6cb97b569b-nkdwm 1/1 Running 0 11s 172.25.104.51 node2 <none> <none>
deploy-6cb97b569b-tg7qc 1/1 Running 0 11s 172.25.104.53 node2 <none> <none>
1.2、node硬亲和性
为Pod对象使用nodeSelector属性可以基于节点标签匹配的方式将Pod对象强制调度至某一类特定的节点之上 ,不过它仅能基于简单的等值关系定义标签选择器,而nodeAffinity中支持使用 matchExpressions属性构建更为复杂的标签选择机制。
---
apiVersion: apps/v1
kind: Deployment
metadata:name: deploylabels:app: web
spec:replicas: 6selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: nginx-deployimage: nginx:latestimagePullPolicy: IfNotPresentaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution: # 硬策略nodeSelectorTerms:- matchExpressions:- key: appoperator: Invalues:- web
######
为node添加标签,如下:
[root@node1 ~]# kubectl label node node2 app=web
node/node2 labeled######
启动pod,如下pod都起在node上:
[root@node1 ~]# kubectl apply -f deploy-pod.yaml
deployment.apps/deploy created
[root@node1 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-66747445f7-25pwb 1/1 Running 0 14s 172.25.104.5 node2 <none> <none>
deploy-66747445f7-4qdf7 1/1 Running 0 14s 172.25.104.10 node2 <none> <none>
deploy-66747445f7-f24bq 1/1 Running 0 14s 172.25.104.20 node2 <none> <none>
deploy-66747445f7-f9vbq 1/1 Running 0 14s 172.25.104.34 node2 <none> <none>
deploy-66747445f7-gx4mq 1/1 Running 0 14s 172.25.104.28 node2 <none> <none>
deploy-66747445f7-zwtc8 1/1 Running 0 14s 172.25.104.33 node2 <none> <none>
在定义节点亲和性时,requiredDuringSchedulinglgnoredDuringExecution字段的值是一个对象列表,用于定义节点硬亲和性,它可由一到多个nodeSelectorTerm定义的对象组成, 彼此间为“逻辑或”的关系,进行匹配度检查时,在多个nodeSelectorTerm之间只要满足其中之一 即可。
preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution名字中的后半段符串IgnoredDuringExecution隐含的意义所指,在Pod资源基于节点亲和性规则调度至某节点之后,节点标签发生了改变而不再符合此节点亲和性规则时 ,调度器不会将Pod对象从此节点上移出,因为,它仅对新建的Pod对象生效。
nodeSelectorTerm用于定义节点选择器条目,其值为对象列表,它可由一个或多个matchExpressions对象定义的匹配规则组成,多个规则彼此之间为“逻辑与”的关系, 这就意味着某节点的标签需要完全匹配同一个nodeSelectorTerm下所有的matchExpression对象定义的规则才算成功通过节点选择器条目的检查。而matchExmpressions又可由 一到多 个标签选择器组成,多个标签选择器彼此间为“逻辑与”的关系 。
---
apiVersion: apps/v1
kind: Deployment
metadata:name: deploylabels:app: web
spec:replicas: 6selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: nginx-deployimage: nginx:latestimagePullPolicy: IfNotPresentaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution: # 硬策略nodeSelectorTerms:- matchExpressions:- key: appoperator: Invalues:- server- web
#######为node2和node3打标签
[root@node1 ~]# kubectl label node node2 app=web
node/node2 labeled
[root@node1 ~]# kubectl label node node3 app=server
node/node3 labeled
########启动pod,如下会在node2和node3上调度
[root@node1 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-d78b4d4d9-5hb4k 1/1 Running 0 2m17s 172.25.104.47 node2 <none> <none>
deploy-d78b4d4d9-l8tjk 1/1 Running 0 2m17s 172.25.135.61 node3 <none> <none>
deploy-d78b4d4d9-mcvsk 1/1 Running 0 2m17s 172.25.135.60 node3 <none> <none>
deploy-d78b4d4d9-mj7gk 1/1 Running 0 2m17s 172.25.104.43 node2 <none> <none>
deploy-d78b4d4d9-r5xqn 1/1 Running 0 2m17s 172.25.104.45 node2 <none> <none>
deploy-d78b4d4d9-zl684 1/1 Running 0 2m17s 172.25.104.46 node2 <none> <none>
构建标签选择器表达式中支持使用操作符有In、Notln、Exists、DoesNotExist、Lt和Gt等
In:label的值在某个列表中
NotIn:label的值不在某个列表中
Gt:label的值大于某个值
Lt:label的值小于某个值
Exists:某个label存在 #####values为任意值。
DoesNotExist:某个label不存在
1.3、node软亲和性
节点软亲和性为节点选择机制提供了一种柔性控制逻辑,被调度的Pod对象不再是“必须”而是“应该”放置于某些特定节点之上,当条件不满足时它也能够接受被编排于其他不符合条件的节点之上。另外,它还为每种倾向性提供了weight属性以便用户定义其优先级,取值范围是1 ~ 100,数字越大优先级越高 。
---
apiVersion: apps/v1
kind: Deployment
metadata:name: deploylabels:app: web
spec:replicas: 6selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: nginx-deployimage: nginx:latestimagePullPolicy: IfNotPresentaffinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 60 ###设置app=web的权重为60preference:matchExpressions:- key: appoperator: Invalues:- web- weight: 40 ###设置app=server的权重为40preference:matchExpressions:- key: appoperator: Invalues:- server#####启动pod如下,会发现大部分pod在app=web的node上
[root@node1 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-55bf777f76-5466z 1/1 Running 0 9m9s 172.25.104.50 node2 <none> <none>
deploy-55bf777f76-62rrz 1/1 Running 0 9m9s 172.25.104.49 node2 <none> <none>
deploy-55bf777f76-bf9bn 1/1 Running 0 9m9s 172.25.104.48 node2 <none> <none>
deploy-55bf777f76-lx5pz 1/1 Running 0 9m9s 172.25.104.53 node2 <none> <none>
deploy-55bf777f76-s78v5 1/1 Running 0 9m9s 172.25.135.62 node3 <none> <none>
deploy-55bf777f76-t9cw9 1/1 Running 0 9m9s 172.25.104.63 node2 <none> <none>
二、pod亲和性
Pod亲和性指的是满足特定条件的的Pod对象运行在同一个node上, 而反亲和性调度则要求它们不能运行于同一node 。
2.1、pod硬亲和性
Pod强制约束的亲和性调度也使用requiredDuringSchedulinglgnoredDuringExecution属性进行定
---
apiVersion: apps/v1
kind: Deployment
metadata:name: deploylabels:app: web
spec:replicas: 6selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: nginx-deployimage: nginx:latestimagePullPolicy: IfNotPresentaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- webtopologyKey: 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对象的节点。
2.2、pod软亲和性
类似于节点亲和性机制,Pod也支持使用preferredDuringSchedulinglgnoredDuringExecution属性定义柔性亲和机制,调度器会尽力确保满足亲和约束的调度逻辑,然而在约束条 件不能得到满足时,它也允许将Pod对象调度至其他节点运行。下面是一个使用了Pod软亲和性调度机制的资源配置清单示例
apiVersion: apps/v1
kind: Deployment
metadata:name: app-affinity
spec:replicas: 5selector:matchLabels:app: myapptemplate:metadata:name: myapplabels:app: myappspec:affinity:podAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 80podAffinityTerm:labelSelector:matchExpressions:- {key: app, operator: In, values: ["nginx"]}topologyKey: zone- weight: 20podAffinityTerm:labelSelector:matchExpressions:- {key: app, operator: In, values: ["apach"]}topologyKey: zonecontainers:- name: nginximage: 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。
2.3、pod反亲和性
podAffinity用于定义Pod对象的亲和约束,对应地,将其替换为podAntiAffinty即可用于定义Pod对象的反亲和约束。不过,反亲和性调度一般用于分散同一类应用的Pod对象等,也包括将不同安全级别的Pod对象调度至不同的区域、机架或节点等。下面的资源配置清单中定义了由同一Deployment创建但彼此基于节点位置互斥的Pod对象:
---
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx
spec:selector:matchLabels:app: nginxreplicas: 4template:metadata:labels:app: nginxspec:affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- nginxtopologyKey: "kubernetes.io/hostname"containers:- name: nginx-serverimage: 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>
参考链接:链接
k8s之亲和性、反亲和性相关推荐
- k8s调度之node的亲和性以及pod的亲和性/反亲和性
k8s调度之node的亲和性以及pod的亲和性/反亲和性 通常情况下,使用的都是k8s默认的调度调度方式,但是在有些情况下,我们需要将pod运行在具有特定的标签的node上才能都运行,这个时候,pod ...
- OpenShift 4 - Pod的亲和性/反亲和性
<OpenShift 4.x HOL教程汇总> 文章目录 Pod的亲和性/反亲和性 方法1:直接指定Pod运行Node 方法2:通过设置Pod的nodeselector实现 方法3:通过设 ...
- k8s中亲和性与反亲和性
k8s中亲和性与反亲和性 Kubernetes的默认调度器以预选.优选.选定机制完成将每个新的Pod资源绑定至为其选出的目标节点上,不过,它只是Pod对象的默认调度器,默认情况下调度器考虑的是资源足够 ...
- Kubernetes 亲和性与反亲和性
文章目录 一.前言 1. 概述 2. 亲和性和反亲和性的类型 3.硬亲和与软亲和 4.亲和性支持的运算符 二.nodeAffinity(节点亲和) 1. 测试环境准备 2. 节点硬亲和 3. 节点软亲 ...
- 【云原生 | 从零开始学Kubernetes】十、k8sPod节点亲和性和反亲和性
该篇文章已经被专栏<从零开始学k8s>收录 Pod节点亲和性和常见的状态 Pod 节点亲和性 pod 节点反亲和性 写在最后 Pod 节点亲和性 pod 自身的亲和性调度有两种表示形式 p ...
- k8s学习(二十一) 亲和性调度
亲和性调度可以分成软策略和硬策略两种方式: 软策略就是如果你没有满足调度要求的节点的话,pod 就会忽略这条规则,继续完成调度过程,说白了就是满足条件最好了,没有的话也无所谓了的策略 硬策略就比较强硬 ...
- 【项目实战23】k8s(9)—k8s调度(节点亲和性,Taint污点,pod容忍性)
k8s调度 一.k8s调度背景介绍 二.nodeName方式调度 三.nodeSelector方式调度 (1).使用方式 (2).节点亲和性 四.Taints污点 (1).介绍 (2).使用 五.to ...
- K8S调度之pod亲和性
目录 Pod Affinity Pod亲和性调度 pod互斥性调度 Pod Affinity 通过<K8S调度之节点亲和性>,我们知道怎么在调度的时候让pod灵活的选择node,但有些时候 ...
- Kubernetes调度之亲和性和反亲和性
背景 Kubernetes中的调度策略可以大致分为两种,一种是全局的调度策略,要在启动调度器时配置,包括kubernetes调度器自带的各种predicates和priorities算法:另一种是运行 ...
最新文章
- 【组队学习】孙健坤:基于Python的会员数据化运营
- mysql内置乐观锁吗_mysql 乐观锁详解
- php flock 超时,php flock失效问题
- Demo学习: CalendarPanel
- 工作中常用到的sql命令!!!
- 深入浅析HTML5中的article和section的区别
- 台达b3伺服modbus通讯_【数控系统】台达伺服压机控制灵活 精准压合满足各种工序需求...
- QT消息,事件,槽的典型用法
- bzoj2756: [SCOI2012]奇怪的游戏
- webapi 给自己挖的坑
- Linux 系统批量安装字体的方法
- renpy-视觉小说转换器-编程零基础写视觉小说
- 聊聊那些知识管理软件
- 计算机备注用if函数怎么算,Excel中IF函数使用操作的设置技巧
- 用golang从企业微信里获取打卡记录的方法
- 【论文笔记--FORCE】Progressive Skeletonization: Trimming more fat from a networkat initialization
- 基于mini2440嵌入式linux上整合一套Domoticz智能家居系统(十)使用domoticz+mosquitto+Android客户端实现控制STM32板上的LED(一)
- jQuery轮播图(详细注释)
- 主引导扇区(MBR),分区表(DPT)及活动分区(DBR)
- E18-D80NK拆解