linux innode节点读取,linuxea:kubernetes 节点调度nodeSelector和nodeAffinity(40)

最新推荐文章于 2023-12-23 18:47:59 发布

多伦多豪

最新推荐文章于 2023-12-23 18:47:59 发布

阅读量206

点赞数

文章标签： linux innode节点读取

之前的scheduler，默认的default scheduler分三部实现调度过程，首先是预选，从所有节点当中选择基本符合选择条件的节点，而后在众多基本符合选择条件的节点中通过优选函数，对这些节点加以比较。并且从最高得分当中随机选择一个作为运行pod的节点。这就是scheduler负责的功用。

I. 高级调度机制

II. 节点调度

在某些调度参加中，可通过自己的预设来影响预选，优选的过程，从而使得调度的操作符合期望。如，一个pod应该固定的被运行在某个节点，就可以使用预设的方式来影响调度来达到预期的目的。

此类的影响方式有4种，这4种都可成为高级调度设置机制

1，节点选择器，如nodeSelector,nodename

2，节点亲和性调度，nodeAffinity

对于nodename来讲，我们期望将pod调度到某一个特定的节点之上，就可以在nodename属性当中直接给定node的名称，而后对应的这个pod，一定只能会调度到这个node节点之上。

如果有一类节点都符合调用的属性条件，并且我们期望调度到这类节点上，就可以使用nodeSelector，可以给一部分节点打上特有的标签，在pod配置当中使用nodeSelector匹配这些标签，节点能适配这些标签的就是pod可运行的节点之一。而这种方式也会非常大的缩小预选范围

1，nodeSelector

我们测试下nodeSelector的效果，如下图

在linuxea.node-3.com节点之上，添加标签zone=linuxea.zone

[root@linuxea schedule]# kubectl label nodes linuxea.node-3.com zone=linuxea.zone

node/linuxea.node-3.com labeled

[root@linuxea schedule]# kubectl get nodes --show-labels|grep zone

linuxea.node-3.com Ready 39d v1.11.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=linuxea.node-3.com,zone=linuxea.zone

而后绑定到linuxea.zone标签的节点之上

[root@linuxea schedule]# cat pods.yaml

apiVersion: v1

kind: Pod

metadata:

namespace: default

labels:

app: linuxea.com

spec:

containers:

- name: pods-1026

image: marksugar/nginx:1.14.a

ports:

- name: http

containerPort: 80

nodeSelector:

zone: linuxea.zone

[root@linuxea schedule]# kubectl apply -f pods.yaml

pod/linuxea-pods-1026 created

[root@linuxea schedule]# kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE

linuxea-pods-1026 1/1 Running 0 2h 172.16.5.12 linuxea.node-3.com

此时linuxea-pods-1026名称的pod就运行在node3之上。因为只有node3才有zone: linuxea.zone标签

如果nodeSelector定义的标签在节点内不存在就会挂起。nodeSelector是签约束，如果不满足条件，在预选时候就会停止。

此刻将nodeSelector的标签修改成zone: linuxea.zone.cn。zone: linuxea.zone.cn是不存在的。

nodeSelector:

zone: linuxea.zone.cn

那么标签zone: linuxea.zone.cn不存在在节点上，这个pod就会Pending。因为pod中nodeSelector的标签不存在。

[root@linuxea schedule]# kubectl apply -f pods.yaml

pod/linuxea-pods-1026 created

[root@linuxea schedule]# kubectl get pods

NAME READY STATUS RESTARTS AGE

linuxea-pods-1026 0/1 Pending 0 3s

将node1.linuxea.com打上zone: linuxea.zone.cn标签，就会将linuxea-pods-1026调度到node1上

[root@linuxea schedule]# kubectl label nodes linuxea.node-1.com zone=linuxea.zone.cn

node/linuxea.node-1.com labeled

[root@linuxea schedule]# kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE

linuxea-pods-1026 1/1 Running 0 46s 172.16.3.2 linuxea.node-1.com

2，nodeAffinity

在pod.spec.affinity中就有affinity，在affinity中nodeAffinity(节点亲和性)，podAffinity(pod亲和性)，podAntiAffinity(pod反亲和性)

在nodeAffinity中有两项如下：

requiredDuringSchedulingIgnoredDuringExecution

requiredDuringSchedulingIgnoredDuringExecution是硬亲和性，也就是说必须满足条件。与nodeSelector相似，如果不满足亲和定义的条件，就一定不会运行，那么就会pending状态

preferredDuringSchedulingIgnoredDuringExecution

preferredDuringSchedulingIgnoredDuringExecution倾向性。优先运行满足节点亲和性高的节点上。尽量满足条件，如果不能够尽量的满足条件，那也可以找其他节点运行。当然，能够运行在亲和性高，满足条件多的节点是最好不过了。

在preferredDuringSchedulingIgnoredDuringExecution下嵌套：

preference 倾向节点

weight 倾向权重

在requiredDuringSchedulingIgnoredDuringExecution下的nodeSelectorTerms定义对象列表，并且嵌套节点选择器Terms。在nodeSelectorTerms之下嵌套

matchExpressions：匹配表达式

matchFields：匹配字段

在matchFields下需要定义key，检查label key，操作符operator(等值或者不等值选择，以及集合的标签，如果使用exists，或者doesnotexist的时候values是不能有值的)，values只需要给定值即可

matchExpressions 定义表达式基于标签选择。

开始测试requiredDuringSchedulingIgnoredDuringExecution

其中定义affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions，定义key是zone，operator操作符是In，values是www.linuxea.com，而后在添加weight ，如上图

yaml

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: zone

operator: In

values:

- www.linuxea.com

如下：

[root@linuxea schedule]# cat pods_nodeAffinity.yaml

apiVersion: v1

kind: Pod

metadata:

namespace: default

labels:

app: linuxea.com

spec:

containers:

- name: pods-1026

image: marksugar/nginx:1.14.a

ports:

- name: http

containerPort: 80

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: zone

operator: In

values:

- www.linuxea.com

apply

[root@linuxea schedule]# kubectl apply -f pods_nodeAffinity.yaml

pod/linuxea-nodeaffinity created

此刻状态是Pending，因为目前并没有zone标签，且值是等值的www.linuxea.com的node

[root@linuxea schedule]# kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE

linuxea-nodeaffinity 0/1 Pending 0 9s

并且定义的是requiredDuringSchedulingIgnoredDuringExecution硬亲和性，在上述中，我们知道硬亲和性的话，如果不存在，就不会选中。所以被Pending

preferredDuringSchedulingIgnoredDuringExecution

那么这样以来就无法绑定了，我们尝试使用倾向性绑定，这和硬绑定requiredDuringSchedulingIgnoredDuringExecution不同，配置preference和weight即可，如下：

affinity:

nodeAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

- preference:

matchExpressions:

- key: zone

operator: In

values:

- www.linuxea.com

weight: 60

如下：

[root@linuxea schedule]# cat pods_nodeAffinity-2.yaml

apiVersion: v1

kind: Pod

metadata:

namespace: default

labels:

app: linuxea.com

spec:

containers:

- name: pods-1026

image: marksugar/nginx:1.14.a

ports:

- name: http

containerPort: 80

affinity:

nodeAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

- preference:

matchExpressions:

- key: zone

operator: In

values:

- www.linuxea.com

weight: 60

apply

[root@linuxea schedule]# kubectl apply -f pods_nodeAffinity-2.yaml

pod/linuxea-nodeaffinity created

而后调度到node2节点。

[root@linuxea schedule]# kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE

linuxea-nodeaffinity 1/1 Running 0 6s 172.16.4.9 linuxea.node-2.com

[root@linuxea schedule]# kubectl describe pods linuxea-nodeaffinity|tail -6

Type Reason Age From Message

---- ------ ---- ---- -------

Normal Scheduled 6m default-scheduler Successfully assigned default/linuxea-nodeaffinity to linuxea.node-2.com

Normal Pulled 6m kubelet, linuxea.node-2.com Container image "marksugar/nginx:1.14.a" already present on machine

Normal Created 6m kubelet, linuxea.node-2.com Created container

Normal Started 6m kubelet, linuxea.node-2.com Started container

但是我们知道，node2肯定是不符合硬性条件的。但是仅仅尽量满足而已。如果此时在其他节点打上一个符合的标签，如果使用preferred仍然会调度到符合条件的节点上。如果使用required则只会调度到符合的节点，而不会尽量满足调用，而是硬性满足，没有则pending。这就是两种节点亲和，前者硬性亲和，后者软亲和。

除非另有说明，否则本站上的内容根据以下许可进行许可: CC署名-非商业性使用-相同方式共享4.0国际许可协议4.0进行许可

本文作者：www.linuxea.com for Mark

文章链接：http://www.linuxea.com/2079.html (转载请注明本文出处和本章链接)

多伦多豪

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
linux innode节点读取,linuxea:kubernetes 节点调度nodeSelector和nodeAffinity(40)

之前的scheduler，默认的default scheduler分三部实现调度过程，首先是预选，从所有节点当中选择基本符合选择条件的节点，而后在众多基本符合选择条件的节点中通过优选函数，对这些节点加以比较。并且从最高得分当中随机选择一个作为运行pod的节点。这就是scheduler负责的功用。I. 高级调度机制II. 节点调度在某些调度参加中，可通过自己的预设来影响预选，优选的过程，从而使得...
复制链接

扫一扫