K8S-污点与污点容忍

K8S-污点与污点容忍,第1张

Taints(污点):避免Pod调度到特定的Node上

Tolerations(污点容忍): 允许Pod调度到持有Taints的Node上

应用场景:

• 专用节点:根据业务线将Node分组管理,希望在默认情况下不调度该节点,只有配置了污点容忍才允许分配

• 配备特殊硬件:部分Node配有SSD硬盘,GPU,希望在默认情况下不调度该节点,只有配置了污点容忍才允许分配

• 基于Taint的驱逐

给node节点添加污点

其中key=value 是设定一个污点标签

其中[effect] 可取值:

• NoSchedule :一定不能被调度

• PreferNoSchedule:尽量不要调度,非必须配置容忍

• NoExecute:不仅不会调度,还会驱逐Node上已有的Pod

在pod.yaml中添加配置(spec下级,和containers段同级)

上述结果说明,污点配置成功,node1和node2都被打上了污点,当前已无合适的node可分配了。

再次创建pod,发现成功分配到了。验证Tolerations

污点是K8s高级调度的特性,用于限制哪些Pod可以被调度到某一个节点。在普通节点横向时我们可以使用污点容忍度创建恶意pod来对主节点进行横向控制。

kube-scheduler 是 Kubernetes 集群的默认调度器,并且是集群控制面(master)的一部分。对每一个新创建的Pod或者是未被调度的Pod, kube-scheduler 会选择一个最优的Node去运行这个Pod。

然而, Pod 内的每一个容器对资源都有不同的需求,而且Pod本身也有不同的资源需求。因此,Pod在被调度到Node上之前,根据这些特定的资源调度需求,需要对集群中的Node进行一次过滤。

当创建pod时候,会首先把创建的命令请求提交给apiserver,通过一系列认证授权,apiserver把pod数据存储到etcd,创建deployment资源并初始化。然后再是scheduler通过进行list-watch机制进行监测,经过 调度算法 把pod调度到某个node节点上,最后信息更新到etcd,再后面就是kubelet接受信息到创建容器。

当前调度器选择适当的节点时,调度程序会检查每个节点是否有足够的资源满足 Pod 调度,比如查看CPU和内存限制是否满足:

通过资源限制调度程序可确保由于过多 Pod 竞争消耗节点所有可用资源,从而导致节点资源耗尽引起其他系统异常。

在创建pod的时候,节点选择器可以约束pod在特定节点上运行。

nodeSelector 也是节点选择约束的最简单推荐形式, nodeSelector 字段添加到 Pod 的规约中设置希望目标节点所具有的 节点标签 。 K8s 只会将 Pod 调度到拥有你所指定的每个标签的节点上。

例子, 比如多个节点需要调度时候,通过给1,2节点打上标签,创建pod时候使用节点选择器,那么pod会被按照节点选择器希望的目标在相应节点调度。

为节点打上标签:

kubectl label node nodename env_role=env

查看节点的标签:

kubectl get nodes nodename --show-labels

节点亲和性概念上类似于 nodeSelector , 它使可以根据节点上的标签来约束 Pod 可以调度到哪些节点上,这种方法比上面的 nodeSelector 更加灵活,它可以进行一些简单的逻辑组合了,不只是简单的相等匹配。

节点亲和性和节点选择器相比功能更强大,比如还是刚才的图,如果我使用节点选择器 env_role:dev1 的话是找不到相应的节点的,就没有办法调度,会一直是一个等待的状态:

但我如果使用节点亲和性,就算当前没有这个节点,我还是可以根据调度调度策略进行调度,不只是简单的相等匹配。

调度可以分成软策略( 软亲和性 )和硬策略( 硬亲和性 )两种方式:

如图可以看到软亲和性和硬亲和性的字段其实差不多,软亲和性多了一个 weight 字段,表权重:

如上亲和性还有一个字段是 operator 表匹配的逻辑 *** 作符,可以使用 descirbe 命令查看具体的调度情况是否满足我们的要求, K8s 提供的 *** 作符有下面的几种:

如果 nodeSelectorTerms 下面有多个选项的话,满足任何一个条件就可以了;如果 matchExpressions 有多个选项的话,则必须同时满足这些条件才能正常调度 POD。

容忍度( Toleration )是应用于 Pod 上的,允许(但并不要求)Pod 调度到带有与之匹配的污点的节点上。污点说白了就是不做普通的调度。

对于节点亲和性无论是软亲和性和硬亲和性,都是调度 POD 到预期节点上,而污点( Taints )恰好与之相反,如果一个节点标记为 Taints , 除非 POD 也被标识为可以容忍污点节点,否则该 Taints 节点不会被调度pod

查看污点情况:

kubectl describe node nodename | grep Taint

可以看到,默认污点也只有master有。

污点里的值有三种:

NoSchedule 就是字面意思,不会被调度, PreferNoSchedule 说白了是尽量不被调度, NoExecute 是不会调度并且还会驱逐 node 已有的 pod 。

创建一个pod:

如果不加污点,可以看到这个pod会随机调度到节点1或者节点2:

这时候把pod删除了,重新创建pod并且给node加上污点:

给节点打污点:

kubectl taint node nodename key=value:NoSchedule

重新创建pod并且deployment多个:

可以发现全部被调度在节点2上,节点1的污点 NoSchedule 起了作用。

删除污点:

容忍度 tolerations 是定义在 Pod 对象上的键值型属性数据,用于配置其可容忍的节点污点,而且调度器仅能将 Pod 对象调度至其能够容忍该节点污点的节点之上。

污点定义在节点的 node Spec 中,而容忍度则定义在 Pod 的 podSpec 中,它们都是键值型数据。

在 Pod 对象上定义容忍度时,它支持两种 *** 作符:一种是等值比较 Equal ,表示容忍度与污点必须在 key 、 value 和 effect 三者之上完全匹配;另一种是存在性判断 Exists ,表示二者的 key 和 effect 必须完全匹配,而容忍度中的 value 字段要使用空值。

这里的key和value对应的值都是你自己设置的key和value:

说白了就是:

而污点容忍的作用举个例子,如果像上面污点一样设置了 NoSchedule 污点的节点,那么创建pod的时候是必不被调度到的,但是如果我使用污点容忍,那这个节点可以在设置 NoSchedule 污点的情况下可能又被调度,类似于亲和性那种作用。

污点和污点容忍度的作用也就是获取 主节点的shell ,因为像常见或者节点shell的流程是创建pod--》分配到正常node---》通过常规挂载目录拿到节点的shell,而默认主节点是不被调度的,所以只有使用污点容忍度,创建一个能够被调度到master节点的pod,然后通过挂载之类的手法来拿到主节点的shell。

通过创建一个具有 node-role.kubernetes.io/master:NoSchedule 的容忍度让Pod被Kubernetes Master所调度。

如上的Pod中将宿主机的根目录挂载到容器中(volumes与volumeMounts)即可逃逸至Kubernetes Master中接管集群。

查看节点,当前是在普通节点:

多次创建可以发现在master节点上了:

可以通过挂载 *** 作master节点母机shell:

污点 taints 是定义在node节点 上的键值型属性数据,用于让节点拒绝将Pod调度运行于其上,除非Pod有接纳节点污点的容忍度。容忍度 tolerations 是定义在Pod 上的键值属性数据,用于配置可容忍的污点,且调度器将Pod调度至其能容忍该节点污点的节点上或没有污点的节点上 。

对于nodeAffinity无论是硬策略(硬亲和)还是软策略(软亲和)方式,都是调度 pod 到预期节点上,而Taints恰好与之相反,如果一个节点标记为 Taints ,除非 pod 也被标识为可以容忍污点节点,否则该Taints 节点不会被调度 pod。

节点亲和性,是 pod 的一种属性(偏好或硬性要求),它使 pod 被吸引到一类特定的节点。Taint 则相反,它使节点 能够 排斥 一类特定的 pod Taint 和 toleration 相互配合,可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个taint ,这表示对于那些不能容忍这些 taint 的 pod,是不会被该节点接受的。如果将 toleration 应用于pod上,则表示这些 pod 可以(但不要求)被调度到具有匹配 taint 的节点上

污点定义于 nodes.spec.taints 属性。容忍度定义于 pods.spec.tolerations 属性。

使用 kubectl taint 命令可以给某个 Node 节点设置污点,Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系,可以让 Node 拒绝 Pod 的调度执行,甚至将 Node 已经存在的 Pod 驱逐出去 。

语法: key=value:effect

NoSchedule ,不能容忍,但仅影响调度过程,已调度上去的pod不受影响,仅对新增加的pod生效。

解释说明:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上 。 PreferNoSchedule ,柔性约束,节点现存Pod不受影响,如果实在是没有符合的节点,也可以调度上来。 解释说明:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上 。 NoExecute ,不能容忍,当污点变动时,Pod对象会被驱逐。

解释说明:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上,同时会将 Node 上已经存在的Pod 驱逐出去

本案例用于演示创建、删除污点及驱逐pod的过程。

污点语法

deploymentdemo控制器

产生10个副本

设置污点

全部资源文件清档

本案例用于演示创建、删除及驱逐pod的过程。

设置污点

deploymentdemo控制器

产生10个副本

查看部署情况

设置pod容忍度

完整控制器清单

部署控制器


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/bake/11882763.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-19
下一篇2023-05-19

发表评论

登录后才能评论

评论列表(0条)

    保存