【云原生 · Kubernetes】Taint和Toleration(污点和容忍)

这篇具有很好参考价值的文章主要介绍了【云原生 · Kubernetes】Taint和Toleration(污点和容忍)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

个人名片:
因为云计算成为了监控工程师👨🏻‍💻
个人博客🏆:念舒_C.ying
CSDN主页✏️:念舒_C.ying

节点亲和性是pod的一种属性(优先选择或硬性要求),它使 pod 被优先分配到一类特定的节点上。而Taint则相反,它使节点能够排斥一类特定的 pod。

Taint(污点)和 toleration(容忍)相互配合,可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ,这表示对于那些不能容忍这些 taint 的 pod,是不会被该节点接受的。如果将 toleration 应用于 pod 上,则表示这些 pod 可以(但不要求)被调度到具有匹配 taint 的节点上。

概念

您可以使用命令 [kubectl taint] 给节点增加一个 taint。比如,

kubectl taint nodes node1 key=value:NoSchedule

给节点 node1 增加一个 taint,它的 key 是 key,value 是 value,effect 是 NoSchedule。这表示只有拥有和这个 taint 相匹配的 toleration 的 pod 才能够被分配到 node1 这个节点。

选择,你可以在 PodSpec 中定义 pod 的 toleration。下面提供的两个 toleration 例子均与上面例子中使用 kubectl taint 命令创建的 taint 相匹配,因此如果一个 pod 拥有其中的任何一个 toleration 都能够被分配到 node1

想删除刚才添加的 taint ,你可以运行:

kubectl taint nodes kube11 key:NoSchedule-
tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"
tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"

一个 toleration 和一个 taint 相“匹配”是指它们有一样的 key 和 effect ,并且:

  • 如果 operatorExists (此时 toleration 不能指定 value),或者
  • 如果 operatorEqual ,则它们的 value 应该相等

注意: 存在两种特殊情况:

  • 如果一个 toleration 的 key 为空且 operator 为 Exists ,表示这个 toleration 与任意的 key 、 value 和 effect 都匹配,即这个 toleration 能容忍任意 taint。
tolerations:
- operator: "Exists"
  • 如果一个 toleration 的 effect 为空,则 key 值与之相同的相匹配 taint 的 effect 可以是任意值。
tolerations:
- key: "key"
  operator: "Exists"

上述例子使用到的 effect 的一个值 NoSchedule,您也可以使用另外一个值 PreferNoSchedule。这是优化版本的 NoSchedule —— 系统会尽量避免将 pod 调度到存在其不能容忍 taint 的节点上,但这不是强制的。effect 的值还可以设置为 NoExecute

其中 [effect] 可取值: [ NoSchedule | PreferNoSchedule | NoExecute ]

  • NoSchedule: 一定不能被调度
  • PreferNoSchedule: 尽量不要调度,实在没有地方调度的情况下,才考虑可以调度过来
  • NoExecute: 不仅不会调度, 还会立即驱逐Node上已有的Pod

添加多个tainit(污点)

您可以给一个节点添加多个 taint ,也可以给一个 pod 添加多个 toleration。Kubernetes 处理多个 taint 和 toleration 的过程就像一个过滤器:从一个节点的所有 taint 开始遍历,过滤掉那些 pod 中存在与之相匹配的 toleration 的 taint。余下未被过滤的 taint 的 effect 值决定了 pod 是否会被分配到该节点,特别是以下情况:

  • 如果未被过滤的 taint 中存在一个以上 effect 值为 NoSchedule 的 taint,则 Kubernetes 不会将 pod 分配到该节点。
  • 如果未被过滤的 taint 中不存在 effect 值为 NoSchedule 的 taint,但是存在 effect 值为 PreferNoSchedule 的 taint,则 Kubernetes 会尝试将 pod 分配到该节点。
  • 如果未被过滤的 taint 中存在一个以上 effect 值为 NoExecute 的 taint,则 Kubernetes 不会将 pod 分配到该节点(如果 pod 还未在节点上运行),或者将 pod 从该节点驱逐(如果 pod 已经在节点上运行)。

例如,假设您给一个节点添加了如下的 taint

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:NoSchedule

然后存在一个 pod,它有两个 toleration

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

在这个例子中,上述 pod 不会被分配到上述节点,因为其没有 toleration 和第三个 taint 相匹配。但是如果在给节点添加 上述 taint 之前,该 pod 已经在上述节点运行,那么它还可以继续运行在该节点上,因为第三个 taint 是三个 taint 中唯一不能被这个 pod 容忍的。

通常情况下,如果给一个节点添加了一个 effect 值为 NoExecute 的 taint,则任何不能忍受这个 taint 的 pod 都会马上被驱逐,任何可以忍受这个 taint 的 pod 都不会被驱逐。但是,如果 pod 存在一个 effect 值为 NoExecute 的 toleration 指定了可选属性 tolerationSeconds 的值,则表示在给节点添加了上述 taint 之后,pod 还能继续在节点上运行的时间。例如,

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

这表示如果这个 pod 正在运行,然后一个匹配的 taint 被添加到其所在的节点,那么 pod 还将继续在节点上运行 3600 秒,然后被驱逐。如果在此之前上述 taint 被删除了,则 pod 不会被驱逐。

使用例子

通过 taint 和 toleration ,可以灵活地让 pod 避开某些节点或者将 pod 从某些节点驱逐。下面是几个使用例子:

  • 专用节点:如果您想将某些节点专门分配给特定的一组用户使用,您可以给这些节点添加一个 taint(即,
    kubectl taint nodes nodename dedicated=groupName:NoSchedule),然后给这组用户的 pod 添加一个相对应的 toleration(通过编写一个自定义的admission controller,很容易就能做到)。拥有上述 toleration 的 pod 就能够被分配到上述专用节点,同时也能够被分配到集群中的其它节点。如果您希望这些 pod 只能被分配到上述专用节点,那么您还需要给这些专用节点另外添加一个和上述 taint 类似的 label (例如:dedicated=groupName),同时 还要在上述 admission controller 中给 pod 增加节点亲和性要求上述 pod 只能被分配到添加了 dedicated=groupName 标签的节点上。

  • 配备了特殊硬件的节点:在部分节点配备了特殊硬件(比如 GPU)的集群中,我们希望不需要这类硬件的 pod 不要被分配到这些特殊节点,以便为后继需要这类硬件的 pod 保留资源。要达到这个目的,可以先给配备了特殊硬件的节点添加 taint(例如 kubectl taint nodes nodename special=true:NoSchedule or kubectl taint nodes nodename special=true:PreferNoSchedule),然后给使用了这类特殊硬件的 pod 添加一个相匹配的 toleration。和专用节点的例子类似,添加这个 toleration 的最简单的方法是使用自定义 admission controller。比如,我们推荐使用 Extended Resources 来表示特殊硬件,给配置了特殊硬件的节点添加 taint 时包含 extended resource 名称,然后运行一个 ExtendedResourceToleration admission controller。此时,因为节点已经被 taint 了,没有对应 toleration 的 Pod 会被调度到这些节点。但当你创建一个使用了 extended resource 的 Pod 时,ExtendedResourceToleration admission controller 会自动给 Pod 加上正确的 toleration ,这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。这样就能够确保这些配置了特殊硬件的节点专门用于运行 需要使用这些硬件的 Pod,并且您无需手动给这些 Pod 添加 toleration。

  • 基于 taint 的驱逐 (alpha 特性): 这是在每个 pod 中配置的在节点出现问题时的驱逐行为,接下来的章节会描述这个特性

基于 taint 的驱逐

前面我们提到过 taint 的 effect 值 NoExecute ,它会影响已经在节点上运行的 pod

  • 如果 pod 不能忍受effect 值为 NoExecute 的 taint,那么 pod 将马上被驱逐
  • 如果 pod 能够忍受effect 值为 NoExecute 的 taint,但是在 toleration 定义中没有指定 tolerationSeconds,则 pod 还会一直在这个节点上运行。
  • 如果 pod 能够忍受effect 值为 NoExecute 的 taint,而且指定了 tolerationSeconds,则 pod 还能在这个节点上继续运行这个指定的时间长度。

此外,Kubernetes 1.6 已经支持(alpha阶段)节点问题的表示。换句话说,当某种条件为真时,node controller会自动给节点添加一个 taint。当前内置的 taint 包括:

  • node.kubernetes.io/not-ready:节点未准备好。这相当于节点状态 Ready 的值为 “False”。
  • node.kubernetes.io/unreachable:node controller 访问不到节点. 这相当于节点状态 Ready 的值为 “Unknown”。
  • node.kubernetes.io/out-of-disk:节点磁盘耗尽。
  • node.kubernetes.io/memory-pressure:节点存在内存压力。
  • node.kubernetes.io/disk-pressure:节点存在磁盘压力。
  • node.kubernetes.io/network-unavailable:节点网络不可用。
  • node.kubernetes.io/unschedulable: 节点不可调度。
  • node.cloudprovider.kubernetes.io/uninitialized:如果 kubelet 启动时指定了一个 “外部” cloud provider,它将给当前节点添加一个 taint 将其标志为不可用。在 cloud-controller-manager 的一个 controller 初始化这个节点后,kubelet 将删除这个 taint。

在启用了 TaintBasedEvictions 这个 alpha 功能特性后(在 Kubernetes controller manager 的 --feature-gates 参数中包含TaintBasedEvictions=true 开启这个功能特性,例如:--feature-gates=FooBar=true,TaintBasedEvictions=true),NodeController (或 kubelet)会自动给节点添加这类 taint,上述基于节点状态 Ready 对 pod 进行驱逐的逻辑会被禁用。

注意:为了保证由于节点问题引起的 pod 驱逐rate limiting行为正常,系统实际上会以 rate-limited 的方式添加 taint。在像 master 和 node 通讯中断等场景下,这避免了 pod 被大量驱逐。

使用这个 alpha 功能特性,结合 tolerationSeconds ,pod 就可以指定当节点出现一个或全部上述问题时还将在这个节点上运行多长的时间。

比如,一个使用了很多本地状态的应用程序在网络断开时,仍然希望停留在当前节点上运行一段较长的时间,愿意等待网络恢复以避免被驱逐。在这种情况下,pod 的 toleration 可能是下面这样的:

tolerations:
- key: "node.alpha.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

注意,Kubernetes 会自动给 pod 添加一个 key 为 node.kubernetes.io/not-ready 的 toleration 并配置 tolerationSeconds=300,除非用户提供的 pod 配置中已经已存在了 key 为 node.kubernetes.io/not-ready 的 toleration。同样,Kubernetes 会给 pod 添加一个 key 为 node.kubernetes.io/unreachable 的 toleration 并配置 tolerationSeconds=300,除非用户提供的 pod 配置中已经已存在了 key 为 node.kubernetes.io/unreachable 的 toleration。

这种自动添加 toleration 机制保证了在其中一种问题被检测到时 pod 默认能够继续停留在当前节点运行 5 分钟。这两个默认 toleration 是由 DefaultTolerationSeconds
admission controller添加的。

DaemonSet 中的 pod 被创建时,针对以下 taint 自动添加的 NoExecute 的 toleration 将不会指定 tolerationSeconds

  • node.alpha.kubernetes.io/unreachable
  • node.kubernetes.io/not-ready

这保证了出现上述问题时 DaemonSet 中的 pod 永远不会被驱逐,这和 TaintBasedEvictions 这个特性被禁用后的行为是一样的。

基于节点状态添加 taint

1.8 版本引入了一个 alpha 特性,让 node controller 根据节点的状态创建 taint。当开启了这个特性时(通过给 scheduler 的 --feature-gates 添加 TaintNodesByCondition=true 参数,例如:--feature-gates=FooBar=true,TaintNodesByCondition=true),scheduler不会去检查节点的状态,而是检查节点的 taint。这确保了节点的状态不影响应该调度哪些 Pod 到节点上。用户可以通过给 Pod 添加 toleration 来选择忽略节点的一些问题(节点状态的形式表示)。

从 Kubernetes 1.8 开始,DaemonSet controller 会自动添加如下 NoSchedule toleration,以防止 DaemonSet 中断。

  • node.kubernetes.io/memory-pressure
  • node.kubernetes.io/disk-pressure
  • node.kubernetes.io/out-of-disk (只适合 critical pod)
  • node.kubernetes.io/unschedulable (1.10 或更高版本)
  • node.kubernetes.io/network-unavailable (只适合 host network)

添加上述 toleration 确保了向后兼容,您也可以选择自由的向 DaemonSet 添加 toleration。

期待下次的分享,别忘了三连支持博主呀~
我是 念舒_C.ying ,期待你的关注~💪💪💪文章来源地址https://www.toymoban.com/news/detail-404010.html

到了这里,关于【云原生 · Kubernetes】Taint和Toleration(污点和容忍)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Kubernetes 污点、容忍策略、优先级与抢占、Pod安全

    污点使结点与pod产生排斥与标签相反 污点策略是通过嵌入合在键值对上的污点标签进行声明 污点标签必须绑定在键值对上,格式为:key=value:[污点标签] taint翻译就是污点的意思 查看污点标签         kubectl describe nodes [结点名] 设置污点标签         kubectl taint node [结点名字

    2024年02月05日
    浏览(44)
  • 学习笔记十八:污点、容忍度

    给了节点选则的主动权,我们给节点打一个污点,不容忍的pod就运行不上来,污点就是定义在节点上的键值属性数据,可以定决定拒绝那些pod; taints是键值数据,用在节点上,定义污点; tolerations是键值数据,用在pod上,定义容忍度,能容忍哪些污点 pod亲和性是pod属性;但

    2024年02月12日
    浏览(31)
  • k8s 污点和容忍

    在 Kubernetes 中,节点亲和性 NodeAffinity 是 Pod 上定义的一种属性,能够使 Pod 按我们的要求调度到某个节点上,而 Taints(污点) 则恰恰相反,它是 Node 上的一个属性,可以让 Pod 不能调度到带污点的节点上,甚至会对带污点节点上已有的 Pod 进行驱逐。当然,对应的 Kubernetes 可以

    2023年04月08日
    浏览(30)
  • k8s概念-污点与容忍

    k8s 集群中可能管理着非常庞大的服务器,这些服务器可能是各种各样不同类型的,比如机房、地理位置、配置等,有些是计算型节点,有些是存储型节点,此时我们希望能更好的将 pod 调度到与之需求更匹配的节点上。 此时就需要用到污点(Taint)和容忍(Toleration),这些配

    2024年02月14日
    浏览(40)
  • K8s的亲和、反亲和、污点、容忍

    亲和性的原理其实很简单,主要利用label标签结合nodeSelector选择器来实现 从pod出发,可以分成亲和性和反亲和性,分别对应podAffinity和podAntiAffinity。 从node出发,也可以分成亲和性和反亲和性,分别对应nodeAffinity和nodeAntiAffinity。 从操作指令来讲,可以有ln、Notln、Exists、DoesN

    2024年04月27日
    浏览(35)
  • k8s--基础--20--污点和容忍度

    节点亲和性,是pod的一种属性(偏好或硬性要求),它使pod被吸引到一类特定的节点。 Taint(污点)与节点亲和性相反,它使节点能够排斥一类特定的pod。 Taint(污点)和toleration(容忍度)相互配合,可以用来避免pod被分配到不合适的节点上。 每个节点上都可以应用一个或多个taint,这

    2024年02月07日
    浏览(33)
  • k8s--基础--污点和容忍度 -- use

    节点亲和性,是pod的一种属性(偏好或硬性要求),它使pod被吸引到一类特定的节点。 Taint(污点)与节点亲和性相反,它使节点能够排斥一类特定的pod。 Taint(污点)和toleration(容忍度)相互配合,可以用来避免pod被分配到不合适的节点上。 每个节点上都可以应用一个或多个taint,这

    2024年02月11日
    浏览(32)
  • 【k8s】pod调度——亲和,反亲和,污点,容忍

    官方网址:https://kubernetes.io/zh/docs/concepts/scheduling-eviction/assign-pod-node/ pod.spec.nodeAffinity ●preferredDuringSchedulingIgnoredDuringExecution:软策略  p开头 ●requiredDuringSchedulingIgnoredDuringExecution:硬策略  r开头 pod.spec.affinity.podAffinity/podAntiAffinity ●preferredDuringSchedulingIgnoredDuringExecution:软策

    2024年02月05日
    浏览(41)
  • K8S之运用污点、容忍度设置Pod的调度约束

    taints 是键值数据, 用在节点上 ,定义污点; tolerations 是键值数据, 用在pod上 ,定义容忍度,能容忍哪些污点。 污点 是定义在k8s集群的节点上的键值属性数据,可以决定拒绝那些pod。 给了Node选则的主动权,给Node打个污点, 不容忍 的Pod就调度不上来。 现象:刚部署好的

    2024年02月19日
    浏览(35)
  • K8s Pod亲和性、污点、容忍度、生命周期与健康探测详解(下)

    🐇明明跟你说过:个人主页 🏅个人专栏:《Kubernetes航线图:从船长到K8s掌舵者》 🏅 🔖行路有良友,便是天堂🔖 目录 五、健康探测 1、健康探测的概念 2、Pod启动探测(Startup Probe) 3、Pod存活探测(Liveness Probe) 4、Pod就绪探测(Readiness Probe) 5、Pod健康探测在故障转移与

    2024年04月08日
    浏览(48)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包