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
值为falsenode.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添加任意类型的容忍
- Kubernetes1.6新特性:POD高级调度-污点和容忍特性/报告节点问题特性
- Kubernetes的污点和容忍(上篇)
- Kubernetes的污点和容忍(下篇)
- Kubernetes的污点和容忍(上篇)
- Kubernetes的污点和容忍(下篇)
- Kubernetes之Taints与Tolerations 污点和容忍
- Kubernetes容器调度策略
- kubernetes 通过annotations指定调度节点
- 从kubernetes看如何设计超大规模资源调度系统
- TaintDroid剖析之Native方法级污点跟踪分析
- TaintDroid剖析之File & Memiry & Socket级污点传播
- TaintDroid剖析之Native方法级污点跟踪分析
- 【有容云干货-容器系列】Kubernetes调度核心解密:从Google Borg说起
- 从kubernetes看如何设计超大规模资源调度系统
- Kubernetes 1.6新特性系列 | 高级调度
- Kubernetes1.6新特性:POD高级调度-POD调度器配置变化
- kubernetes 调度控制原理
- 解析Kubernetes 1.8中的基于Pod优先级的抢占式调度
- Kubernetes1.6新特性:POD高级调度-亲和性/反亲和性特性
- Kubernetes容器调度策略