这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Scheduler 根据资源、亲和性、拓扑约束、污点和优先级为 Pod 选择节点。理解调度过程才能解释 Pending 和负载不均。
17.1 调度流程
过滤可用节点
-> 节点打分
-> 选择最高分节点
-> 绑定 Pod
17.2 资源请求
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: "1"
memory: 2Gi
调度使用 requests，运行时限制使用 limits。没有 requests 的 Pod 可能挤占节点资源并影响调度判断。
17.3 Node Selector 与 Affinity
节点选择：
nodeSelector:
disktype: ssd
节点亲和：
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-type
operator: In
values: [worker]
Pod 反亲和：
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: order
topologyKey: kubernetes.io/hostname
17.4 Taint 与 Toleration
添加污点：
kubectl taint nodes node-01 dedicated=database:NoSchedule
容忍：
tolerations:
- key: dedicated
operator: Equal
value: database
effect: NoSchedule
常见 effect：
| Effect | 含义 |
|---|---|
| NoSchedule | 不调度新 Pod |
| PreferNoSchedule | 尽量不调度 |
| NoExecute | 驱逐不容忍的 Pod |
17.5 Priority 与 Preemption
高优先级 Pod 资源不足时可能驱逐低优先级 Pod。必须谨慎设置，避免关键系统组件被业务任务抢占。
17.6 Pod Topology Spread
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: order
用于控制节点、机架或可用区分布。
17.7 Pending 排查
kubectl describe pod app
常见原因：
- CPU / 内存不足；
- GPU 或设备不可用；
- 节点选择器无匹配；
- 污点未容忍；
- PVC 拓扑等待；
- 端口冲突；
- 反亲和过严。
本章小结
调度由 requests、亲和性、污点容忍、拓扑约束和优先级共同决定。生产应为所有容器设置资源请求，并用拓扑分布降低故障域集中风险。
思考题
- requests 和 limits 在调度中的作用有何不同？
- 什么场景使用 Pod 反亲和？
- 污点和容忍解决什么问题？
- maxSkew 如何影响分布？
- Pending 应如何定位？