您的位置:首页 > 运维架构 > Kubernetes

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

2019-06-15 08:22 1366 查看

系列目录

节点亲和性(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添加任意类型的容忍

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: