K8s Pod 调度策略完全指南

Kubernetes 调度器（kube-scheduler）通过预选（Filtering）和优选（Scoring）决定 Pod 落在哪个节点。 默认行为在生产环境往往不够用。本文覆盖六大调度机制，附完整 YAML 配置和生产案例。

调度流程概览

调度策略的生效优先级从高到低：

1. nodeName（最高优先级，直接指定节点名，跳过调度器）
2. Taints / Tolerations（节点污点过滤）
3. nodeSelector（简单标签匹配）
4. nodeAffinity（灵活的节点亲和性）
5. podAffinity / podAntiAffinity（Pod 间亲和/反亲和）
6. topologySpreadConstraints（拓扑分散约束）
7. 资源请求（节点剩余资源是否满足 requests）

六大调度机制

1. nodeSelector — 最简单的调度约束

通过标签键值对匹配节点，硬约束，无匹配节点则 Pod 永久 Pending。

spec:
  nodeSelector:
    disktype: ssd

适用场景: 简单场景，如"数据库必须跑在 SSD 节点"。复杂场景建议用 nodeAffinity。

2. nodeAffinity — 灵活的节点亲和性

支持多种操作符和软/硬约束结合：

• 硬约束: requiredDuringSchedulingIgnoredDuringExecution — 不满足不调度
• 软约束: preferredDuringSchedulingIgnoredDuringExecution — 尽量满足，权重 1-100

⚠️ IgnoredDuringExecution 表示 Pod 已运行后，即使节点标签变了也不驱逐。Kubernetes 计划实现 RequiredDuringExecution 但尚未可用。

逻辑关系: 多个 nodeSelectorTerms 之间是 OR，同一 nodeSelectorTerm 中的多个 matchExpressions 是 AND。

3. podAffinity / podAntiAffinity — Pod 间亲和与反亲和

控制 Pod 之间的调度关系：

• podAffinity: 让 Pod 和指定 Pod 部署在同一拓扑域（降低网络延迟）
• podAntiAffinity: 让 Pod 远离指定 Pod（分散风险）

topologyKey 定义拓扑域：

• kubernetes.io/hostname → 以节点为域
• topology.kubernetes.io/zone → 以可用区为域

⚠️ 性能警告: podAffinity 计算复杂度为 O(N²)，N 是集群 Pod 数量。5000+ Pod 的大集群中调度延迟可从 5ms 升至 200ms。优先用 topologySpreadConstraints 替代。

4. Taints & Tolerations — 节点专用化

从节点角度排斥 Pod，实现节点专用化（GPU 节点、数据库节点等）：

常用内置污点:

• node.kubernetes.io/not-ready:NoExecute
• node.kubernetes.io/unreachable:NoExecute
• node-role.kubernetes.io/control-plane:NoSchedule

tolerationSeconds: 容忍 NoExecute 污点的最长等待时间（到期后被驱逐）。

5. topologySpreadConstraints — 拓扑分散（推荐）

K8s 1.19 GA，比 podAntiAffinity 更精细地控制 Pod 在拓扑域间的分布：

示例: 9 副本 + 3 zone + maxSkew=1 → 每个 zone 恰好 3 个 Pod。

✅ 生产环境跨故障域部署的首选方案。

6. PriorityClass — 优先级与抢占

高优先级 Pod 可抢占低优先级 Pod 的资源：

preemptionPolicy: PreemptLowerPriority  # 可抢占
preemptionPolicy: Never                 # 不抢占（批处理任务推荐）

⚠️ PreemptLowerPriority 会驱逐低优先级 Pod（收到 SIGTERM），确保应用能正确处理优雅关闭。生产环境建议批处理任务设 Never。

生产案例

案例一：MySQL 主从集群调度

• Master：nodeAffinity 锁定 SSD + database 节点，PriorityClass critical-production
• Slave：podAntiAffinity 硬约束分散到不同节点，topologySpreadConstraints 跨 zone
• 结果：Master 固定在 SSD 节点，Slave 分布在 zone-a/b/c 的不同节点

案例二：灰度发布调度

• 灰度节点打标签 canary=true
• 灰度 Deployment 通过 nodeAffinity 锁定灰度节点
• 验证通过后更新稳定版镜像 + 缩容灰度 Deployment

最佳实践

性能优化

1. 能用 topologySpreadConstraints 就不要用 podAntiAffinity（计算复杂度差别巨大）
2. 合理设置 resource requests — 调度器按 requests 决策。设 P95 实际用量，避免过高（节点利用率低）或过低（OOMKill）
3. 使用 Descheduler 重平衡 — 节点扩容/Pod 漂移后自动重新调度

安全加固

1. 限制 nodeName 直接指定 — 通过 OPA/Gatekeeper 策略禁止（跳过所有调度检查）
2. PriorityClass 权限控制 — RBAC 限制高优先级类的使用
3. 节点污点防篡改 — 通过准入 webhook 拦截关键节点 taint 修改

高可用配置

• 核心服务 ≥3 副本 + podAntiAffinity 硬约束 + topologySpreadConstraints 跨 zone
• 使用 PodDisruptionBudget（PDB）限制同时不可用 Pod 数量
• 调度策略配置（PriorityClass、节点标签、污点）纳入 GitOps

排障速查

监控告警

命令速查表

# 节点标签管理
kubectl label node <node> key=value            # 添加标签
kubectl label node <node> key-                 # 删除标签
kubectl get nodes --show-labels                # 查看所有标签

# 污点管理
kubectl taint nodes <node> key=value:NoSchedule    # 添加污点
kubectl taint nodes <node> key=value:NoSchedule-   # 删除污点
kubectl describe node <node> | grep Taints         # 查看污点

# 调度排查
kubectl get events --field-selector reason=FailedScheduling -A
kubectl describe pod <pod> | grep -A 10 Events
kubectl top nodes

# 节点维护
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
kubectl cordon <node>         # 标记不可调度
kubectl uncordon <node>       # 恢复调度

关联页面