Linux nfd 的 node-feature 标签与调度器 predicate 匹配实践

node feature discovery（nfd）的label生成规则是：基于feature-labels.yaml中labelname字段定义键名，硬件特性经映射转换（如avx512f→cpu-avx512f，gpu型号转pci vendor:device id），下划线自动转连字符，值默认为”true”，少数支持显式valuefrom输出字符串。

node-feature-discovery 的 label 生成规则是什么

nfd 不会直接把硬件信息原样塞进 Node label，而是按预定义的 feature-labels 映射规则转换。比如 CPU flag avx512f 对应 label feature.node.kubernetes.io/cpu-avx512f，而 GPU 型号 A100-SXM4-40GB 会被清洗成 feature.node.kubernetes.io/pci-10de_20f1_present（vendor:device ID 形式）。

• label 名由 feature-labels.yaml 中的 labelName 字段决定，不是自由命名
• 值默认是 "true"（存在性 label），少数字段如 cpu-cpuid 可输出具体字符串值，但需显式启用 valueFrom
• label 键名里带下划线（_）会被自动转为连字符（-），例如 cpu_avx512f → cpu-avx512f

如何让调度器真正用上 nfd 的 label

Kubernetes 默认不检查自定义 label，必须在 Pod spec 中显式声明 nodeSelector 或 nodeAffinity，且 label key 必须完全匹配（包括命名空间前缀）。常见错误是漏掉 feature.node.kubernetes.io/ 前缀，或大小写错位。

• nodeSelector 最简：只支持精确匹配，适合“有/无”类需求

  nodeSelector:<br>  feature.node.kubernetes.io/cpu-avx512f: "true"

• nodeAffinity 更灵活，可组合多个条件、设置 soft/hard 约束
• 调度器不会自动 fallback：如果所有节点都不满足，Pod 就卡在 Pending，不会降级运行

predicate 匹配失败时怎么快速定位

最常见现象是 Pod 卡在 Pending，kubectl describe pod 里看到类似 0/3 nodes are available: 3 node(s) didn't match Pod's node affinity/selector.，但没说具体哪条不匹配。

• 先确认 label 确实存在于目标 Node：kubectl get node <name> -o wide</name> → kubectl get node <name> -o jsonpath='{.metadata.labels}' | jq</name>
• 检查 label 是否被 nfd-worker 覆盖：它默认每 60 秒重刷一次，若手动加过 label，会被清掉
• 注意 label 值类型：nfd 输出的都是字符串，哪怕看起来像布尔值（"true" ≠ true），nodeSelector 中必须用双引号包住

和 taint/toleration 混用时的优先级陷阱

nfd label 本身不触发污点（taint），但实践中常配合使用——比如给带 GPU 的节点打 label 同时加 gpu=true:NoSchedule。这时调度逻辑分两层：先过 predicate（label 匹配），再过 taint check（toleration 匹配）。

• 顺序不可逆：label 不匹配，根本进不了 taint 判断阶段
• 容易忽略的是 toleration 的 effect 必须与 taint 完全一致，NoSchedule ≠ NoExecute
• 如果用了 nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution，但 toleration 写错了，Pod 仍会 pending，错误提示却只提 affinity

nfd 的 label 是静态快照，不反映实时状态（比如 GPU 进程占满后 label 不会变），真要约束资源可用性，得靠 extended Resource 或 device plugin 配合。