场景与目标

集群节点：master（4 核）、node1（16 核）、node2（16 核）。
目标：将一个高 CPU 消耗的工作负载横向扩展到 4 个实例，并通过**节点亲和性（软亲和）**确保 Pod 优先调度到 node1、node2（CPU 更充足）。
已完成：node1/node2 已打标签 cpu-tier=high。

参考：Kubernetes 官方节点亲和文档（支持首选型 preferred、权重 1–100）、Kuboard 亲和性教程（节点亲和的概念与写法）、以及中文教程对软/硬亲和的区分说明。

配置思路（为什么选“软亲和”）

软亲和（preferredDuringSchedulingIgnoredDuringExecution）：调度器会为满足规则的节点打分（可设定权重 1–100），尽量将 Pod 放到匹配节点（cpu-tier=high）；若资源不足，仍可回退到其他节点，避免扩容/滚更卡在 Pending。
与 硬亲和（required…） 相比，软亲和更利于弹性与可用性，减少因“条件太硬”而导致的调度失败。

节点标签（确认）

当前节点标签示例（你已完成）：

# 已有：为 16 核节点打上高 CPU 标签
kubectl label node node1 cpu-tier=high --overwrite=true
kubectl label node node2 cpu-tier=high --overwrite=true

节点亲和是基于节点标签实现的，preferred规则通过标签匹配给节点“加分”。

部署清单中的关键修改（仅节点软亲和）

在 Deployment 的 spec.template.spec 下添加 nodeAffinity（preferred），示例片段如下（可直接粘贴）：

affinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100preference:matchExpressions:- key: cpu-tieroperator: Invalues:- high

weight: 100 表示强烈偏好匹配该表达式的节点；调度器按规则累积分值进行优先选择。

一条命令合并补丁（不改其他字段）

将现有工作负载（以 prod/device 为例）打上节点软亲和，并把副本数扩到 4：

kubectl -n prod patch deploy device --type='merge' -p '
{"spec": {"replicas": 4,"template": {"spec": {"affinity": {"nodeAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight": 100,"preference": {"matchExpressions": [{ "key": "cpu-tier", "operator": "In", "values": ["high"] }]}}]}}}}}
}'

“首选型（preferred）”亲和规则在满足条件的节点上加分，确保优先调度到 node1/node2；当没有可用资源时，调度器仍会将 Pod 放到其它节点，以保障发布成功。

验证与观测

查看分布与所在节点

kubectl -n prod get pod -l k8s.kuboard.cn/name=device -o wide

查看调度事件与亲和匹配

kubectl -n prod describe pod <pod-name> | sed -n '1,120p'

观察 Node:、Events 中的调度决策与亲和性评估信息。

官方文档：节点亲和任务指南、概念详解。

参考资料

Kubernetes 官方文档：Assign Pods to Nodes using Node Affinity（含 preferred/required 与权重说明）。
Kuboard 教程：亲和性与反亲和性（节点亲和的概念与示例）。
中文教程：亲和力软/硬的对比与说明。
CSDN：Kubernetes 进阶之容器组（Pod）（包含资源 requests/limits 的清单说明，可用于配合调度）。