Kubernetes(K8S) 入门进阶实战完整教程-05k8s的Pod详解-03调度
概述
在默认情况下,一个Pod在哪个Node节点上运行,是由Scheduler组件采用相应的算法计算出来的,这个过程是不受人工控制的。但是在实际使用中,这并不满足需求,因为很多情况下,我们想控制某些Pod到达某些节点上,那么应该怎么做?这就要求了解kubernetes对Pod的调度规则,kubernetes提供了四大类调度方式。
- 自动调度:运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
- 定向调度:NodeName, NodeSelector
- 亲和性调度:NodeAffinity, PodAffinity, PodAntiAffinity
- 污点(容忍)调度:Taints, Toleration
定向调度
- 概述
定向调度,指的是利用在Pod上声明的nodeName或nodeSelector,以此将Pod调度到期望的Node节点上。注意,这里的调度是强制的,这就意味着即使要调度的目标Node不存在,也会向上面进行调度,只不过Pod运行失败而已。 - nodeName
● nodeName用于强制约束将Pod调度到指定的name的Node节点上。这种方式,其实是直接跳过Scheduler的调度逻辑,直接将Pod调度到指定名称的节点。
● 创建一个pod-nodename.yaml文件,内容如下:
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
labels:
user: mayanan
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nodeName: node1 # 指定将pod调度到node1节点上
创建Pod
kubectl create -f pod-nodename.yaml
3. nodeSelector
● nodeSelector用于将Pod调度到添加了指定标签的Node节点上,它是通过kubernetes的label-selector机制实现的,换言之,在Pod创建之前,会由Scheduler使用MatchNodeSelector调度策略进行label匹配,找出目标node,然后将Pod调度到目标节点,该匹配规则是强制约束。
● 首先给node节点添加标签:
kubectl label node node2 version=v2
创建pod-podselector.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeSelector:
version: v2 # 指定调度到具有version=v2标签的节点上
创建pod,查看pod所在节点
kubectl create -f pod-nodeselector.yaml
kubectl get pod pod-nodeselector -n dev -o wide
亲和性调度概述
- 虽然定向调度的两种方式,使用起来非常方便,但是也有一定的问题,那就是如果没有满足条件的Node,那么Pod将不会被运行,即使在集群中还有可用的Node列表也不行,这就限制了它的使用场景。
- 基于上面的问题,kubernetes还提供了一种亲和性调度(Affinity)。它在nodeSelector的基础之上进行了扩展,可以通过配置的形式,实现优先选择满足条件的Node进行调度,如果没有,也可以调度到不满足条件的节点上,使得调度更加灵活。
- Affinity主要分为三类:
- nodeAffinity(node亲和性): 以Node为目标,解决Pod可以调度到哪些Node的问题;
- podAffinity(pod亲和性): 以Pod为目标,解决Pod可以和那些已存在的Pod部署在同一拓扑域中的问题;
- podAntiAffinity(pod反亲和性): 以Pod为目标,解决Pod不能和那些已经存在的Pod部署在同一拓扑域中的问题。
- 关于亲和性和反亲和性使用场景的说明:
- 亲和性:如果两个应用频繁交互,那么就有必要利用亲和性将两个应用尽可能的靠近,这样可以减少因网络通信带来的性能损耗
- 反亲和性:当应用采用多副本部署的时候,那么就有必要利用反亲和性将各个应用示例打散分不到各个Node节点上,这样可以提高服务的高可用性。
亲和性调度-nodeAffinity
- 查看一下nodeAffinity配置向
kubectl explain pod.spec.affinity.nodeAffinity
requiredDuringSchedulingIgnoredDuringExecution Node节点必须满足指定的所有规则才可以,相当于硬限制
nodeSelectorTerms 节点选择列表
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
preferredDuringSchedulingIgnoredDuringExecution 优先调度到满足指定的规则的Node,相当于软限制 (倾向)
preference 一个节点选择器项,与相应的权重相关联
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
weight 倾向权重,在范围1-100。
- 关系符的使用说明
- matchExpressions:
- key: nodeenv # 匹配存在标签的key为nodeenv的节点
operator: Exists
- key: nodeenv # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点
operator: In
values: ["xxx","yyy"]
- key: nodeenv # 匹配标签的key为nodeenv,且value大于"xxx"的节点
operator: Gt
values: "xxx"
- 下面演示硬限制:requiredDuringSchedulingIgnoredDuringExecution:
创建文件:pod-nodeaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性配置
nodeAffinity: # node亲和性配置
requiredDuringSchedulingIgnoredDuringExecution: # node节点必须满足指定的所有规则才可以,相当于硬规则,类似于定向调度
nodeSelectorTerms: # 节点选择列表
- matchExpressions:
- key: name # 匹配存在的标签的key为name的节点,并且values是node1的节点
operator: In
values:
- "xxx"
- "yyy"
# - "node1" # 注意,如果添加上了node1, 因为有这个节点对应的标签,所以Pod就会成功调度到node1节点上去。
创建Pod,因为节点中key为name,值为xxx或yyy的节点并没有,所以Pod启动失败
kubectl create -f pod-nodeaffinity-required.yaml
4. 下面演示软限制:preferredDuringSchedulingIgnoredDuringExecution
创建文件pod-nodeaffinity-preferred.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
nodeAffinity: # 设置node亲和性
preferredDuringSchedulingIgnoredDuringExecution: # 软限制
- preference:
matchExpressions: # 匹配节点标签name在xxx或yyy(当前环境没有)
- key: name
operator: In
values: ["xxx", "yyy"]
weight: 1
创建pod,当前标签xxx或yyy没有匹配到任意节点,但是因为是软限制,还是会把该Pod调度到一个节点上去
kubectl create -f pod-nodeaffinity-prefered.yaml
5. nodeAffinity注意事项
如果同时定义了nodeSelector和nodeAffinity,那么必须两个条件都满足,Pod才能运行在指定的Node上。
如果nodeAffinity指定了多个nodeSelectorTerms,那么只需要其中一个能够匹配成功即可。
如果一个nodeSelectorTerms中有多个matchExpressions,则一个节点必须满足所有的才能匹配成功。
如果一个Pod所在的Node在Pod运行期间其标签发生了改变,不再符合该Pod的nodeAffinity的要求,则系统将忽略此变化。
亲和性调度-podAffinity
- podAffinity主要实现以运行的Pod为参照,实现让新创建的Pod和参照的Pod在一个区域的功能。
PodAffinity的可选配置项:
pod.spec.affinity.podAffinity
requiredDuringSchedulingIgnoredDuringExecution 硬限制
namespaces 指定参照pod的namespace
topologyKey 指定调度作用域
labelSelector 标签选择器
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持In, NotIn, Exists, DoesNotExist.
matchLabels 指多个matchExpressions映射的内容
preferredDuringSchedulingIgnoredDuringExecution 软限制
podAffinityTerm 选项
namespaces
topologyKey
labelSelector
matchExpressions
key 键
values 值
operator
matchLabels
weight 倾向权重,在范围1-100
- topologyKey用于指定调度的作用域,例如:
如果指定为kubernetes.io/hostname,那就是以Node节点为区分范围。
如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分。 - 首先创建一个参照Pod
创建pod-podaffinity-target.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-target
namespace: dev
labels:
podenv: pro # Pod的标签
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: node1
创建Pod kubectl create -f pod-podaffinity-target.yaml
4. 演示硬限制:requiredDuringSchedulingIgnoredDuringExecution
创建pod-podaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
podAffinity: # 设置pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- namespaces: ["dev"]
topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: podeenv
operator: In
values: ["xxx", "pro"] # 根据pod的标签去选择对应的节点
上面配置表达的意思是:新pod必须要与拥有标签podeenv=xxx或podenv=pro的pod在同一node上。
亲和性调度-podAntiAffinity
- podAntiAffinity主要实现以运行的Pod为参照,让新创建的Pod和参照的Pod不在一个区域的功能。
其配置方式和podAffinity一样,此处不做详细解释。
使用上个案例中的目标Pod: - 创建pod-podantiaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podantiaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
podAntiAffinity: # 设置Pod反亲和性
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: podenv
operator: In
values: ["xxx", "pro"]
topologyKey: kubernetes.io/hostname
创建pod,我们发现Pod已经被部署到了node2节点上,因为node1上已经有一个pod包含标签podenv=pro了。
kubectl create -f pod-podantiaffinity-required.yaml
调度-污点(Taints)
- 前面的调度方式都是站在Pod的角度上,通过在Pod上添加属性,来确定Pod是否要调度到指定的Node上,其实我们也可以站在Node的角度上,通过在Node上添加污点属性,来决定是否运行Pod调度过来。
- Node被设置了污点之后就和Pod之间存在了一种相斥的关系,进而拒绝Pod调度进来,甚至可以将已经存在的Pod驱逐出去。
- 污点的格式为:key=value:effect,key和value是污点的标签,effect描述污点的作用,支持如下三个选项:
- PreferNoSchedule: kubernetes将尽量避免把pod调度到具有该污点的node上,除非没有其它节点可以调度
- NoSchedule: kubernetes将不会把pod调度到具有该污点的node上,但是不会影响当前node上已经存在的pod
- NoExecute: kubernetes将不会把pod调度到具有该污点的node上,同时会把node上已经存在的pod驱逐
- 语法
(1)设置污点
kubectl taint node node_name key=value:effect
(2)去除污点
kubectl taint node node_name key:effect-
(3)去除所有污点
kubectl taint node node_name key-
- 接下来演示下污点的效果
(1)准备节点node1(为了演示效果明显,暂时停止node2节点)
(2)为node1设置一个污点tag=heima:PreferNoSchedule,然后创建pod1
(3)修改node1节点的污点为:tag=heima:NoSchedule, 然后创建pod2
(3)修改node1节点的污点为:tag=heima:NoExecute, 然后创建pod3
# 为node1设置污点
kubectl taint node node1 tag=mayanan:PreferNoSchedule
# 创建pod1
kubectl run taint1 --image=nginx:1.17.1 -n dev
kubectl get pod -n dev -o wide
# 为node1设置污点,取消PreferNoSchedule, 设置NoSchedule
kubectl taint node node1 tag:PreferNoSchedule-
kubectl taint node node1 tag=mayanan:NoSchedule
# 创建pod2
kubectl run taint2 --image=nginx:1.17.1 -n dev
kubectl get pods -n dev -o wide
# 为node1设置污点,取消NoSchedule,设置NoExecute
kubectl taint node node1 tag:NoSchedule-
kubectl taint node node1 tag=mayanan:NoExecute
# 创建pod3
kubectl run taint3 --image=nginx:1.17.1 -n dev
kubectl get pods -n dev -o wide
注意:使用kubeadm创建的集群,默认就会给master节点上添加一个污点标记,所以pod就不会被调度到master节点上。
调度-容忍(Toleration)
- 上面介绍了污点的作用,我们可以在Node上添加污点用来拒绝Pod调度上来,但是如果就是想让一个Pod调度到一个有污点的Node上去,这时候应该怎么做?这就需要使用到容忍
简而言之,言而总之:污点就是拒绝,容忍就是忽略,Node通过污点拒绝Pod调度上去,Pod通过容忍忽略拒绝。 - 容忍的详细配置
kubectl explain pod.spec.tolerations
......
FIELDS:
key # 对应着要容忍的污点的键,空意味着匹配所有的键
value # 对应着要容忍的污点的值
operator # key-value的运算符,支持Equal和Exists(默认),Exists表示匹配键就可以,value可以省略
effect # 对应污点的effect,空意味着匹配所有影响
tolerationSeconds # 容忍时间, 当effect为NoExecute时生效,表示pod在Node上的停留时间
- 创建pod-toleration.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
tolerations: # 添加容忍
- key: tag # 要容忍的污点的key
operator: Equal # 操作符Equal或Exists
value: mayanan # 容忍的污点的value
effect: NoExecute # 添加容忍的规则,这里必须和标记的污点规则相同
创建pod,查看pod
kubectl create -f pod-toleration.yaml
kubectl get pod -n dev -o wide
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)