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 配合。
