3. 节点选择器（nodeSelector）：用法、标签匹配规则与局限性
节点选择器是 Kubernetes 调度中最简单、最直接的节点约束机制。它通过 Pod 规约中的 nodeSelector 字段声明一组键值对，调度器仅将 Pod 分配给标签完全匹配这些键值对的节点。本节从用法、匹配规则和局限性三个维度展开，帮助你在实际集群中正确使用这一基础调度策略。
3.1 nodeSelector 的用法
在 Pod 的 YAML 定义中，spec.nodeSelector 是一个 map[string]string 类型的字段。调度器在调度该 Pod 时，会过滤出所有标签包含指定键值对的节点，然后从剩余节点中选择一个运行 Pod。
关键行为：nodeSelector 是“硬约束”（hard constraint），如果集群中没有节点满足标签条件，Pod 将一直处于 Pending 状态，不会自动降级到其他节点。
基本使用步骤：
- 为节点打标签：
kubectl label nodes node01 disktype=ssd - 在 Pod 定义中引用该标签：
apiVersion: v1
kind: Pod
metadata:
name: nginx-ssd
spec:
nodeSelector:
disktype: ssd
containers:
- name: nginx
image: nginx:1.25调度器会将此 Pod 分配到带有 disktype=ssd 标签的节点上。如果集群中有多个节点都带有该标签，调度器会在这些节点之间按默认策略（如资源均衡）进一步选择。
3.2 标签匹配规则
nodeSelector 的匹配规则非常严格，理解这些规则是避免调度失败的前提。
| 规则维度 | 说明 | 示例 |
|---|---|---|
| 完全匹配 | 节点必须包含 Pod 中声明的所有键值对，且值必须完全一致 | Pod 声明 disktype: ssd，节点标签 disktype=ssd 匹配；disktype=SSD 不匹配 |
| 多条件 AND 逻辑 | nodeSelector 中多个键值对之间是“与”关系，节点必须同时满足所有条件 | Pod 声明 disktype: ssd 和 region: us-east，节点必须同时有这两个标签 |
| 节点可有多余标签 | 节点可以拥有 Pod 未声明的其他标签，不影响匹配 | 节点有 disktype=ssd 和 gpu=true，Pod 只要求 disktype=ssd，仍可调度 |
| 空值不匹配 | 节点上标签的值为空字符串时，与 Pod 中声明的非空值不匹配 | 节点标签 disktype=""，Pod 要求 disktype: ssd，不匹配 |
| 不存在的键不匹配 | 节点上完全不存在该键时，直接过滤掉该节点 | 节点没有 disktype 标签，Pod 要求 disktype: ssd，不匹配 |
实践建议：为节点打标签时，建议使用统一的命名规范（如
node-role.kubernetes.io/ 前缀或自定义前缀），避免因大小写、空格等细微差异导致调度失败。
3.3 局限性分析
nodeSelector 虽然简单易用，但在复杂调度场景中存在明显不足。下图展示了 nodeSelector 在调度决策中的位置及其能力边界。
局限性详细说明：
- 表达能力单一：nodeSelector 只支持键值对的“等于”匹配，无法表达“节点不在某个区域”“节点拥有 GPU 但不一定是特定型号”等复杂条件。
- 逻辑组合受限：多个条件之间只有 AND 关系。例如无法实现“节点在 us-east 区域 或 拥有 SSD 磁盘”的调度需求。
- 动态调度能力缺失：nodeSelector 是静态标签匹配，无法感知节点的实时资源使用率、负载情况或自定义指标。
- 无运行时重调度：节点标签在 Pod 运行期间发生变化时，已经运行的 Pod 不会自动迁移。例如将节点标签从
disktype=ssd改为disktype=hdd，已在该节点上运行的 Pod 不会自动离开。
常见陷阱：当 nodeSelector 条件无法满足时，Pod 会无限期 Pending。使用
kubectl describe pod <pod-name> 查看事件时，会看到 0/3 nodes are available: 3 node(s) didn't match node selector。此时需要检查节点标签是否正确，或考虑使用更灵活的节点亲和性（NodeAffinity）。
3.4 nodeSelector 与节点亲和性的对比
Kubernetes 在 nodeSelector 基础上提供了更强大的节点亲和性（NodeAffinity）机制。下表对比两者的核心差异，帮助你根据场景选择合适的调度策略。
| 对比维度 | nodeSelector | 节点亲和性（NodeAffinity） |
|---|---|---|
| 匹配操作符 | 仅支持 =（等于） |
支持 In、NotIn、Exists、DoesNotExist、Gt、Lt |
| 逻辑组合 | 仅 AND | 支持 AND（requiredDuringScheduling）和 OR（matchExpressions 内多个值） |
| 软约束支持 | 不支持（仅硬约束） | 支持 preferredDuringSchedulingIgnoredDuringExecution（软约束） |
| 运行时重调度 | 不支持 | IgnoredDuringExecution 语义：调度后不重调度 |
| 配置复杂度 | 低（一行 map） | 中（嵌套 matchExpressions） |
| 适用场景 | 简单、固定的节点分类（如按硬件类型） | 复杂条件、多区域、需要软偏好或排除特定节点 |
迁移建议：如果当前使用 nodeSelector 且遇到上述局限性，建议逐步迁移到节点亲和性。迁移过程可以保持兼容：在同一个 Pod 中同时使用 nodeSelector 和 nodeAffinity，调度器会同时满足两者的条件（AND 关系）。