第 1 章：调度基础与核心概念

1.1 kube-scheduler 是如何工作的

当你创建一个 Pod 时，它并不会立刻运行。Kubernetes 调度器（kube-scheduler）负责为它挑选一个合适的节点。调度分两个大阶段：

┌─────────────────────────────────────────────────────────┐
│                    kube-scheduler                        │
│                                                          │
│  阶段一：Filtering（过滤）                                 │
│  ─────────────────────────                               │
│  把"绝对不能去"的节点全部筛掉：                            │
│   ✗ 资源不足（CPU/内存不够）                               │
│   ✗ 节点有污点，Pod 没有容忍  ←—— 本章主题               │
│   ✗ 不满足 nodeSelector / nodeAffinity                   │
│   ✗ 端口冲突、卷冲突、节点 NotReady 等                    │
│                                                          │
│  阶段二：Scoring（打分）                                   │
│  ─────────────────────────                               │
│  给剩下的节点打分，挑分最高的：                            │
│   · 资源均衡（LeastRequested / BalancedAllocation）       │
│   · 亲和性加分（preferred nodeAffinity）                   │
│   · 镜像本地化、拓扑分散等                                 │
└─────────────────────────────────────────────────────────┘

关键认知：污点/Toleration 工作在 Filtering（过滤）阶段，它是一个"一票否决"机制，不是"吸引"机制。

1.2 为什么需要污点与容忍

想象这些场景：

主节点保护：Master/Control-plane 节点只跑系统组件，业务 Pod 不许上来。
专用节点：某批节点是给某个团队/某类业务专用的，别人的 Pod 不许混进来。
特殊硬件：GPU 节点很贵，只有真正需要 GPU 的 Pod 才允许调度上去。
节点故障：节点网络出问题了，不仅要阻止新 Pod 上来，还要把已有的 Pod 赶走。

前 3 个场景用"标签 + nodeSelector"只能做到"我的 Pod 去哪儿"，做不到"别人的 Pod 别来"。污点解决的是节点的"拒绝权"问题。

1.3 核心概念对照

概念	定义在	作用	类比
Taint（污点）	Node 对象	节点声明：拒绝没有对应容忍的 Pod	门口挂的"非请勿入"牌子
Toleration（容忍）	Pod spec	Pod 声明：我能忍受（匹配）某些污点	访客手里的"通行证"

匹配关系：Pod 的某个 Toleration 能"容忍"节点的某个 Taint 时，该污点才不会阻止 Pod 调度到该节点。

⚠️ 最容易混淆的一点（务必记住）：容忍 ≠ 吸引。Pod 容忍了节点的污点，只表示"不拒绝"，调度器仍可能把它调度到别的节点。想保证"必须调度到这批节点"，需要配合 nodeAffinity（见第 6 章）。

1.4 一个最小完整例子

bash

# 1. 给 node1 打污点：拒绝没有容忍的 Pod
kubectl taint nodes node1 dedicated=special:NoSchedule

# 2. 没有容忍的 Pod —— 会一直 Pending，调度不上 node1
kubectl run web --image=nginx

# 3. 有容忍的 Pod —— 可以调度到 node1

yaml

apiVersion: v1
kind: Pod
metadata:
  name: web-tolerated
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "special"
    effect: "NoSchedule"
  containers:
  - name: nginx
    image: nginx

1.5 污点的三种效果（Effect）速览

Effect	对已运行的 Pod	对新 Pod 的调度	典型用途
`NoSchedule`	不影响	硬约束：不能调度	专用节点、Master 保护
`PreferNoSchedule`	不影响	软约束：尽量避免	温和的资源隔离
`NoExecute`	驱逐不匹配的 Pod	硬约束：不能调度	节点维护、故障隔离

第 2 章会逐一深入讲解。

本章小结

调度器先过滤再打分；污点/Toleration 属于过滤阶段的硬/软约束。
污点在节点上，容忍在 Pod 上；容忍是通行证，不是邀请函。
三种 Effect：NoSchedule（硬拒绝）、PreferNoSchedule（软拒绝）、NoExecute（拒绝 + 驱逐）。

思考题

给节点打了 NoSchedule 污点后，已经在该节点运行的 Pod 会怎样？
Pod 有了某个污点的容忍，是否一定会被调度到那个节点？为什么？
如果节点上有 3 个污点，Pod 只容忍了其中 2 个，能调度上来吗？

（答案见第 8 章面试题部分）

第 1 章：调度基础与核心概念 ​

1.1 kube-scheduler 是如何工作的 ​

1.2 为什么需要污点与容忍 ​

1.3 核心概念对照 ​

1.4 一个最小完整例子 ​

1.5 污点的三种效果（Effect）速览 ​

本章小结 ​

思考题 ​