kubernetes调度之污点(taint)和容忍(toleration)

系列目录

节点亲和性(affinity),是节点的一种属性,让符合条件的pod亲附于它(倾向于或者硬性要求).污点是一种相反的行为,它会使pod抗拒此节点(即pod调度的时候不被调度到此节点)

污点和容易结合在一起以确保pod不会被调度到不适合的节点上.当一个或者多个污点添加到某个节点上,则意味着此节点不会接受任何不容忍这些污点的pod.Tolerations作用于pod上,允许(但不是必须)pod被调度到有符合的污点(taint)的节点上

概念

可以使用kubectl taint为一个节点(node)添加污点(taint),例如:

kubectl taint nodes node1 key=value:NoSchedule

这样就把键为key,值为value,效果为NoSchedule的污点添加到了节点node1上.这样除非pod有符合的容忍(toleration),否则不会被调度到此节点上

可以通过以下命令删除刚添加的taint

kubectl taint nodes node1 key:NoSchedule-

你可以在创建pod的yml里指定一个关于toleration的PodSpec,以下两个容忍都会匹配前面创建的taint,因此它们中的任意一个创建的pod都会被调度到节点node1上

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

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

只有pod的key和effect都和某一个污点的key与effect匹配,才被认为是匹配,并且要符合以下情形:

• operator是Exists(这种情况下value不应当指定)
• operator是 Equal 并且value相同

如果operator没有指定,则默认是Equal

以下两种情况为特殊情况:

1) 如果key是空(是指key没有指定,而不是指key为空字符串),operator为Exists则匹配所有的key,value和effect,也即匹配任何node,

tolerations:
- operator: "Exists"

2) 空的effect匹配所有effect

tolerations:
- key: "key"
  operator: "Exists"

以上会匹配所有key为key的所有taint节点

前面的示例中使用了NoSchedule类型的effect.此外,也可以使用PreferNoSchedule类型的effect,这是一个优先选择或者软性版本的NoSchedule,调度系统会尽量避免调度不容忍这种污点的pod到带有此污点的节点上,但是并不是硬性要求.第三种effect类型:NoExecute会在晚些时候讲到

你可以为一个节点(node)添加多个污点,也可以为一个pod添加多个容忍(toleration).kubernetes处理多个污点(taint)或者多个容忍(toleration)类似于过滤器:起初包含所有污点,然后忽略掉pod匹配的污点,剩下不可被忽略的污点决定此节点对pod的效果,特别地:

1) 如果至少有一个不可忽略的NoSchedule类型的效果(effect),kubernetes不会调度pod到此节点上来.

2) 如果没有不可忽略的NoSchedule类型的效果(effect),但是至少有一个PreferNoSchedule类型的效果,则kubernetes会尝试调度pod到此节点上

3) 如果至少有一个NoExecute类型的效果(effect),则此pod会被驱离此节点(当然,前提此pod在此节点上),并且如果pod不在此节点上,也不会被调度到此节点上

所谓驱离是指pod被从此节点上移除,调度到其它节点上

示例,假如你有一个以下类型的节点

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

和以下类型的pod

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

这种情况下,pod不会被调度到node1上,因为没有容忍(toleration)来匹配第三个taint.但是如果它运行在此节点上,它仍然可以继续运行在此节点上,因为它仅仅不匹配第三个taint.(而第三个taint的效果是NoSchedule,指示不要被调度到此节点)

通常情况下,一个效果类型为NoExecute的taint被添加到一个节点上后,所有不容忍此taint的pod会被马上驱离,容忍的永远不会被驱离.但是效果类型NoExecute可以指定一个tolerationSeconds字段来指示当NoExecute效果类型的污点被添加到节点以后,pod仍然可以继续在在指定时间内留存在此节点上.

例如:

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

它意味着如果pod运行在一个可以容忍的节点上,则它可以继续运行3600秒,然后被驱离,在此段时间内如果污点被移除,则pod不会被驱离.

以上可以理解为有条件容忍,即便匹配也不能一直运行在此节点上,只能在符合条件的时段内运行在此节点上.

实例:

taint和toleration可以非常灵活地把指示pod不要调度到不合适的节点或者把已经存在的pod驱离节点,以下列举出一些用例:

• 专用节点 假如你想让某些节点供特定的用户专用,你可以为这些节点添加污点,例如:(kubectl taint nodes nodename dedicated=groupName:NoSchedule),然后给专用这些节点的pod添加容忍(toleration),容忍节点污点的pod被允许调度到节点上,当然也可以调度到集群中的其它节点上(没有taint的节点,有taint的必须容忍).如果你想要pod仅被调度到专用的节点,则需要添加标签(使用前面讲到过的亲和属性)

pod的亲和性是以pod为中心的,而节点的污点则是以节点为中心.想要使pod被调度到指定节点,需要亲和属性,想要节点排斥非专用pod,则需要使用taint,同时使用亲和性和污点可以保证专用节点被特定pod专用,特定pod仅使用专用节点

• 配有特殊硬件的节点 在一个集群中,有部分节点包含特殊硬件(例如特殊GPU),理想的情况是把让不需要特殊硬件的pod不被调度到这些节点上以便为可能需要特殊硬件的节点留存空间,这种情况下就可以用给指定节点添加污点(taint)的方法来实现效果.(例如kubectl taint nodes nodename special=true:NoSchedule or kubectl taint nodes nodename special=true:PreferNoSchedule),然后给需要使用特殊硬件的pod添加符合的容忍(toleration).
• 基于taint的驱离策略(测试功能),当节点出现问题时,把不容忍的pod驱离.

基于taint的驱离策略

前面我们提到过NoExecute效果类型的taint,它将对已经存在于此节点上的pod产生效果:

• 不容忍此taint的pod会被马上驱离
• 容忍此taint但是没有指定tolerationSeconds的pod将会永远运行在此节点
• 容忍此taint但是包含tolerationSeconds属性的节点将会在此节点上留存指定时间(虽然容忍,但是是有条件的,仅在一段时间内容忍)

第三点的言外之意即为即便容忍,但是超过容忍时间后仍然会被驱离

此外,kubernetes 1.6引入了对节点问题的展示.也就是说当满足了特定条件,节点控制器会自动为符合条件的节点添加taint,以下是一些内置的taint

• node.kubernetes.io/not-ready,节点还没有准备好,对应节点状态Ready值为false
• node.kubernetes.io/unreachable,节点控制器无法触及节点,对应节点状态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

在kubernetes 1.13版本,基于污点的驱离策略提升到beta级别并且默认开启,因此污点被node控制器(kubelete)自动添加,并且普通的以节点的Ready状态为基础的驱离策略被禁用.

这项beta功能,加上tolerationSeconds,允许节点来指定仍然可以留存长时间即便节目有一种或者多种匹配的问题

例如:一个包含多种本地状态的应用在节点发生网络分裂情况时希望仍然可以留存一点时间,期望在指定的时段内网络能恢复正常以避免被驱离.这种情况下容忍此节点的pod编排如下

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

请注意,如果用户没有在pod的配置中指定node.kubernetes.io/not-ready,则kubernetes会自动为pod配置加上node.kubernetes.io/not-ready tolerationSeconds=300属性.同样地,如果没有配置,则自动添加node.kubernetes.io/unreachable tolerationSeconds=300

DaemonSet类型的pod创建时自动为以下两种类型的taint添加NoExecute效果类型并且没有tolerationSeconds

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

这确保即便节点出现问题,DaemonSet也不会被驱离.

有条件节点taint

在kubernetes 1.12版,有条件为节点添加taint(TaintNodesByCondition)特征被提升为beta级别,节点生命周期控制器会自动根据节点的状态为节点添加taint.同样地调度器不检测node的状态,而是检测node 的污点(taint).这确保node的状态不影响哪些pod可以调度到此node上,用户可以选择通过添加相应的容忍(toleration)来忽略node的指定的问题(通过node的状态体现).注意TaintNodesByCondition仅添加NoSchedule类型的污点.NoExecute效果类型由TaintBasedEviction控制(此功能为1.13版本的beta功能)

从kubernetes 1.8开始,DaemonSet controller自动以下类型的为所有的daemon添加NoSchedule效果类型的容忍(toleration),来防止DeamonSet分裂

• node.kubernetes.io/memory-pressure
• node.kubernetes.io/disk-pressure
• node.kubernetes.io/out-of-disk (only for critical pods)
• node.kubernetes.io/unschedulable (1.10 or later)
• node.kubernetes.io/network-unavailable (host network only)

添加了这些类型的容忍是为了向后兼容,你可以为DaemonSet添加任意类型的容忍

原文地址：https://www.cnblogs.com/tylerzhou/p/11026364.html