偏好策略带权重参与打分
节点亲和性分硬约束（required）与偏好（preferred）两类。偏好条目带 weight，取值 1 到 100，多个偏好会累加进节点得分，得分高的节点优先被选中；只有硬约束不满足时 Pod 才会一直无法调度，偏好不满足只是分数偏低。因此业务上真正不可让步的约束不要写成偏好，容量与就近规划也不能建立在「偏好一定会被满足」这个前提上。
基本信息
| 适用平台 | 各版本的节点亲和性配置 |
|---|---|
| 关键字段 | weight（1 到 100）与 preference.matchExpressions |
| 打分方式 | 多个偏好权重累加，与其他调度因素共同决定落点 |
| 硬约束对应 | requiredDuringSchedulingIgnoredDuringExecution |
| 语义提醒 | 偏好不满足不会阻塞调度，只在同等条件下影响选择 |
典型使用场景
- 机型优选：优先使用较新机型，但允许落在其他节点
- 就近取值：优先选择同机房的节点降低访问延迟
- 成本优化：优先使用价格较低的节点池
- 灰度偏好：优先使用已预热缓存的节点，加快启动
- 风险分散：优先避开采纳中的故障节点，但不阻断调度
多偏好叠加
多偏好叠加
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: node-type
operator: In
values: [gpu] # 更希望落在 GPU 节点
- weight: 50
preference:
matchExpressions:
- key: disktype
operator: In
values: [ssd] # 其次希望使用 SSD 节点看调度结果
看调度结果
kubectl get pod web-x -o wide # 最终落在哪个节点
kubectl describe pod web-x | grep -i -A3 affinity
kubectl get nodes -L node-type -L disktype # 核对标签是否齐全
kubectl get events --field-selector involvedObject.name=web-x --sort-by=.lastTimestamp | tail写法与行为
| 写法 | 行为 | 适用 |
|---|---|---|
| required | 不满足就不调度 | 必须落在特定节点上的硬要求 |
| preferred 加权重 | 参与打分，尽量满足 | 优先但不强求 |
| 多个偏好并存 | 权重累加后共同决定 | 综合权衡落点 |
| 调度后节点标签变化 | 已运行的 Pod 不迁移 | 标签治理要考虑存量 Pod |
偏好表达的是「尽量」：节点扩容缩容、其他 Pod 占用资源、标签调整都可能让偏好失效，容量规划别建立在这类条件上。
多个偏好下的权重是相对值，只有在同一次调度打分中比较才有意义；把权重当成绝对优先级去推导落点，结论往往与事实不符。