作为一名 Kubernetes 集群管理员或开发者，你是否曾经遇到过这样的困惑：为什么我的 Pod 没有调度到那台配置最强大的服务器上？或者，为什么关键的业务应用被挤压到了同一个节点，而其他节点却空闲着？在这篇文章中，我们将深入探讨 Kubernetes 中一项至关重要的调度机制——污点和容忍。我们将通过实际的代码示例和底层原理，向你展示如何像编排大师一样，精确控制 Pod 在集群中的位置，确保资源的合理利用和应用的稳定性。
在 Kubernetes 的世界里，调度器扮演着“交通指挥官”的角色。当你提交一个 Pod 时，API Server 接收到请求，调度器便开始工作，它会根据 CPU、内存、磁盘以及各种规则来决定这个 Pod 应该“定居”在哪个节点上。然而，默认的调度策略往往不能满足我们所有的业务需求。比如，我们可能希望拥有 GPU 的节点只留给机器学习任务，或者我们希望为特定的数据库应用独占一台物理机。这时，单纯靠标签选择器就不够用了，我们需要更强大的工具：污点 和 容忍。
为什么我们需要污点与容忍？
在深入代码之前，让我们先理解为什么需要这个机制。想象一下，你的集群中有一台配置极高的服务器，配备了昂贵的 GPU 和大容量内存。你肯定不希望一个简单的“Hello World”测试应用占用这台机器的资源。这时，我们需要一种机制来“排斥”普通的 Pod，同时只允许特定的 Pod 通过“检查”。
这正是污点和容忍的用武之地。我们可以把这两个概念比作“驱蚊剂”和“免疫力”：
- 污点：是节点上的标记，好比一个人喷了驱蚊剂。这意味着一般的 Pod（蚊子）是无法停留在该节点上的。
- 容忍：是 Pod 上的标记，好比一只黄蜂对驱蚊剂免疫。即使节点有污点，带有对应容忍的 Pod 依然可以被调度上去。
实际应用场景
让我们更具体地看看我们会在哪些场景下使用它们：
- 专用节点：假设你有两种应用，APP1 是一个普通的 Web 前端，资源消耗低；APP2 是一个数据密集型的人工智能训练任务，需要高性能 GPU。通过在 GPU 节点上设置污点，我们可以确保 APP1 被阻挡在外，只有 APP2 通过容忍设置被调度到 GPU 节点上。
- 独占节点：为了性能，你可能希望某个关键数据库应用独占一台机器的所有资源。我们可以给该节点设置污点，阻止其他 Pod 调度，同时给数据库 Pod 设置容忍。这种组合配合 Node Affinity（节点亲和性）还可以确保 Pod 就在特定的节点运行。
- 节点维护与驱逐：当需要对节点进行升级维护时，我们可以给节点添加特定的污点。Kubernetes 会自动识别这个污点，并将该节点上现有的 Pod 驱逐到其他健康的节点上，确保服务不中断。
核心概念与工作原理
污点和容忍是协同工作的键值对。让我们拆解一下它们的组成。
污点是应用于节点上的一个属性。它由三个部分组成：
key=value:effect
- Key：污点的键（例如 INLINECODE8a64b9c6，INLINECODE4d61bf04）。
- Value：污点的值（例如 INLINECODE698308a4，INLINECODE48efe981）。
- Effect（污点效果）：这定义了当 Pod 不能容忍该污点时，会发生什么。这是最关键的部分。
容忍是应用在 Pod 上的，用于告诉调度器：“我愿意接受带有特定污点的节点”。要实现匹配，Pod 的容忍必须满足以下条件之一：
- 完全匹配：Key、Value 和 Effect 都与节点的污点一致。
- 存在性检查：如果不指定 Value，或者 Operator 设置为
Exists，只要 Key 和 Effect 匹配即可。
深入理解三种污点效果
Kubernetes 为我们提供了三种不同的污点效果，分别对应不同的控制力度。理解它们的区别是掌握调度的关键。
1. NoSchedule (禁止调度)
这是最常用的一种效果，属于“软性排斥”。
- 行为：如果节点上有
NoSchedule污点，Kubernetes 调度器将不会把不容忍该污点的 Pod 调度到该节点上。 - 特殊情况：这是一个关键点，已经在该节点上运行的 Pod 不会受到影响，它们会继续运行。这意味着 NoSchedule 主要影响的是新创建的 Pod，对存量 Pod 是“怀柔”政策。
2. PreferNoSchedule (尽量不调度)
这是一种“尽力而为”的策略，属于“建议性排斥”。
- 行为：调度器会尽量避免把 Pod 放到带有这种污点的节点上。但是，如果集群资源不足，或者没有其他节点可供选择，调度器依然有可能会把 Pod 调度到这里。这并不是一种硬性限制，更像是一种优先级的建议。
3. NoExecute (驱逐并禁止调度)
这是最“严厉”的一种效果，属于“强制驱逐”。
- 行为：这种污点不仅会阻止新 Pod 的调度，还会对现有的 Pod 产生影响。
- 驱逐机制：如果 Pod 没有容忍该污点，它会被立即从该节点驱逐。这通常用于节点故障排查、版本升级或者强制隔离某台机器的场景。
实战演练：命令与代码
现在，让我们动手试试。我们将通过命令行工具 kubectl 来设置污点，并通过 YAML 文件来配置 Pod 的容忍。
第一步：给节点设置污点
假设我们有一个名为 node-1 的节点，它有特殊的 GPU 硬件。我们希望它只运行特定的计算任务。命令如下：
# 使用 kubectl taint 命令
# 格式：kubectl taint nodes =:
kubectl taint nodes node-1 hardware=gpu:NoSchedule
``
执行完这条命令后，`node-1` 就像贴了一张封条。普通用户提交的 Pod 将无法在这台机器上运行。
### 第二步：验证污点
我们可以通过 `describe` 命令来查看节点的详细信息，确认污点是否设置成功：
bash
kubectl describe node node-1 | grep Taint
`INLINECODE1a698015Taints: hardware=gpu:NoScheduleINLINECODEf5be852b`
**2. 不要滥用污点**
污点和容忍主要用于“独占”或“隔离”场景。如果你的目的仅仅是将 Pod 尽量调度到某类节点上，但又不强制禁止其他 Pod，那么 **Node Affinity（节点亲和性）** 可能是更好的选择。例如，如果你希望日志应用分散在各个节点上，而不是堆积在一起，使用 Pod 反亲和性会更合适。
**3. 结合使用效果最佳**
在实际生产环境中，我们通常会结合多种策略。例如：
* 使用 **Node Affinity** 确保特定应用的 Pod 优先去往特定硬件节点。
* 使用 **Taints** 防止其他无关 Pod 抢占这些特定资源。
这种“软硬兼施”的策略，能最大程度地保障集群的稳定性和性能。
## 总结
我们在今天的学习中，揭开了 Kubernetes 污点和容忍的神秘面纱。我们从蚊子和驱蚊剂的比喻入手，了解了它们如何协同工作以控制 Pod 的调度。我们对比了三种不同的污点效果，并通过实际的 kubectl` 命令和 YAML 代码，掌握了如何配置和管理它们。
掌握污点和容忍，意味着你不再仅仅是一个 Kubernetes 的使用者，而是一个能够精细控制集群资源的架构师。你可以根据业务需求，为关键应用打造专属的运行环境，或者在维护时实现零停机平滑迁移。
接下来，我鼓励你尝试在自己的测试集群中创建一个带污点的节点，并编写一个带有容忍的 Pod，亲眼看看它是如何被调度到那个“禁区”的。只有通过动手实践，这些概念才能真正转化为你的实战技能。祝你调度愉快！