2025，每天10分钟，跟我学K8S（二十六）- 对象属性 - 打标和nodeSelector

        一个K8S集群一般的情况下会有多台服务器，例如master和多台node，我在生产环境中一般会将ETCD和api server等运行在master节点上，而业务服务的pod则运行在node服务器上面，那如何实现这种分配？常用的有两种思路，打标/nodeSelector 和 亲和性选择。在 Kubernetes 中，​标签(Labels)/nodeSelector​ 和 ​亲和性（Affinity）​ 是资源调度的核心机制，用于实现智能 Pod 分布和高可用性设计。

        

标签（Labels）

​核心作用

• ​多维分类：为 Node、Pod、Namespace 等资源添加 key=value 标签，实现细粒度分类。
• ​筛选逻辑：通过 nodeSelector、podAffinity 等规则匹配标签，控制资源调度。

​标签设计最佳实践

标签类别	推荐键名示例	用途说明
​环境	env=production	区分生产/测试/开发环境
​业务类型	app=frontend	区分微服务类型（前端/后端）
​区域/可用区	region=us-west-1	跨区域部署策略
​硬件特性	gpu=nvidia	GPU 资源标识
​多租户	team=finance	隔离不同团队的资源

节点选择器（nodeSelector）​

核心作用

• ​标签匹配：通过节点标签（Label）控制 Pod 的调度目标，例如将需要 GPU 的 Pod 调度到标记为 gpu=true 的节点。
• ​资源优化：将计算密集型任务调度到高性能节点，存储密集型任务调度到高容量磁盘节点

举例配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-label
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app 
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:        # 节点选择器
        env: prod  # 选择包含这个键值对的node
      containers:
      - name: nginx-label
        image: m.daocloud.io/docker.io/nginx

通过kubectl get node --show-labels可以查看node的标签

运行上面的yaml文件，由于里面指定了template.spec.nodeSelector.matchLabels的标签选择(env: prod)，所有理论上创建的pod都应该分配到node01节点上面,也可以通过结果进行验证。

上面的案例是针对node节点进行打标，然后进行选择，那是否可以针对在运行的pod进行一样的操作。答案是可以的。也就是我们下一章讲解的亲和性（Affinity）​ 和 ​反亲和性（Anti-Affinity）。