pod-7

考察点：污点容忍和节点选择器的使用。

注意：
在cka的考试中，他一般比较绝对，题目上明确说明精确的匹配到node01，那么我们就要注意选择tolerations的参数，因为你的operator:Exisit的话他是默认不检查value的，说明只要节点的Taints里有你所指定的key他都会调度不会去管是不是node01，我们如果设置成operator:Equal时，这样他就会去匹配value里的值看是否和node01的Taintsl里的value匹配，如果有则直接就调度到node01上，这有一个前提条件就是你的nodeselector必须先匹配node01的key和value因为题目上明确指出了要调度到node01。

让我们重新审视 nodeSelector 和 tolerations 的核心作用：

nodeSelector (或 nodeAffinity)：
- 作用： 这是约束性规则，用于吸引或强制 Pod 调度到满足特定标签条件的节点上。它告诉调度器：“我只允许 Pod 运行在满足这些条件的节点上。”
- 性质： 它是一个正面选择器。如果节点不匹配 nodeSelector，调度器根本不会考虑它。
tolerations：
- 作用： 这是允许性规则，用于容忍节点上的污点 (Taints)。污点的作用是排斥 Pod（除非 Pod 有相应的容忍）。tolerations 告诉调度器：“这个 Pod 可以忽略某个特定的排斥规则（污点），从而允许它调度到有这个污点的节点上。”
- 性质： 它是一个负面规则的豁免者。它不吸引 Pod，它只是移除一个障碍。

调度过程的逻辑概括：
当调度器为一个 Pod 选择节点时，它会执行以下高级步骤：

预选 (Predicates)：
- nodeSelector 过滤：调度器会首先过滤掉那些不满足 Pod nodeSelector 条件的节点。
- 污点/容忍检查：对于通过 nodeSelector 筛选出来的节点，调度器会检查这些节点上的污点。如果节点有污点，并且 Pod 没有对应的容忍，那么这个节点也会被排除。
- 其他资源限制、端口冲突等检查。
优选 (Priorities)：
- 对通过预选的节点进行打分，选择分数最高的节点。

问题： “如果我不写 nodeSelector 字段，是不是凭借 tolerations 就可以把 Pod 调度到 node01 上了？”

答案： 不一定。

原因：

假设你的集群有 node01 (有 nodeName=workerNode01:NoSchedule 污点) 和 node02 (无此污点)。

调度器在没有 nodeSelector 的情况下：
调度器会寻找所有满足 Pod 基本资源需求（CPU、内存等）、端口不冲突等预选条件的节点。此时，node02 是一个完全合格的候选节点，因为它没有任何污点会排斥你的 Pod。
tolerations 的作用：
你的 Pod 配置了 tolerations，这使得它能够容忍 node01 上的 nodeName=workerNode01:NoSchedule 污点。这意味着 node01 也成为了一个合格的候选节点。
调度结果的不确定性：
现在，调度器面临两个合格的节点：node01 和 node02。在没有 nodeSelector 明确指示 Pod 必须去 node01 的情况下，调度器会根据其内部的优选算法（Priorities）来选择一个分数最高的节点。
- 常见的优选算法考虑因素包括： 节点资源的利用率、Pod 的紧凑度、节点本地存储、节点健康状况等。
- 调度器并不会因为 Pod 能够容忍 node01 的污点，就优先选择 node01。事实上，如果 node02 负载更轻、资源更充足，或者其他优选算法让它得分更高，那么 Pod 很可能就会被调度到 node02 上。

结论：

tolerations 仅仅是让 Pod 有了进入特定节点的“通行证”，但这张通行证并不能“指引”Pod 前往该节点。
nodeSelector 才是真正的“指南针”或“过滤器”，它明确地限制了 Pod 只能去某些节点。

因此，为了确保你的 redis-pod 被调度到 node01，你需要同时使用 nodeSelector 和 tolerations：

nodeSelector: kubernetes.io/hostname: node01 确保了只有 node01 会被考虑。
tolerations 确保了 Pod 能够容忍 node01 上可能存在的污点，从而被允许调度到它。

这两者是协同工作的，一个负责选择目标，另一个负责清除障碍。

posted on 2025-06-14 22:21 Leo-Yide 阅读(8) 评论(0) 收藏举报