调度入门：把 Pod 放到合适的节点上

调度器到底在做什么#

前面几章里，你只写了「我要 3 个副本」，从来没说过它们该跑在哪台机器上。做出这个决定的是 kube-scheduler：它盯着所有 spec.nodeName 为空的 Pod，替它们挑一个节点。挑选分三步，你写的每一条约束都挂在其中某一步上：

你提交 Pod（spec.nodeName 为空）
        │
        ▼
① 过滤 Filter：把不合格的节点全部排除，活下来的才能进入下一步
   · 资源够不够（requests 里的 CPU / 内存、端口冲突）
   · nodeSelector / nodeAffinity 的 required   ← 硬约束在这里
   · 节点污点 taints vs Pod tolerations        ← 污点在这里
   · podAffinity 的 required、卷拓扑、节点状态
        │  活下来的节点（0 个 → Pod 停在 Pending，原因写进事件）
        ▼
② 打分 Score：给候选节点排序 0~100
   · ImageLocality：镜像是不是已经在这台机器上
   · LeastAllocated：谁更空闲
   · nodeAffinity 的 preferred、podAffinity、
     topologySpreadConstraints        ← 软约束在这里加分
        │  取最高分（并列时随机挑一个）
        ▼
③ 绑定 Bind：写入 spec.nodeName，该节点 kubelet 开始拉镜像、起容器

如果没有节点通过「过滤」这一关，Pod 就停在 Pending，事件里会写 0/N nodes are available: ...，冒号后面列出每个节点被排除的原因。这是排查调度问题最重要的一句话。

最简单的指定方式：nodeSelector 与 nodeName#

nodeSelector 是最容易上手的写法：给节点打标签，Pod 里写上同名标签，两边完全相等才会被调度过去。

# 1. 看一眼节点名字，后面所有命令都用这个变量
NODE=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

# 1. 给节点打标签并确认
kubectl label node "$NODE" disktype=ssd
kubectl get node "$NODE" --show-labels

apiVersion: v1
kind: Pod
metadata:
  name: web-pinned
spec:
  nodeSelector:
    disktype: ssd
  containers:
    - name: web
      image: nginx:1.27

kubectl apply -f web-pinned.yaml
kubectl get pod web-pinned -o wide

-o wide 会多出一列 NODE，确认它就是你打了标签的那台。kubectl describe pod web-pinned 的 Events 里应该有一行 Successfully assigned default/web-pinned to <节点名>。

nodeName 则是最粗暴的写法：直接告诉 kubelet「这个 Pod 归你了」，完全不经过调度器。

apiVersion: v1
kind: Pod
metadata:
  name: web-forced
spec:
  nodeName: kind-control-plane   # 直接指定节点，跳过调度
  containers:
    - name: web
      image: nginx:1.27

亲和性：nodeAffinity、podAffinity 与拓扑分布#

节点亲和性：required 与 preferred#

nodeSelector 只能表达「等于」，而且只有硬性要求。nodeAffinity 补上了两个能力：更丰富的匹配表达式，以及「尽量满足」的软约束。

apiVersion: v1
kind: Pod
metadata:
  name: web-preferred
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/os
                operator: In
                values:
                  - linux
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
              - key: disktype
                operator: In
                values:
                  - ssd
  containers:
    - name: web
      image: nginx:1.27

常用的 operator 有 In、NotIn、Exists、DoesNotExist、Gt、Lt。注意 nodeSelectorTerms 之间是「或」，matchExpressions 之间是「与」，写多个条件时很容易记反。

Pod 亲和与反亲和#

podAffinity 关心的是「别的 Pod 在哪」，而不是节点标签。最常用的场景是反亲和：让同一个 Deployment 的多个副本不要挤在同一台机器上，一台机器挂了不至于全灭。

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app: web
            topologyKey: kubernetes.io/hostname

topologyKey 是「按什么维度分开」：kubernetes.io/hostname 表示按节点分，也可以写 topology.kubernetes.io/zone 表示按可用区分。

拓扑分布约束#

topologySpreadConstraints 一句话：按 topologyKey 把副本均匀撒到多个故障域，用 maxSkew 控制允许的最大偏差，whenUnsatisfiable: ScheduleAnyway 是软约束、DoNotSchedule 是硬约束。副本数多、要求打散时，它比反亲和更好用——反亲和只能表达「不在一起」，它还能表达「每台最多差 1 个」。

污点与容忍#

前面都是 Pod 挑节点，污点反过来：节点主动拒绝 Pod。节点上打污点，只有声明了对应「容忍」的 Pod 才能落上去。控制面节点就是这么保护自己的。

# 给节点打污点：key=value:效果
kubectl taint nodes "$NODE" dedicated=kube101:NoSchedule

# 查看污点（Taints 一行）
kubectl describe node "$NODE" | grep -i taints

# 删除污点：末尾加一个减号
kubectl taint nodes "$NODE" dedicated=kube101:NoSchedule-

三种效果的区别：

Pod 侧的容忍长这样：

spec:
  tolerations:
    - key: dedicated
      operator: Equal
      value: kube101
      effect: NoSchedule

operator 用 Exists 时可以省略 value，表示「只要键在就行」；key 也留空的话就是容忍一切污点，等于放弃保护，慎用。NoExecute 还支持 tolerationSeconds，表示「忍 N 秒再走」，常用于节点失联后的宽限期。

控制面节点默认带的污点是 node-role.kubernetes.io/control-plane:NoSchedule（较早的版本里键名是 master）。kubeadm 装出来的集群因此不允许普通业务 Pod 落在控制面；kind 这类单节点实验集群通常已经把它去掉了，用 kubectl describe node "$NODE" | grep -i taints 看一眼就知道。

维护节点：cordon / drain / uncordon#

要给一台节点打补丁、换内核或下线维护时，顺序是这样的：

# 1. 标记为不可调度：新 Pod 不再上来，已经在跑的不动
kubectl cordon "$NODE"
kubectl get nodes          # STATUS 变成 Ready,SchedulingDisabled

# 2. 驱逐节点上的 Pod（Deployment 管的会被调度到别的节点）
kubectl drain "$NODE" --ignore-daemonsets --delete-emptydir-data

# 3. 维护完成后恢复可调度
kubectl uncordon "$NODE"

--ignore-daemonsets 是必须的：DaemonSet 的 Pod 本来就是要跑在每个节点上的，drain 无法驱逐它们，不加这个参数会直接报错退出。--delete-emptydir-data 是明确承认「这些用 emptyDir 的 Pod 数据会丢」。

动手练习：在单节点集群里验证#

NODE=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')
kubectl label node "$NODE" disktype=ssd --overwrite

kubectl taint nodes "$NODE" dedicated=kube101:NoSchedule
kubectl run tainted-test --image=nginx:1.27        # 期望 Pending
kubectl taint nodes "$NODE" dedicated=kube101:NoSchedule-

kubectl cordon "$NODE"
kubectl run cordon-test --image=nginx:1.27         # 期望 Pending
kubectl uncordon "$NODE"
kubectl get pod cordon-test -o wide                # 期望很快变成 Running

kubectl delete pod web-pinned web-preferred tainted-test cordon-test --ignore-not-found
kubectl label node "$NODE" disktype-
kubectl taint nodes "$NODE" dedicated=kube101:NoSchedule-

Pod 一直 Pending 的排查顺序#

Pending 只说明「还没被调度成功」，原因有五六类。按下面的顺序逐条排除，每条都对应上面「过滤」阶段的一个检查点：

kubectl describe pod web-pinned | grep -A5 Events    # 先读 0/N nodes are available 那一行
kubectl describe node "$NODE" | grep -E 'Taints|Allocatable|Allocated'
kubectl get pvc -n demo
kubectl describe resourcequota -n demo

1. 先读那句话：0/N nodes are available: ...，冒号后面按节点列出原因，通常直接写出 Insufficient cpu、had untolerated taint、didn't match Pod's node affinity 或 didn't find available persistent volumes，对应下面某一条。
2. 资源不足：Insufficient cpu / Insufficient memory。看 describe node 的 Allocated resources，要么调小 requests，要么加节点。
3. 亲和性与选择器：didn't match Pod's node affinity/selector、didn't match pod affinity rules。用 kubectl get node "$NODE" --show-labels 核对标签，注意 nodeSelectorTerms 是「或」、matchExpressions 是「与」。
4. 污点没容忍：had untolerated taint {node-role.kubernetes.io/control-plane: NoSchedule}，给 Pod 补对应的 tolerations。
5. PVC 没绑上：pod has unbound immediate PersistentVolumeClaims，kubectl get pvc -n demo 的 STATUS 不是 Bound。细节见 第 10 章 存储卷与 PV/PVC。
6. 配额不够：exceeded quota，或 LimitRange 强制了最小 requests 而你没写。kubectl describe resourcequota -n demo 看用量。
7. 节点不可调度：node(s) were unschedulable（被 cordon 过的节点）、node(s) had volume node affinity conflict、节点 NotReady。用 kubectl get nodes 确认状态。

常见坑与速查表#

自测题#

小结#

• 调度器的工作流是过滤 → 打分 → 绑定；没有节点通过过滤时 Pod 停在 Pending，原因写在 describe 的 Events 里。
• nodeSelector 表达「等于」，nodeAffinity 表达更复杂的规则；required 是硬约束（会 Pending），preferred 是软约束。
• podAffinity / podAntiAffinity 按 topologyKey 决定 Pod 之间靠近还是分开，副本分散优先用 preferred 或 topologySpreadConstraints。
• 污点写在节点上、容忍写在 Pod 上；NoSchedule 只挡新 Pod，NoExecute 还会驱逐已有 Pod。
• 维护节点的标准动作是 cordon → drain → uncordon，drain 记得带上 --ignore-daemonsets。

相关章节：第 11 章 探针与资源管理 讲 requests 怎么影响调度，第 15 章 排障手册 把这里的事件分析放进了完整的排查流程。

练习#

1. 给节点打上 gpu=true 标签，写一个 required 的 nodeAffinity，再故意把值改成 false，观察 Events 里调度器的原话。
2. 用 topologySpreadConstraints 把一个 3 副本的 Deployment 分散到多节点（如果没有多节点，先用 maxSkew: 1 + ScheduleAnyway 跑通语法）。
3. 思考题：如果一台节点磁盘写满被 kubelet 打上 node.kubernetes.io/disk-pressure:NoSchedule，已经在上面跑的 Pod 会被赶走吗？为什么？

调度只决定 Pod 落在哪，落下去之后出问题就是另一套功夫了。下一章我们整理一份排障手册，把「先看什么、再看什么」固定成流程。