20250720-4-Kubernetes 调度-指定节点调度：nodeSelector&nodeAffinity笔记

一、指定节点调度



1. nodeSelector



1）例题：确保Pod分配到具有SSD硬盘的节点



• NodeSelector基本使用
  • 
  • 命令格式：kubectl label nodes <node-name> <label-key>=<label-value>
  • YAML配置：
  • 实现原理：通过给节点打标签并在Pod配置中添加nodeSelector字段，实现Pod定向调度到特定节点
• 标签操作实践
  • 
  • 添加标签：
    • 方法：使用kubectl label node k8s-node1 disktype=ssd命令
    • 验证：通过kubectl get nodes --show-labels查看标签
  • 删除标签：
    • 方法：在key后加横杠，如kubectl label node k8s-node1 disktype-
    • 注意：这是固定语法，必须严格遵循格式
• NodeSelector特性
  • 核心特性：
    • 完全匹配：必须严格匹配节点标签才会调度
    • 硬性约束：若无匹配节点，Pod将保持Pending状态
  • 应用场景：
    • 专用节点：按业务线分组管理节点
    • 特殊硬件：配备SSD、GPU等特殊硬件的节点
• 调度失败处理
  • 
  • 错误分析：
    • 当出现0/3 nodes are available提示时，表示没有匹配的节点
    • 可能原因：节点标签不匹配或节点存在taint
  • 解决方法：
    • 检查节点标签是否正确：kubectl get nodes --show-labels
    • 确保Pod配置的nodeSelector与节点标签完全一致
• 与NodeAffinity对比
  • 
  • 主要区别：
    • 匹配逻辑：NodeSelector仅支持完全相等，NodeAffinity支持In、NotIn等操作符
    • 策略类型：NodeAffinity支持软策略(preferred)和硬策略(required)
  • 选择建议：
    • 简单场景使用NodeSelector
    • 复杂调度需求使用NodeAffinity

2. nodeAffinity



• 标签操作语法: 格式为 kubectl label nodes <node-name> <label-key>=<label-value>
• nodeSelector示例:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  nodeSelector:
    disktype: "ssd"
  containers:
  - name: nginx
    image: nginx:1.19

1）基本概念

• 与nodeSelector的关系: nodeAffinity功能类似于nodeSelector，都是根据节点上的标签来约束Pod可以调度到哪些节点
• 核心优势:
  • 逻辑组合更丰富: 不只是字符串完全相等匹配，支持多种操作符：In、NotIn、Exists、DoesNotExist、Gt、Lt
  • 策略更灵活: 分为软策略(preferred)和硬策略(required)

2）功能特性

• 硬策略(required):
  • 必须满足指定条件才会调度
  • 配置字段为requiredDuringSchedulingIgnoredDuringExecution
  • 示例中要求节点必须具有disktype=ssd标签
• 软策略(preferred):
  • 尝试满足但不强制要求
  • 配置字段为preferredDuringSchedulingIgnoredDuringExecution
  • 示例中优先选择具有disktype=ssd2标签的节点
  • 可以设置权重(weight)来调整优先级
• 常用操作符:
  • In: 节点必须包含指定标签值
  • NotIn: 节点不能包含指定标签值
  • Exists: 节点必须存在指定标签键
  • DoesNotExist: 节点不能存在指定标签键
  • Gt/Lt: 数值比较(不常用)

3）使用场景

• 硬策略适用场景: 当Pod必须运行在特定节点时使用，如需要特殊硬件或软件的Pod
• 软策略适用场景: 当Pod可以运行在任何节点但某些节点更优时使用，如优先选择SSD节点但HDD节点也可接受
• 与nodeSelector对比:
  • nodeSelector是硬性匹配，没有标签的节点会导致调度失败
  • nodeAffinity提供更灵活的匹配条件和策略选择

二、知识小结

知识点	核心内容	关键特性/易混淆点	应用场景
Node Selector	通过节点标签完全匹配调度Pod	硬性约束：必须完全匹配标签否则调度失败 操作简单：仅支持键值对完全匹配	专用节点分配 硬件特定调度(如GPU/SSD节点)
Node Affinity	提供更丰富的调度逻辑规则	软硬策略：requiredDuringScheduling(硬)和preferredDuringScheduling(软) 高级匹配：支持in/notIn/Exists等操作符	优先但不强制调度 多条件组合调度
标签管理	kubectl label命令操作节点标签	增删语法： kubectl label nodes <node-name> key=value(添加) kubectl label nodes <node-name> key-(删除)	节点分类标记 动态环境维护
调度验证	describe pod查看调度结果	关键字段： Node: 显示实际调度节点 Events: 显示调度失败原因	调度问题排查 策略效果验证
典型应用场景	硬件差异化集群调度	SSD节点：IO密集型应用 GPU节点：AI计算任务 普通节点：无特殊需求负载	资源优化配置 性能敏感型应用部署