在多租户、多业务线共用的生产级 Kubernetes 大集群中，计算节点的异构化与分级管理是非常普遍的架构常态。为了满足不同工作负载的苛刻要求，基础设施团队往往会采购一批昂贵的专用物理机，例如搭载了 NVIDIA A100/H100 的 GPU 训练节点、挂载了数十 TB 本地 NVMe 固态盘的低延迟数据库节点，或者专门留给金融级核心交易组件的高频计算节点。
然而，很多刚接触 Kubernetes 的团队经常踩入这样一个“资源被抢占”的深坑：工程师通过 nodeSelector 或 nodeAffinity 将 GPU 深度学习 Pod 绑定到了指定的 GPU 节点上。本以为万事大吉，但几天后大促演练，普通前端业务由于突发扩容且默认计算节点资源紧张，Kubernetes 默认调度器（kube-scheduler）顺理成章地将大批普适性 Web 服务 Pod 调度到了这些昂贵的 GPU 机器上，不仅耗尽了基础 CPU 与内存资源，还直接导致合法的训练任务因宿主机资源不足而处于 Pending 状态。
要实现物理层面的“节点独占与防挤占”，仅靠节点亲和性是远远不够的。必须结合 污点（Taints）与容忍度（Tolerations） 构建严密的“双向排斥与准入过滤闭环”。本文将深入拆解其底层机制与企业级实战配置。
1. 为什么 NodeAffinity 无法实现真正的“独占”？
要理解防挤占的本质，首先要看清 Kubernetes 调度体系中“吸引”与“排斥”的哲学差异：
+————————————————————————-+
| NodeAffinity / NodeSelector: "吸引法则" |
| – 表达的是 Pod 对 Node 的偏好或强制选择。 |
| – 语义: "我 (Pod A) 想要去具有 gpu=true 标签的节点上运行"。 |
| – 致命漏洞: 它无法约束别人！普通 Pod B 没有任何亲和性偏好，调度器依然 |
| 可以将其放置在有剩余空间的 GPU 节点上。 |
+————————————————————————-+
vs
+————————————————————————-+
| Taints & Tolerations: "排斥法则" |
| – 表达的是 Node 对 Pod 的主动态度与拒绝。 |
| – 语义: "我 (Node X) 身染污点，除非你拥有特许通行证(Toleration)，否则 |
| 无论资源多宽裕，都绝不允许踏上这台机器一步！" |
+————————————————————————-+
单纯使用亲和性是单向的“单相思”，普通应用因为没有限制，依然会“随遇而安”地蚕食昂贵节点。要做到绝对的物理隔离与防挤占，必须执行**“双重门禁设计模式（Two-Way Fence Pattern）”**：
2. 污点的三类 Effect 深度剖析
通过 kubectl taint nodes <node-name> key=value:effect 可以为节点打标。Effect 决定了调度器对非容忍 Pod 的处置力度：
3. 生产级“双向排斥”高阶实战架构
我们以一个高价值的 AI 推理/微调节点池（含 8 张 A100 GPU 显卡）为例，落地完整的防挤占与独占调度方案。
3.1 步骤一：为物理节点赋予污点与业务标签
首先，对两台 GPU 专用宿主机 node-gpu-prod-01 和 node-gpu-prod-02 进行物理标记：
# 1. 注入排他性污点 (任何未携带专用容忍凭证的 Pod 一律不可调度)
kubectl taint nodes node-gpu-prod-01 dedicated=ai-inference:NoSchedule
kubectl taint nodes node-gpu-prod-02 dedicated=ai-inference:NoSchedule
# 2. 注入节点业务标签 (用于正向亲和性匹配)
kubectl label nodes node-gpu-prod-01 hardware/accelerator=nvidia-a100 node-role.kubernetes.io/ai-inference=true
kubectl label nodes node-gpu-prod-02 hardware/accelerator=nvidia-a100 node-role.kubernetes.io/ai-inference=true
此时，公共微服务（如 Java Web 服务、Redis 等）即使发生雪崩扩容，调度器在初筛选（Filtering）阶段就会直接把这两台机器剪枝过滤，专用池绝对安全。
3.2 步骤二：编写专用工作负载的“双向锁定”部署文件
AI 推理服务的 Deployment 必须同时配置 tolerations（获取登机特许凭证）与 nodeAffinity（禁止去往廉价节点）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: llm-inference-service
namespace: ai-platform
labels:
app: llm-inference
spec:
replicas: 4
selector:
matchLabels:
app: llm-inference
template:
metadata:
labels:
app: llm-inference
spec:
# 门禁 1: 声明容忍度，准许调度到被打上 dedicated=ai-inference 污点的节点
tolerations:
– key: "dedicated"
operator: "Equal"
value: "ai-inference"
effect: "NoSchedule"
# 门禁 2: 声明强亲和性，强制只能落在具备特定 GPU 标签的节点上
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
– matchExpressions:
– key: "hardware/accelerator"
operator: "In"
values:
– "nvidia-a100"
– key: "node-role.kubernetes.io/ai-inference"
operator: "In"
values:
– "true"
containers:
– name: vllm-worker
image: internal-registry.corp/ai/vllm:0.5.4
resources:
limits:
nvidia.com/gpu: 1
memory: 32Gi
cpu: "8"
requests:
nvidia.com/gpu: 1
memory: 16Gi
cpu: "4"
ports:
– containerPort: 8000
4. NoExecute 与 tolerationSeconds：节点演练与平滑下线
在生产中，当某个节点出现硬件故障预警（如 SMART 检测到磁盘即将损坏，或内存出现多次 ECC 错误纠偏），运维人员需要将该节点腾退维护。若直接使用 kubectl drain，可能会瞬间强杀无保护的 Pod。
此时可以利用 NoExecute 污点配合 tolerationSeconds，给特定 Pod 预留处理完当前长连接的宽限期：
# Pod 模版中的优雅驱逐容忍度
tolerations:
– key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 180 # 当节点网络不可达时，宽限 180 秒再驱逐，避免网络瞬时抖动造成剧烈漂移
– key: "maintenance"
operator: "Equal"
value: "draining"
effect: "NoExecute"
tolerationSeconds: 300 # 节点计划维护时，允许该关键任务继续运行最多 5 分钟以完成当前批处理
5. 企业级防线：通过准入控制器（Webhook）自动化注入
在大型工程团队中，要求所有算法开发人员手写复杂的 tolerations 和 affinity 是极易出错的。更致命的是，如果有业务方私自复制了 tolerations 字段，就会突破专用池的防线。
生产环境标准解法是通过 Kyverno 或自研的 MutatingAdmissionWebhook 进行集中托管：
6. 核心经验与避坑清单
通过将 Taints 的排他性与 NodeAffinity 的聚焦性有机融合，配合准入 Webhook 的刚性治理，团队才能真正从混沌的混合调度深水区走向井然有序的资源确定性隔离。
