关于k8s节点污点对系统pod的影响
1.背景信息
在我们部门规划中，计划使用一套 Kubernetes 集群部署两个环境（pre 和 prod）。目前，pre 环境的节点池名称为 pool01-10，prod 环境的节点池名称为 101-110。为了确保 pre 的 Pod 部署到 pre 的节点池，prod 的 Pod 部署到 prod 的节点池，我在所有 Pod 上配置了节点亲和性标签 env:prod/pre 以及容忍污点标签 env:prod/pre。同时，我在 pre 和 prod 的节点上分别设置了对应的污点 env:prod/pre 以及节点标签 env:prod/pre。
在打上这些标签后，出现了两个疑问：
1.CoreDNS 以及loki部署正常，但一直处于告警状态。
2.阿里云 Logtail 没有配置容忍污点，但依然能够部署到已经设置污点的节点，并且没有产生告警。
2.原因
1.CoreDNS 以及loki部署正常，但一直处于告警状态。
问题的原因在于 CoreDNS 和 Loki 并未配置容忍污点，而我先部署了这些 Pod，之后才为 pre 环境的节点添加了污点。因此，尽管 Pod 没有容忍污点，但由于我的污点策略设置为 NoSchedule，这些 Pod 并不会被驱逐，但仍然会触发告警。
2.阿里云 Logtail 没有配置容忍污点，但依然能够部署到已经设置污点的节点，并且没有产生告警。
首先来看一下logtail的污点容忍配置
查看以上配置“- operator: Exists”,这一行配置等于如果只使用 operator: Exists，则表示 Pod 容忍所有带有该污点的节点，不关心污点的具体键和值，简单来说，只要你有污点，我就可以匹配，万能公式。
3.案例
根据上述原因，还有以下几种情况，理解了这些案例后，基本可以掌握污点配置的使用。
operator: "Exists" 含义
- operator: "Exists"：只检查污点的 key 是否存在，不关心 value。
- 如果 key 存在，Pod 会匹配该污点并容忍。
- effect 需要匹配（如 NoSchedule、NoExecute 等）。
例子 1：匹配所有 NoSchedule 污点
tolerations:
- operator: "Exists"
effect: "NoSchedule"
解析：匹配任何 NoSchedule 类型的污点，忽略 key 和 value。
示例污点：
kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node2 key2=value2:NoSchedule
结果：Pod 会匹配这两个节点。
例子 2：只匹配 key1，忽略 value
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
解析：匹配 key1，不关心 value，只要 effect=NoSchedule。
示例污点：
kubectl taint nodes node1 key1=valueA:NoSchedule
kubectl taint nodes node2 key1=valueB:NoSchedule
结果：Pod 会匹配 node1 和 node2。
例子 3：匹配 key1 的所有 effect
tolerations:
- key: "key1"
operator: "Exists"
解析：匹配 key1，不关心 effect，适用于任何 effect（如 NoSchedule、NoExecute）。
总结
简单理解：
- operator: "Exists" 表示只要 key 存在，Pod 就会匹配，忽略 value。
- effect 仍然需要匹配。
4.建议配置
由于我司在阿里云 Kubernetes 上部署了两套环境（prod/pre），并且未来可能还会部署一些其他的边缘组件，这些组件可能没有阿里云预配置的污点。为此，提出以下两种建议方案：
1. 新增一个公共节点池，用于部署如 emqx、higress、coredns 等系统及其他 pod。
2. 不在节点上添加污点，而是要求所有 pod 使用节点亲和性，这样即使是未知的 pod，也不会导致处于 pending 状态。
5.参考
https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/
浙公网安备 33010602011771号