企业官网建设流程全解析

一个集群里同时跑着在线接口、离线任务和 AI 训练，如果你的调度策略只有资源请求和限制，那早晚会踩到几个典型的坑：GPU 训练任务被调度到了没有 GPU 的节点上、一个频繁抖动的大任务把整台机器 Load 拉满、同一批 Pod 全挤在同一台机器上导致单点故障。节点选择器、污点与容忍、亲和性与反亲和性，这三套机制就是解决这些问题的工具箱。这篇内容不打算停留在官网文档层面，我会从实际调度架构设计的角度，把三者的原理、用法、组合方式和排查方法完整串一遍，适合已经对 Kubernetes 基础概念有认知、正在优化集群调度的同学参考。

1. 先把调度器的工作流程看透

1.1 调度周期：过滤、打分、绑定

kube-scheduler 是控制平面里负责“分配节点”的组件。它不负责运行 Pod，只负责决定 Pod 跑到哪台节点上。每个新创建的 Pod 都会进入调度队列，调度器会按照顺序执行三个阶段：

• 过滤（Filtering）：把所有节点过一遍，剔除不满足硬性条件的节点。资源不足的、端口冲突的、有调度相关限制的，都在这一步被淘汰。
• 打分（Scoring）：对剩下的节点按优先级排序，给每个节点算出一个 0 到 100 的分数，综合了资源余量、亲和性规则、Pod 分布情况等因素。
• 绑定（Binding）：选出分数最高的节点，把 Pod 和节点的绑定关系写入 etcd。这个动作速度很快，大部分场景在秒级完成。

这里需要特别理解一点：过滤阶段是“一票否决”性质的，只要有一条规则不满足就出局。而打分阶段只是“择优录取”，分数低的节点仍然可能被选中，只是概率低。明白了这一点，你就能理解为什么 nodeSelector 这类硬约束依然有它的价值，也能理解为什么亲和性的 preferred 语义只是“尽量”而不是“一定”。

1.2 三套机制的定位有何不同

简单归纳三者的定位：

• nodeSelector 是“白名单思维”：节点必须带某个 label，不带就不调度。
• 污点与容忍是“反向排斥”：节点主动声明“我不欢迎某些 Pod”，只有明确容忍的 Pod 才能过来。
• 亲和性/反亲和性是“精细导航”：既能表达硬约束，也能表达偏好，还能控制 Pod 之间的聚合与打散。

用一个生活化的类比来记：nodeSelector 像公司门禁，只有工牌上印了指定部门的人才能进；污点像门上贴了“施工中，闲人免进”，施工队出示通行证才能进；亲和性像人力主管综合考虑技能、项目位置、团队配合度来安排工位，既要能干，又要干得顺。

这三者不是互斥关系，实际架构中经常叠加使用。我的经验是：nodeSelector 适合做粗粒度的强制约束，污点用来做节点级的隔离声明，亲和性负责把“能调度”升级成“调度得好”。如果你只依赖其中一种，很多场景会绕不过去。

2. 节点选择器：简单直接，但别把它当万能

2.1 先说节点标签

nodeSelector 的工作原理完全建立在节点标签上。给节点打标签用：

kubectl label nodes node-01 disktype=ssd gpu=true

查看所有节点的标签：

kubectl get nodes --show-labels

如果你想管理大量节点的标签，建议制定一套命名规范。我见过不少团队随意打 label，比如有的写gpu=true，有的写has_gpu=yes，后面写调度规则时就非常痛苦。规范一点的方案是使用带语义前缀的标签，比如：

• node-type: general/node-type: compute
• disk-type: ssd/disk-type: hdd
• gpu.vendor: nvidia
• service-tier: core/service-tier: best-effort

前缀不一定要用域名格式，但至少要保证同一个含义在整集群里只有一个写法。另外注意，节点标签是可以随时修改的，改了之后已经调度上去的 Pod 不受影响，这一点和亲和性里 “IgnoredDuringExecution” 的语义一脉相承。

2.2 nodeSelector 的配置方式

在 Pod 规格里加一个 selector 字段：

apiVersion: v1 kind: Pod metadata: name: demo-pod spec: nodeSelector: node-type: compute gpu.vendor: nvidia containers: - name: app image: registry.example.com/demo:v1

调度器在过滤阶段会检查节点是否同时满足这两个标签条件。注意多个条件是 AND 关系，只要有一个不满足，节点就会被排除。

这里要区分几个容易混淆的概念：nodeSelector 是经典调度字段，nodeName 是直接指定节点名，nodeAffinity 是更灵活的约束。nodeName 会完全绕过调度器，直接把 Pod 绑到某台机器上，一般不推荐在业务负载里使用，因为很容易造成资源分配失衡，节点挂了 Pod 也不会自动补到别处。

2.3 局限性是真实存在的

nodeSelector 有三个明显的短板。

第一，它只能表达“等于”，不能表达“不等于”“存在”“不存在”这类条件。你想表达“调度到不是 GPU 的节点上”，用 nodeSelector 很难做到，只能反过来打标签再用排除思维绕。

第二，它是纯硬约束，没有“尽量”的概念。一旦所有节点都不满足标签条件，Pod 就一直 Pending，不会有降级策略。这在节点标签写错或者节点维护时尤其容易暴雷。

第三，它管不了 Pod 之间的关系。你没法通过 nodeSelector 表达“这两个 Pod 不要放在同一台机器上”。

那么什么时候用 nodeSelector？我个人的判断标准是：如果你只需要一两个简单的条件，且这些条件在节点生命周期内基本不变，用 nodeSelector 就够了。比如把批处理任务固定到高内存节点池，把测试环境 Pod 固定到测试专用节点。一旦条件复杂起来，或者需要表达偏好和 Pod 间关系，就该上亲和性了。

3. 污点与容忍：节点主动发出“排斥声明”

3.1 污点的三个组成部分

给节点打污点的命令：

kubectl taint nodes node-01 dedicated=general:NoSchedule

污点由 key、value、effect 三部分组成。effect 决定排斥的强度，有三种取值：

key 和 value 的匹配规则：value 可以为空，但 key 必须存在。effect 是必须匹配的，也就是说一个容忍只对同一种 effect 生效。

有一个很多新手忽略的点：NoSchedule 只管“未来的调度”，对已经在节点上运行的 Pod 不做任何处理。只有 NoExecute 才具备驱逐能力。所以如果你想给节点做维护、把上面跑的 Pod 全部赶走，应该用 NoExecute 而不是 NoSchedule。反过来，如果你只是想新 Pod 别过来、跑着的继续跑，NoSchedule 才是合适的。

3.2 容忍的写法与匹配细节

在 Pod 里声明容忍：

tolerations: - key: dedicated operator: Exists effect: NoSchedule

operator 有两种语义：

• Exists：只要 key 存在就匹配，不关心 value。写key: dedicated时默认 operator 就是 Exists。
• Equal：key 和 value 都需要一致，必须显式写出 value。

什么时候用 Exists、什么时候用 Equal？如果节点上有dedicated=general:NoSchedule和dedicated=storage:NoSchedule两种污点，你想统一容忍所有 “dedicated” 污点，就用 Exists。如果你想只容忍 general 这一种 value，就得用 Equal。

还有一种特殊写法：容忍所有污点。key 为空、operator 为 Exists 且不指定 effect，会匹配集群里所有污点。系统组件 Pod 经常这样写：

tolerations: - operator: Exists

这个写法要慎用。它能容忍一切污点，包括各种系统级故障污点，意味着 Pod 可能被调度到任何节点上，即使是正在故障维护的节点。对于业务工作负载，我建议尽量精确匹配到 key 和 effect。

3.3 实战场景：从独占节点到物理隔离

污点最常见的用途是给节点做专用化。比如 GPU 节点。如果集群里只有少量机器有 GPU，而大部分业务 Pod 并不需要 GPU，你不希望每个 Pod 都被调度到 GPU 机器上浪费资源。做法是给 GPU 节点打上污点：

kubectl taint nodes node-gpu-01 gpu=true:NoSchedule

然后只有需要 GPU 的工作负载声明对应容忍。这样一个简单的组合，就完成了“普通 Pod 不占 GPU 节点”的隔离。如果再加一层，让 GPU 节点之间用反亲和性打散，可以避免两个大任务挤在同一台机器上抢显存，AI 训练场景里这几乎是标配。

另外一个很实用的场景是节点维护。当你要对一批节点做内核升级或重启时，可以先用 kubectl cordon 冻结调度，再优雅驱逐 Pod。但如果你希望“新 Pod 不要来，老 Pod 自动走”，用 NoExecute 污点更直接：

kubectl taint nodes node-01 maintenance=true:NoExecute

已运行的 Pod 会在默认宽限期后被杀掉。kubelet 对 not-ready、unreachable 这类系统污点有自己的容忍逻辑，一般会给 Pod 留 300 秒的驱逐宽限，但自定义的 NoExecute 污点默认不设置宽限期，除非你在容忍里写了 tolerationSeconds。

控制平面节点上的默认污点也值得留意。node-role.kubernetes.io/control-plane这类污点默认拒绝普通业务 Pod，保证控制面组件独占资源。如果你发现业务 Pod 进不了某个节点，先用命令看看节点上有哪些污点再说，不要第一反应就觉得是网络或镜像问题。

3.4 tolerationSeconds 与系统污点的边界

NoExecute 容忍可以带上时长：

tolerations: - key: maintenance operator: Exists effect: NoExecute tolerationSeconds: 300

表示 Pod 可以容忍这个污点 300 秒。超过时间如果污点还在，Pod 就会被驱逐。这个机制很实用，比如节点要做 5 分钟内的快速重启，你希望 Pod 坚持一下别马上被杀，就可以设置一个合理的 tolerationSeconds。

集群里其实已经存在一些系统污点，例如：

• node.kubernetes.io/not-ready
• node.kubernetes.io/unreachable
• node.kubernetes.io/memory-pressure
• node.kubernetes.io/disk-pressure
• node.kubernetes.io/network-unavailable

这些污点是 kubelet 根据节点状态自动打上的，用于故障隔离。正常情况下业务 Pod 不应该容忍它们，否则就会出现在故障节点上仍然正常运行、但实际已经失联的假象。只有像网络插件这类基础设施组件才需要容忍网络类污点。

4. 亲和性：从被动筛选到主动布局

4.1 nodeAffinity 的两种语义

nodeAffinity 是 nodeSelector 的升级版，它支持更丰富的条件运算符，并且区分“硬约束”和“偏好”两种语义。

先看一个例子：

affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-type operator: In values: - compute - gpu preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 preference: matchExpressions: - key: zone operator: In values: - zone-a

required 段是硬约束，必须满足，否则不调度，相当于加强版 nodeSelector。preferred 段是软偏好，调度器会尽量满足并给更高分，但不满足也能调度。

字段名里那段很长的 “IgnoredDuringExecution” 是什么意思？它表示：调度完成后，如果节点的标签发生了变化，已经运行的 Pod 不会因此被强制迁移。这个设计是刻意的，节点标签变化是常态，如果每次标签变更都把 Pod 驱逐掉，集群会非常不稳定。所以记住一个结论：这两段都只影响“未来调度”，不影响“已运行的 Pod”。

nodeAffinity 支持多种运算符：

用 NotIn 和 DoesNotExist 能表达 nodeSelector 表达不了的“反选”逻辑，比如“调度到非 GPU 节点”。还有一个容易忽略的细节：nodeSelectorTerms 之间是 OR 关系，而每个 term 内部的 matchExpressions 之间是 AND 关系。写多个 term 时要清楚这层逻辑，别把本该是“或”的条件误写成叠加的“与”。

4.2 weight 的权重机制与使用尺度

preferred 段可以写多个偏好，每个都有 weight，取值范围 1 到 100。调度器会把所有满足条件的偏好权重加起来，加到节点总分里。权重越大的偏好对最终选择影响越大。

需要注意，权重不是概率。一个 weight=100 的偏好不代表有百分百概率被选中，它只是给满足条件的节点额外加分。最终结果还受资源充足度、Pod 分布约束等其他打分项影响。所以在设计时要有心理准备：preferred 只能保证“大概率”，不能保证“一定”。

根据我的经验，weight 控制在 10 到 80 之间比较合理。如果到处都用 100，等于把其他打分维度全部淹没，反而不利于集群整体资源均衡。比如你既希望 Pod 倾向于 zone-a，又不希望 zone-b 完全空转，那给 zone-a 设个 60 的权重就够了，调度器会在资源分布和偏好之间做折中。

4.3 podAffinity 与 podAntiAffinity：管理 Pod 之间的关系

nodeAffinity 管的是“Pod 与节点的关系”，而 podAffinity 管的是“Pod 与 Pod 的关系”。这在多实例部署里非常关键。

podAffinity 的典型场景：两个服务之间网络交互非常频繁，希望调度到同一个可用区，降低跨可用区流量和延迟。podAntiAffinity 的典型场景：同一应用的多个副本不要落在同一台机器或同一个可用区，避免单点故障。

看一个反亲和性的例子：

affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: nginx topologyKey: kubernetes.io/hostname

这段配置的含义是：调度这个 Pod 时，不能选择那些“已经运行着 app=nginx 的 Pod”的节点。topologyKey 指定了判断范围，这里是主机名维度，也就是同一台 Node 上不允许有两个相同 app 标签的 Pod。

topologyKey 是 podAffinity 的核心概念，它决定在哪个维度上判断 Pod 关系。常用取值有：

• kubernetes.io/hostname：同一节点维度
• topology.kubernetes.io/zone：同一可用区维度
• topology.kubernetes.io/region：同一地域维度

topologyKey 不能为空，而且它必须对每个节点都有值。如果某些节点缺少这个 label，调度器会直接认为约束不满足，这在 required 语义下会导致 Pod 无法调度。这是排查时必须检查的点。

说句实在话，podAntiAffinity 是非常消耗调度性能的配置。它的计算复杂度随集群规模和 Pod 数量增长明显，一条 required 的反亲和规则，调度器要扫描所有节点上的所有 Pod 来判断标签匹配关系。在大集群里，如果每个 Deployment 都配一条 required podAntiAffinity，调度时延会明显上升。我的建议是：能用 preferred 语义就尽量用 preferred，只在故障域容灾这种必须有保证的场景才用 required。

5. 架构级组合实践：调度策略的完整设计

5.1 先聊一个典型混合集群场景

假设这样一个集群：里面有 30 个节点，包含三种类型：通用型节点（跑在线 API 和普通微服务）、计算型节点（大内存、跑批处理和 AI 训练）、存储型节点（挂了大容量本地盘，跑数据库类负载）。

业务上也分三类：在线服务要求稳定，多副本，不能互相挤在同一台机器；批处理任务对时延不敏感，但对资源消耗大；AI 训练任务需要 GPU，且多个训练任务不能共用一台机器，否则显存和算力都会争抢。

如果不对调度做任何控制，会发生什么？批处理任务可能把在线服务的节点 CPU 打满，AI 任务可能被调度到没有 GPU 的节点上一直 Pending，或者三个在线服务副本全落在一台机器上，机器一挂服务就全挂了。这些事故我在实际环境里不止一次见过，根因基本都不是资源不够，而是调度策略没设计。

5.2 分层的调度设计原则

我的设计思路可以概括成一句话：先隔离、再优化、最后控制分布。

第一层是节点池隔离，用污点配合强制标签共同完成。给每种节点类型打上标签和污点：

• 通用节点：node-type=general，污点dedicated=general:NoSchedule
• 计算节点：node-type=compute，污点dedicated=compute:NoSchedule
• 存储节点：node-type=storage，污点dedicated=storage:NoExecute

同时制定一个规则：所有业务 Pod 必须显式声明 nodeSelector 和对应的 toleration。没有声明的 Pod 默认不带容忍，自然不会靠近专用节点，只能落到默认节点池。这个规则的执行力度取决于团队规范，如果担心有人漏写，可以在准入控制层做校验，也可以在节点上只保留默认节点池给“无声明”的 Pod 使用，让错误自然暴露成 Pending。

第二层是亲和性优化。在线服务加 podAntiAffinity，用 kubernetes.io/hostname 做反亲和，保证多副本分布在不同节点；如果有跨可用区需求，再用 topology.kubernetes.io/zone 做一层更粗粒度的反亲和，保证故障域级别的容灾。

AI 训练任务加 nodeAffinity，required 阶段要求 node-type 是 compute，preferred 阶段偏向有 GPU 标签的节点，再用 podAntiAffinity 保证同一个训练任务的不同 worker 不落在同一台机器上。

第三层是分布约束。如果集群启用了 topologySpreadConstraints，可以按 zone 或 hostname 维度让 Pod 尽量均匀分布。它和 podAntiAffinity 有重叠但互补：反亲和管“不能和相同标签的 Pod 在一起”，拓扑分布约束管“整个集群维度上尽量均匀”。两个都配的时候要留意叠加效果，避免规则互相打架导致调度困难。

5.3 一个组合 YAML 实例

下面这个 Deployment 综合了 nodeSelector、toleration、nodeAffinity、podAntiAffinity 四层控制：

apiVersion: apps/v1 kind: Deployment metadata: name: online-api labels: app: online-api spec: replicas: 3 selector: matchLabels: app: online-api template: metadata: labels: app: online-api spec: nodeSelector: node-type: general tolerations: - key: dedicated operator: Equal value: general effect: NoSchedule affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 60 preference: matchExpressions: - key: zone operator: In values: - zone-a podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 podAffinityTerm: labelSelector: matchLabels: app: online-api topologyKey: kubernetes.io/hostname containers: - name: api image: registry.example.com/online-api:v1 resources: requests: cpu: "1" memory: 1Gi limits: cpu: "2" memory: 2Gi

这段配置的含义是：Pod 只能去带 node-type=general 标签的节点（nodeSelector），且该节点要有对应的 dedicated=general 污点（toleration），调度时尽量偏向 zone-a 节点（preferred nodeAffinity），多个副本尽量分散到不同节点（preferred podAntiAffinity）。注意这里反亲和用的是 preferred，在大规模多副本场景下这是务实的选择，既保证了多数情况下的打散效果，又不会因为节点不足导致副本无法扩容。

5.4 变更上线与验证节奏

调度策略配置错了，后果往往不是立刻暴露，而是表现为 Pod 长时间 Pending 或者扩容失败。所以上线节奏要稳。

我的习惯是先做一个“调度策略预演”：先把目标节点的标签打好，但先不打污点；用临时 Pod 验证标签是否符合预期；确认无误后再打污点，并且先在一两个节点上试，观察现有 Pod 有没有异常；最后再正式发布带有 toleration 和 affinity 的业务配置。

每一步都要配合 kubectl 观察。比如你想知道一批 Pod 到底被调度到哪里：

kubectl get pods -o wide -n production kubectl get nodes -l node-type=general kubectl describe pod online-api-xxxxx -n production | tail -30

污点的撤销也很简单，命令末尾加个减号去掉即可：

kubectl taint nodes node-01 dedicated=general:NoSchedule-

如果发现某条亲和性规则是误加的，直接改 YAML 再 apply 就行，已经运行的 Pod 不会被驱逐，这正好利用了 IgnoredDuringExecution 的特性。不过要提醒一句：调度器不会对已运行的 Pod 重新调度，所以改了规则后，需要滚动重启工作负载才能让新规则生效。

6. 常见问题与排查技巧实录

6.1 Pod 一直 Pending，先看事件

排障第一动作永远是看事件：

kubectl describe pod <pod-name> -n <namespace>

重点看最后一段 Events，调度器会把拒绝原因明确写在里面。常见事件消息和对应原因，我整理过一张速查表：

这些信息是调度器直接给出的，比任何猜测都准确。我见过不少同学拿到 Pending 的 Pod 第一反应就是看镜像是不是拉不下来，其实事件里明明写着是调度失败。先看事件这一步能省掉大量时间。

6.2 污点与容忍匹配不上的隐蔽原因

事件提示 did not tolerate，但你明明写了 toleration，那就要逐项核对三件事。

第一，key 是否完全一致。节点污点的 key 和 Pod 容忍的 key，任何一个字符不对都匹配不上。比如节点上是dedicated=general，你写成了deticated，直接失效。

第二，effect 是否一致。节点污点是 NoSchedule，Pod 容忍只写了 NoExecute，两者不匹配。我在排查时见过有人以为写了 effect 就能容忍所有污点，这是误解。

第三，operator 的语义。如果写 operator: Equal，必须同时提供 value 且严格一致。如果写 operator: Exists，不需要写 value，但 key 必须存在。

还有一个容易忽略的点：同一个 key 不同 value 可以打多个污点，Pod 需要逐一容忍，漏一个都不行。用这个命令能完整看到节点上的所有污点：

kubectl get nodes node-01 -o json | jq '.spec.taints'

6.3 亲和性上的几个隐蔽坑

亲和性配置有几个坑，我踩过也帮人排查过。

第一个是 required 语义下节点缺少 topologyKey 对应的标签。比如反亲和用了 topology.kubernetes.io/zone，但某些节点没有这个标签，调度器会认为这些节点永远不满足条件，导致 Pod 无法调度。解决方法是提前统一节点标签，或者改用 kubernetes.io/hostname 这种每个节点都有的标准标签。

第二个是 labelSelector 匹配范围过大。podAntiAffinity 的 labelSelector 会在整个命名空间或集群范围匹配 Pod（取决于是否写了 namespace 字段），如果 matchLabels 写得太宽，很多不相关的 Pod 也会被纳入反亲和范围，结果就是没有任何节点满足条件。建议 matchLabels 指向应用自己的精确标签，range 尽量收窄。

第三个是 weight 的取值范围。weight 只能是 1 到 100 的整数，写 0 或超过 100 会在 apply 时直接报校验错误。这种错误倒不会造成线上事故，但卡在部署流水线里也挺耽误时间。

第四个是 YAML 嵌套缩进问题。affinity 结构嵌套层数多，缩进错一级就很难被发现。配置复杂时我会先用kubectl apply --dry-run=server -f deploy.yaml让集群做一次服务端校验，很多语法问题会在这一步暴露，而不是等到 Pod 创建后才查。

6.4 一套完整的排障命令组合

把排障流程收敛成一套固定的命令组合，能极大提高效率：

# 1. 看 Pod 状态和所在节点 kubectl get pod <pod> -n <ns> -o wide # 2. 看事件，重点是最后一段 kubectl describe pod <pod> -n <ns> | tail -40 # 3. 看节点标签和污点 kubectl get node <node> --show-labels -o wide kubectl get node <node> -o json | jq '.spec.taints' # 4. 查看当前节点上已运行 Pod 的分布情况 kubectl get pods -n <ns> -o wide --sort-by=.spec.nodeName # 5. 服务端校验配置 kubectl apply --dry-run=server -f deploy.yaml

这套流程执行下来，大部分调度问题都能定位到具体环节。剩下的少部分属于集群资源碎片化或自定义调度器干预，那就需要往资源水位和调度器日志方向继续排查了。

最后分享一点个人体会。调度策略设计最忌讳的是“一次性想得很全，配置堆得很多”。我见过最复杂的配置里同时塞了 nodeSelector、两个 required 亲和、三个 preferred 亲和、还有 topologySpreadConstraints，结果集群规模稍微变化就调度失败，排起来非常痛苦。好的调度架构应该是分层的：每层只解决一个问题，每层都有明确目的，并且每层都留了可观测的路径。先保证隔离和稳定性，再逐步加优化规则。节点标签和污点的命名规范要像对待 API 设计一样严格，因为你后面会在几十个 YAML 文件里反复引用它们。把基础打扎实，Kubernetes 调度系统带给你的就不是麻烦，而是实实在在的稳定性和资源效率。