将Daemonset管理器容忍所有的Taints

Daemonset Taints

字数统计: 579阅读时长: 2 min

 2021/03/25   Share

前言

我们都知道, kubernetes的daemonset控制器,可以将副本每个运行在集群中的所有节点中,并且 daemonset 控制器默认会对Pod添加污点容忍度

容忍度健名	效果	版本	描述
`node.kubernetes.io/not-ready`	NoExecute	1.13+	当出现类似网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。
`node.kubernetes.io/unreachable`	NoExecute	1.13+	当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。
`node.kubernetes.io/disk-pressure`	NoSchedule	1.8+
`node.kubernetes.io/memory-pressure`	NoSchedule	1.8+
`node.kubernetes.io/unschedulable`	NoSchedule	1.12+	DaemonSet Pod 能够容忍默认调度器所设置的 unschedulable 属性.
`node.kubernetes.io/network-unavailable`	NoSchedule	1.12+	DaemonSet 在使用宿主网络时，能够容忍默认调度器所设置的 network-unavailable 属性

这些容忍度可以保证Pod可以允许在集群中的每个节点.

但是, 如果是我们用户自定义的Taint呢？

将Pod容忍所有的Taint

我们这时候就会发现一个有意思的事情, 如果我们将集群中的某个节点打上Taint, 就会发现我们自己设置的daemonset副本全部被驱逐,并且无法被调度回来. 而kube-system下的daemonset 如：kube-proxy就不会出现这种问题.

我们也可以在用户自己的daemonset当中设置容忍, 解决这个问题，但是kube-proxy到底是怎么做的呢？

通过观察,kube-proxy的配置,我们发现了关键

kube-proxy

- operator: Exists
- effect: NoExecute
  key: node.kubernetes.io/not-ready
  operator: Exists
- effect: NoExecute
  key: node.kubernetes.io/unreachable
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/disk-pressure
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/memory-pressure
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/pid-pressure
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/unschedulable
  operator: Exists

用户自己的

- effect: NoExecute
  key: node.kubernetes.io/not-ready
  operator: Exists
- effect: NoExecute
  key: node.kubernetes.io/unreachable
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/disk-pressure
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/memory-pressure
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/pid-pressure
  operator: Exists
- effect: NoSchedule
  key: node.kubernetes.io/unschedulable
  operator: Exists