为什么Kubernetes的nodeSelector采用键值对形式而非单一标识符？

nodeSelector基于Kubernetes统一的标签体系设计为键值对形式，核心考量如下：

• 维度隔离，避免命名冲突
  集群的节点属性往往分属多个不同维度：磁盘类型、可用区、CPU架构、操作系统、GPU型号等等。如果采用单一标识符的标签设计，不同维度的标签很容易出现命名冲突，比如ssd既可能表示节点挂载SSD磁盘，也可能被某类业务自定义为特殊调度标记。用键值对可以通过键明确划分属性维度，比如disktype=ssd、zone=cn-shanghai、arch=arm64，不同维度的属性天然隔离，不会互相干扰。
• 兼容更灵活的调度匹配逻辑
  键值对结构天然支持同一属性下的多值匹配、范围匹配等扩展逻辑，除了基础的nodeSelector精确匹配外，后续衍生的nodeAffinity调度能力可以直接基于该结构实现in/notIn/exists等复杂匹配规则：比如要调度到磁盘类型为SSD或NVMe的节点，只需要配置disktype in [ssd, nvme]即可，若用单一标识符则需要编写多条匹配规则，逻辑复杂度大幅提升。
• 复用Kubernetes统一的标签体系能力
  键值对标签是Kubernetes所有资源的通用设计，Pod、Service、Deployment等资源的标签选择器都采用该结构，nodeSelector直接复用这套成熟体系，不需要单独开发一套单标签的特殊逻辑，整个集群的标签管理、匹配检索能力可以全链路通用，大幅降低系统的维护复杂度。
• 包容性强，兼容单一标识符的使用场景
  键值对设计完全可以覆盖你提到的单一标识符需求：只需要将值设为固定的true即可，比如你可以执行kubectl label nodes node.xyz ssdDisk=true，随后在nodeSelector中配置ssdDisk: "true"就能实现和单标识符完全一致的效果，反过来单一标识符的设计无法覆盖键值对的复杂场景。

内容的提问来源于stack exchange，提问作者Manish Khandelwal