前言

我们都知道, 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