第八章：调度 —— Scheduler 到底怎么选 Node - 现代前后端完全指南：软件城市宇宙

Pod 写出来以后，不是自动飘到天上，它得被放到某台 Node 上。
这个决定由 kube-scheduler 来做。

类比就是舰队调度官：

哪个任务舱该装到哪艘母舰上？

官方给出的核心过程很直白：

text

待调度 Pod
   │
   ▼
先过滤不合格的 Node（feasible nodes）
   │
   ▼
再给合格 Node 打分
   │
   ▼
选分最高的 Node
   │
   ▼
绑定（binding）

它会考虑什么？

资源够不够：CPU、内存、GPU、存储
你有没有 nodeSelector
你有没有 affinity / anti-affinity
Node 上有没有 taint，你的 Pod 有没有 toleration
拓扑分布要不要打散
某些节点是否被预留给特定业务

一个最简单的定向调度例子：

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: city-worker
spec:
  replicas: 2
  selector:
    matchLabels:
      app: city-worker
  template:
    metadata:
      labels:
        app: city-worker
    spec:
      nodeSelector:
        workload: cpu
      containers:
        - name: worker
          image: busybox:1.36
          command: ["sh", "-c", "sleep 3600"]

先给节点打标签：

bash

kubectl label nodes node-a workload=cpu
kubectl get nodes --show-labels

如果你发现 Pod 一直 Pending，第一反应不是骂 Kubernetes，而是查调度条件：

bash

kubectl describe pod <pod-name>

通常原因就这几类：

资源请求太大，没节点装得下
nodeSelector / affinity 太苛刻
被 taint 拦住了
镜像拉取失败
PVC 没绑定好

一句话记住调度：

Scheduler 不是随机分配，而是在“满足约束”前提下做最合适放置。