Kubernetes :Taints(污点)和Tolerations(容忍)

简介: Kubernetes :Taints(污点)和Tolerations(容忍)

目录

Taint

基本用法

effect 的取值

NoExecute

Toleration

基本用法

Toleration 几个特殊情况:

key 为空并且 operator 等于 Exists

effect 为空

TolerationSeconds

多污点与多容忍配置

kubernetes 内置taint行为

Taints(污点)和Tolerations(容忍)示例

专用节点

具有特殊硬件的节点

基于 taint 的驱逐


  • Taint(污点)和 Toleration(容忍)可以作用于 node 和 pod 上,其目的是优化 pod 在集群间的调度,它们相互配合,可以用来避免 pod 被分配到不合适的节点上。
  • 不同于Kubernetes 亲和性调度---是描述 pod 的属性,来声明此 pod 希望调度到哪类 nodes
  • Taint(污点) 刚好相反,它是node 的一个属性,允许 node 主动排斥 pod 的调度。
  • 对应的 k8s 又给 pod 新增了配套属性 toleration(容忍) ,用于表示这些 pod 可以(但不强制要求)被调度到具有相应 taints 的 nodes 上。这两者经常一起搭配,来确保不将 pod 调度到不合适的 nodes


Taint

基本用法

  • 设置污点: kubectl taint node [node] key=value:[effect]其中 [effect] 可取值:[ NoSchedule | PreferNoSchedule | NoExecute ]:
  • NoSchedule :一定不能被调度。
  • PreferNoSchedule:尽量不要调度。
  • NoExecute:不仅不会调度,还会驱逐 Node 上已有的 Pod。
  • 去除污点:kubectl taint node [node] key:[effect]-


effect 的取值

下面对 effect 的值作下简单说明:

  • NoSchedule:如果一个 pod 没有声明容忍这个 Taint,则系统不会把该 Pod 调度到有这个 Taint 的 node 上
  • PreferNoSchedule:NoSchedule 的软限制版本,如果一个 Pod 没有声明容忍这个 Taint,则系统会尽量避免把这个 pod 调度到这一节点上去,但不是强制的。
  • NoExecute:定义 pod 的驱逐行为,以应对节点故障。


NoExecute

NoExecute 这个 Taint 效果对节点上正在运行的 pod 有以下影响:

  • 没有设置 Toleration 的 Pod 会被立刻驱逐
  • 配置了对应 Toleration 的 pod,如果没有为 tolerationSeconds 赋值,则会一直留在这一节点中
  • 配置了对应 Toleration 的 pod 且指定了 tolerationSeconds 值,则会在指定时间后驱逐

从 kubernetes1.6 版本开始引入了一个 alpha 版本的功能,即把节点故障标记为 Taint(目前只针对 node unreachable 及 node not ready,相应的 NodeCondition "Ready" 的值为 Unknown 和 False)。

激活 TaintBasedEvictions 功能后(在–feature-gates 参数中加入 TaintBasedEvictions=true),NodeController 会自动为 Node 设置 Taint,而状态为 "Ready" 的 Node 上之前设置过的普通驱逐逻辑将会被禁用。

注意,在节点故障情况下,为了保持现存的 pod 驱逐的限速设置,系统将会以限速的模式逐步给 node 设置 Taint,这就能防止在一些特定情况下(比如 master 暂时失联)造成的大量 pod 被驱逐的后果。这一功能兼容于 tolerationSeconds,允许 pod 定义节点故障时持续多久才被逐出。

NoExecute 效应由 TaintBasedEviction 控制, TaintBasedEviction 是 Beta 版功能,自 Kubernetes 1.13 起默认启用。


Toleration

基本用法

你可以在PodSpec中为容器设定容忍标签。以下两个容忍标签都与上面的 kubectl taint 创建的污点“匹配”, 因此具有任一容忍标签的Pod都可以将其调度到“ node1”上:

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"
tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"


再看下 PodSpec 配置 Tolerations,其中的 key、value、effect 与 Node Taint 设置需要保持一致,operator 支持两类:

  • operator 的值为 Exists,这时无需指定 value
  • operator 的值为 Equal 并且 value 相等(如果不指定 operator,则默认值为 Equal)


Toleration 几个特殊情况:

key 为空并且 operator 等于 Exists

  • 表示匹配了所有的 keys,values 和 effects。换句话说就是容忍了所有的 taints。
tolerations:
- operator: "Exists"


effect 为空

  • 则表示匹配所有的 effects(NoSchedule、PreferNoSchedule、NoExecute)
tolerations:
- key: "key"
  operator: "Exists"


TolerationSeconds

该值与 effect 为 NoExecute 配套使用。用来指定在 node 添加了 effect = NoExecute 的 taint 后,能容忍该 taint 的 pods 可停留在 node 上的时间。

例如:

tolerations: 
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

表示如果这个 pod 已经运行在 node 上并且该 node 添加了一个对应的 taint,那么这个 pod 将会在 node 上停留 3600 秒后才会被驱逐。但是如果 taint 在这个时间前被移除,那么这个 pod 也就不会被驱逐了。


多污点与多容忍配置

我们可以对 node 设置多个 taints,当然也可以在 pod 配置相同个数的 tolerations。影响调度和运行的具体行为,我们可以分为以下几类:

  • 如果至少有一个 effect == NoSchedule 的 taint 没有被 pod toleration,那么 pod 不会被调度到该节点上。
  • 如果所有 effect == NoSchedule 的 taints 都被 pod toleration,但是至少有一个 effect == PreferNoSchedule 没有被 pod toleration,那么 k8s 将努力尝试不把 pod 调度到该节点上。
  • 如果至少有一个 effect == NoExecute 的 taint 没有被 pod toleration,那么不仅这个 pod 不会被调度到该节点,甚至这个节点上已经运行但是也没有设置容忍该污点的 pods,都将被驱逐。


kubernetes 内置taint行为

kubernetes 1.6 版本,node controller 会跟进系统情况自动设置 node taint 属性。

内置 taint key 如下:

  • node.kubernetes.io/not-ready: 节点尚未就绪
  • node.kubernetes.io/unreachable: 节点无法被访问
  • node.kubernetes.io/unschedulable: 节点不可调度
  • node.kubernetes.io/out-of-disk: 节点磁盘不足
  • node.kubernetes.io/memory-pressure: 节点有内存压力
  • node.kubernetes.io/disk-pressure: 节点有磁盘压力
  • node.kubernetes.io/network-unavailable: 节点网络不可用
  • node.kubernetes.io/pid-pressure: 节点有 pid 压力
  • node.cloudprovider.kubernetes.io/uninitialized: 云节点未初始化
  • node.cloudprovider.kubernetes.io/shutdown: 云节点已下线

kubernetes 会通过 DefaultTolerationSeconds admission controller 为创建的 pod 添加两个默认的 toleration: node.kubernetes.io/not-readynode.kubernetes.io/unreachable并且设置 tolerationSeconds = 300。当然这个默认配置,用户可以自行覆盖。

这些自动添加的默认配置,确保 node 出现问题后,pod 可以继续在 node 上停留 5 分钟。

DefaultTolerationSeconds admission controller 设置的 tolerationSeconds 值,也可以由用户指定。具体参考:   https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go

还有一个默认行为,就是 DaemonSet。

所有 DaemonSet 创建的 pod 都会添加两个 toleration: node.alpha.kubernetes.io/unreachablenode.alpha.kubernetes.io/notReady。设置 effect = NoExecute,并且不指定 tolerationSeconds

目的是确保在 node 出现 unreachable 或 notReady 的问题时,DaemonSet Pods 永远不会被驱逐。


Taints(污点)和Tolerations(容忍)示例

专用节点

如果你希望将一组节点专用于特定的用户,那可以将这些节点设置 taints,

kubectl taint nodes nodename dedicated=groupName:NoSchedule

然后给这些应用的 pod 加入相应的 toleration,则带有合适 toleration 的 pod 就会被允许同使用其他节点一样使用有 taint 的节点。

如果你希望节点被专用并且确保服务仅使用这批节点,那么你还应该向这些 node 打上指定的标签 (dedicated=groupName),并且为对应的 pods 设置 NodeAffinity,以控制 pods 只能跑到这批节点上。


具有特殊硬件的节点

有部分带有特殊硬件的节点,比如 GPU、FPGA 等,要确保不将不需要专用硬件的 pods 调度到这些节点。也可以和 专有节点 一样的方式设置 taints:

kubectl taint nodes test special=true:NoSchedule  
kubectl taint nodes test special=true:PreferNoSchedule

然后在 pod 中利用对应的 toleration 来保障特定的 pod 能够使用特定的硬件。然后同样的,我们也可以使用标签或者其他的一些特征来判断这些 pod,将其调度到这些特定硬件的服务器上。

建议还可以通过 Extended ResourcesExtendedResourceToleration admission controller 来更方便的调度依赖特殊硬件的 pods,而不需要手动添加容器的 toleration


基于 taint 的驱逐

之前说到,在节点故障时,可以通过 TaintBasedEvictions 功能自动将节点设置 Taint,然后将 pod 驱逐。

但是在一些场景下,比如说网络故障造成的 master 与 node 失联,而这个 node 上运行了很多本地状态的应用即使网络故障,也仍然希望能够持续在该节点上运行,期望网络能够快速恢复,从而避免从这个 node 上被驱逐。Pod 的 Toleration 可以这样定义:

tolerations:  
- key: "node.alpha.kubernetes.io/unreachable"
  operator:"Exists" 
  effect: "NoExecute"  
  tolerationSeconds: 6000
对于 Node 未就绪状态,可以把 key 设置为 node.alpha.kubernetes.io/notReady
  • 如果没有为 pod 指定 node.alpha.kubernetes.io/noReady 的 Toleration,那么 Kubernetes 会自动为 pod 加入 tolerationSeconds=300 的 node.alpha.kubernetes.io/notReady 类型的 toleration。
  • 如果没有为 pod 指定 node.alpha.kubernetes.io/unreachable 的 Toleration,那么 Kubernetes 会自动为 pod 加入 tolerationSeconds=300 的 node.alpha.kubernetes.io/unreachable 类型的 toleration。

这些系统自动设置的 toleration 用于在 node 发现问题时,能够为 pod 确保驱逐前再运行 5min。这两个默认的 toleration 由 Admission Controller "DefaultTolerationSeconds" 自动加入。


参考链接:https://kubernetes.io/zh/docs/concepts/configuration/taint-and-toleration/



相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
运维 Kubernetes 调度
【kubernetes】关于k8s集群的污点、容忍、驱逐以及k8s集群故障排查思路
【kubernetes】关于k8s集群的污点、容忍、驱逐以及k8s集群故障排查思路
2030 156
|
Kubernetes 调度 Perl
在K8S中,说下Pod污点与容忍的理解?
在K8S中,说下Pod污点与容忍的理解?
|
Kubernetes 调度 容器
在K8S中,内置的污点主要有哪些?
在K8S中,内置的污点主要有哪些?
|
Kubernetes 调度 开发者
在K8S中,如何理解Pod污点与容忍?
在K8S中,如何理解Pod污点与容忍?
|
Kubernetes 应用服务中间件 调度
k8s-高级调度-污点容忍、亲和性调度
k8s-高级调度-污点容忍、亲和性调度
410 1
|
存储 Kubernetes 调度
K8s Pod亲和性、污点、容忍度、生命周期与健康探测详解(下)
本文全面探讨了Kubernetes集群中Pod的四种关键机制——Pod亲和性、污点(Taints)、容忍度(Tolerations)、生命周期以及健康探测,为读者提供了深入理解并有效应用这些特性的指南。
|
Kubernetes Cloud Native 调度
云原生|kubernetes |一文带你搞懂pod调度策略,驱逐策略,污点、容忍调度
云原生|kubernetes |一文带你搞懂pod调度策略,驱逐策略,污点、容忍调度
1267 0
|
Kubernetes Cloud Native 调度
k8s学习-污点和容忍(概念、模版、创建、删除)
k8s学习-污点和容忍(概念、模版、创建、删除)
434 0
|
8月前
|
人工智能 算法 调度
阿里云ACK托管集群Pro版共享GPU调度操作指南
本文介绍在阿里云ACK托管集群Pro版中,如何通过共享GPU调度实现显存与算力的精细化分配,涵盖前提条件、使用限制、节点池配置及任务部署全流程,提升GPU资源利用率,适用于AI训练与推理场景。
655 1
|
8月前
|
弹性计算 监控 调度
ACK One 注册集群云端节点池升级:IDC 集群一键接入云端 GPU 算力,接入效率提升 80%
ACK One注册集群节点池实现“一键接入”,免去手动编写脚本与GPU驱动安装,支持自动扩缩容与多场景调度,大幅提升K8s集群管理效率。
483 89

推荐镜像

更多