Kubernetes 中的污点（Taints）与容忍度（Tolerations）高级应用

好嘞！各位程序猿、攻城狮们，还有未来的AI大师们！今天咱们不聊诗和远方，就来聊聊Kubernetes里有点“小脾气”的污点(Taints)和“海纳百川”的容忍度(Tolerations)。别怕，这玩意儿听起来高大上，其实就像谈恋爱，一个有点原则，一个能包容，才能长长久久嘛！ 😜

开场白：Kubernetes的“择偶观”

在Kubernetes这个集群王国里，Pod们就像一个个嗷嗷待哺的小程序，需要找到合适的Node（节点）安家落户，才能开始它们的表演。 Kubernetes的调度器（Scheduler）就像个媒婆，负责把Pod们“嫁”给合适的Node。

但问题来了，Node也不是随便什么Pod都收留的。有些Node可能比较“挑剔”，比如：

“我是GPU节点，只接待需要高性能计算的Pod！” (内心OS: 那些跑个Web应用的，别来沾边!)
“我是专门跑数据库的，闲杂人等请勿靠近！” (内心OS: 你们这些搞前端的，数据库压力很大好不好!)
“我资源紧张，只允许优先级高的Pod入住！” (内心OS: 先来后到懂不懂？!)

这些“挑剔”的性格，在Kubernetes里就用污点(Taint)来表示。

而Pod们呢，也不是个个都娇生惯养，有些Pod比较“随和”，只要能运行就行，不挑环境。这种“随和”的性格，就用容忍度(Toleration)来表示。

一、污点(Taints)：Node的“免战牌”

想象一下，你家门口挂了个“谢绝访客”的牌子，这就是污点的作用。污点是一种Node上的属性，用于阻止某些Pod调度到该Node上。

1. 污点的结构

一个污点由以下几个部分组成：

key: 污点的键名，就像牌子上的标题，说明拒绝什么类型的Pod。
value: 污点的值，就像牌子上的具体说明，更详细地说明拒绝的理由。
effect: 污点的作用，决定了Pod不满足条件时会发生什么。

2. 污点的三种作用(effect)

这三种作用就像三种不同级别的“谢绝访客”：

NoSchedule: 这是最严格的。如果Pod没有匹配的容忍度，就绝对不会被调度到这个Node上。就像你家门口写着“生人勿近”，谁敢硬闯？ 🙅
PreferNoSchedule: 这是比较温和的。 Kubernetes会尽量避免将Pod调度到这个Node上，但如果实在找不到其他合适的Node，还是会勉强接受。就像你家门口写着“非请勿入”，但如果你是快递员，还是可以敲门的。 😅
NoExecute: 这是最狠的。如果Pod已经在这个Node上运行，但Node突然添加了NoExecute污点，且Pod没有匹配的容忍度，那么Pod会被立即驱逐。就像你正在朋友家做客，突然朋友说：“不好意思，我要睡觉了，你走吧！” 直接扫地出门啊！ 😱

3. 如何给Node“贴标签” (添加污点)

使用kubectl taint命令可以给Node添加污点：

kubectl taint nodes <node-name> <key>=<value>:<effect>

举个例子：

kubectl taint nodes node1 dedicated=gpu:NoSchedule

这条命令会在名为node1的Node上添加一个污点，表示该Node是专门用于GPU计算的，没有匹配容忍度的Pod绝对不能调度到这个Node上。

4. 如何查看Node上的污点

使用kubectl describe node <node-name>命令可以查看Node的详细信息，包括污点：

kubectl describe node node1

输出结果中会包含Taints:字段，显示Node上的所有污点。

二、容忍度(Tolerations)：Pod的“通行证”

容忍度是Pod的一种属性，用于允许Pod调度到具有匹配污点的Node上。就像你拿着一张“通行证”，可以进入某些“谢绝访客”的地方。

1. 容忍度的结构

一个容忍度由以下几个部分组成：

key: 容忍的污点键名，必须与Node上的污点键名匹配。
value: 容忍的污点值，必须与Node上的污点值匹配。如果operator是Exists，则可以省略。
operator: 操作符，用于指定如何匹配污点的值。有两种取值：
- Equal: (默认值) 要求污点值必须完全相等。
- Exists: 只要污点的键名存在，就认为匹配。
effect: 容忍的污点作用，必须与Node上的污点作用匹配。
tolerationSeconds: 只有当effect为NoExecute时才有效。表示Pod可以容忍NoExecute污点的时间，超过这个时间Pod会被驱逐。如果不设置，则表示永远容忍。

2. 如何给Pod“开后门” (添加容忍度)

在Pod的YAML文件中，使用tolerations字段来添加容忍度：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

这个Pod的YAML文件中，定义了一个容忍度，表示该Pod可以容忍键名为dedicated，值为gpu，作用为NoSchedule的污点。也就是说，这个Pod可以被调度到具有dedicated=gpu:NoSchedule污点的Node上。

3. 容忍度的“高级用法”

容忍所有污点: 如果你想让Pod可以调度到任何Node上，可以添加一个空的容忍度：
```
tolerations:
- operator: "Exists"
```
或者，你可以使用通配符：
```
tolerations:
- key: "*"
  operator: "Exists"
```
这就像给Pod发了一张“无限通行证”，任何Node都欢迎它。
容忍一段时间: 如果你想让Pod在Node添加NoExecute污点后，还可以继续运行一段时间，可以设置tolerationSeconds：
```
tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 600
```
这条配置表示，如果Node变为不可达，该Pod还可以继续运行600秒，之后才会被驱逐。这就像给Pod一个“缓冲期”，让它有时间优雅地关闭。

三、污点和容忍度的“恋爱秘籍”

现在，我们来总结一下污点和容忍度之间的关系，就像情侣之间的相处之道：

污点是Node的“原则底线”，容忍度是Pod的“包容能力”。 只有当Pod的容忍度满足Node的污点时，Pod才能被调度到该Node上。
污点和容忍度必须“门当户对”。 key、value和effect必须匹配，才能成功“牵手”。
容忍度可以“无限包容”，污点却不能“无限挑剔”。 Pod可以使用Exists操作符来容忍所有污点，但Node不能使用通配符来拒绝所有Pod。
NoExecute污点是“分手警告”，tolerationSeconds是“冷静期”。 Pod可以设置tolerationSeconds来容忍NoExecute污点一段时间，给自己一个机会，也给对方一个机会。

四、实战演练：打造一个“专属GPU集群”

现在，我们来做一个小实验，创建一个“专属GPU集群”，只有拥有GPU容忍度的Pod才能调度到GPU Node上。

1. 给GPU Node添加污点:

假设我们有一个名为gpu-node的Node，我们给它添加一个污点：

kubectl taint nodes gpu-node dedicated=gpu:NoSchedule

2. 创建一个需要GPU的Pod:

创建一个YAML文件，例如gpu-pod.yaml，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
  - name: gpu-container
    image: nvidia/cuda:11.0-base
    resources:
      limits:
        nvidia.com/gpu: 1 # 请求一个GPU资源
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

这个Pod定义了一个GPU容器，并添加了一个容忍度，允许它调度到具有dedicated=gpu:NoSchedule污点的Node上。

3. 创建一个不需要GPU的Pod:

创建一个YAML文件，例如normal-pod.yaml，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: normal-pod
spec:
  containers:
  - name: normal-container
    image: nginx

这个Pod没有任何容忍度。

4. 验证结果:

分别创建这两个Pod：

kubectl create -f gpu-pod.yaml
kubectl create -f normal-pod.yaml

使用kubectl get pods -o wide命令查看Pod的调度情况：

kubectl get pods -o wide

你会发现，gpu-pod被调度到了gpu-node上，而normal-pod被调度到了其他Node上。这就证明了我们的“专属GPU集群”已经成功搭建！

五、总结：污点与容忍度的“人生哲学”

各位，今天我们一起学习了Kubernetes的污点和容忍度。这玩意儿不仅仅是技术，更是一种“人生哲学”：

要学会“挑剔”，也要学会“包容”。 Node要有自己的原则，Pod也要有自己的适应能力。
要找到“合适的人”，才能“幸福地生活”。 Pod和Node要互相匹配，才能和谐共处。
要给自己一个“缓冲期”，才能“优雅地转身”。 tolerationSeconds就像人生中的冷静期，让我们有时间思考，做出更明智的选择。

希望今天的分享能帮助大家更好地理解Kubernetes的污点和容忍度，并在实际工作中灵活运用。记住，技术是死的，人是活的，要用自己的智慧去驾驭技术，创造价值！ 🎉

最后，送大家一句“鸡汤”：

愿你既有“原则底线”，也能“海纳百川”，在Kubernetes的世界里，找到属于自己的“完美伴侣”！ 😊

发表回复 取消回复

发表回复取消回复