1. 章节承接与亲和性定位
回顾上一小节内容：调度器核心分为预选（筛选满足最低要求的节点）、优选（从多个候选节点中选择最优节点绑定）两个阶段，上一小节通过自定义shell脚本演示了基础调度器的随机匹配逻辑，该脚本仅用于特性演示，不具备生产环境可用性。
调度灵活性的核心要求是「听劝」：管理员可以主动操纵、修改默认调度结果，亲和性就是实现调度灵活性、表达调度偏好的核心特性之一。
2. 亲和性基础概念：软策略与硬策略
亲和性本质是调度偏好特性，分为两类核心策略，通过生活化案例区分：
- 软策略（Soft Policy）：属于偏好型要求，满足时优先执行，不满足时不影响正常调度，类比「希望和小红坐一起，做不到就算了」。
- 硬策略（Hard Policy）：属于强制型要求，必须满足才能完成调度，不满足时Pod会长期处于Pending状态，类比「考试成绩必须及格才能拿毕业证，达不到就不行」。
3. 节点亲和性（Node Affinity）
节点亲和性是针对节点标签的调度偏好配置，配置入口为Pod的spec下的nodeAffinity字段，分为两类子策略：
3.1 软策略：preferredDuringSchedulingIgnoredDuringExecution
- 配置逻辑：通过运算符匹配节点标签，支持
In（标签值在列表中）、NotIn（不在列表中）、Exists（标签存在）、DoesNotExist（标签不存在）、Gt（大于）、Lt（小于）等运算符。 - 核心特性：仅作为调度偏好，不强制要求匹配，不满足时按默认调度规则执行。
3.2 硬策略：requiredDuringSchedulingIgnoredDuringExecution
- 配置逻辑：同样通过运算符匹配节点标签，要求必须匹配到符合条件的节点才能完成调度。
- 核心特性：强制要求，无匹配节点时Pod无法完成调度，长期处于Pending状态。
3.3 节点标签查看方式
通过命令kubectl get node --show-labels查看所有节点的标签，常见自动生成的标签包括：
- 节点架构标签（如
beta.kubernetes.io/arch=amd64） - 操作系统标签（如
kubernetes.io/os=linux） - 主机名标签（如
kubernetes.io/hostname=k8s-node02，建议集群部署时自定义节点名，避免默认值导致标签重复） - 调度器高可用标识标签
- 标签的value可以省略，省略时值为空，但不建议这么做。
3.4 节点亲和性实验验证
实验1：软策略无匹配节点时的表现
- 准备场景：所有节点均无目标标签（如
domain=薪享宏福），创建带节点亲和性软策略的Pod，要求匹配domain=薪享宏福标签。 - 结果：Pod正常调度，不会处于Pending状态，验证软策略非强制。
- 资源差异影响：若节点资源存在差异（如node02剩余资源远大于node01），Pod会优先调度到资源更好的节点，不会因为软策略未匹配就随机切换节点；若节点资源接近，才会出现随机调度结果。
- 人为加压验证：为node02创建Deployment强制运行10个副本，人为提高node02的资源利用率，再次创建带软策略的Pod，会调度到资源更充裕的node01，进一步验证软策略「有最好，没有就算了」的特性。
实验2：软策略有匹配节点时的表现
- 为node02添加目标标签
domain=薪享宏福，此时node02满足软策略的匹配条件。 - 再次创建带软策略的Pod，哪怕node02已经加压，Pod仍会优先调度到node02，验证软策略满足条件时优先生效。
实验3：硬策略无匹配节点时的表现
- 配置硬策略，要求节点必须有
disktype=SSD标签，当前节点均无该标签。 - 创建Pod后，Pod长期处于Pending状态，不会完成调度，验证硬策略的强制特性。
实验4：硬策略有匹配节点时的表现
- 为node01添加
disktype=SSD标签，为node02添加disktype=HDD标签。 - 修改Pod硬策略匹配
disktype=SSD，再次创建Pod，Pod会调度到node01；哪怕人为给node01加压，Pod仍会强制调度到node01，不会切换到node02，验证硬策略的强制约束力。
3.5 节点亲和性适用场景
- 软策略：非强依赖的偏好场景，如「优先调度到SSD节点，没有的话机械硬盘也可以」，「优先调度到同可用区节点，不行的话跨可用区也可以」。
- 硬策略：强依赖约束场景，如「必须调度到SSD节点」，「必须调度到指定可用区节点」，「禁止调度到特定节点」。
4. Pod亲和性与Pod反亲和性
Pod亲和性/反亲和性的逻辑与节点亲和性完全一致，核心区别是匹配对象从节点标签变为Pod标签，配置入口为Pod的spec下的affinity字段下的podAffinity（亲和，要求同拓扑域）和podAntiAffinity（反亲和，要求不同拓扑域），同样支持软硬两种策略。
4.1 核心概念：拓扑域（topologyKey）
Pod之间的「在一起/不在一起」需要明确范围标准，拓扑域就是用来定义这个标准的，通过节点标签实现，常见拓扑域包括：
kubernetes.io/hostname：同一个节点topology.kubernetes.io/zone：同一个可用区topology.kubernetes.io/region：同一个地域- 自定义机架、机房等标签
类比场景：判断两个人是否「在一起」，标准可以是同一个城市、同一个小区、同一栋楼，拓扑域就是明确这个判断标准。
4.2 软策略权重配置
当存在多个满足亲和条件的Pod时，通过weight字段指定优先级，权重越高越优先，例如同时希望和pod-1、pod-2同拓扑域，给pod-1的亲和权重设为10，pod-2设为5，则优先选择和pod-1同拓扑域。类比场景：小明希望和小红、小兰坐一起，只能选一个时优先选权重更高的对象。
4.3 匹配逻辑说明
Pod亲和性的匹配逻辑为：先找到符合标签匹配的Pod，再判断当前待调度Pod和目标Pod是否处于同一个拓扑域，满足条件则符合亲和要求；反亲和性则要求不在同一个拓扑域。
| 调度策略 | 匹配标签 | 操作符 | 拓扑域支持 | 调度目标 |
|---|---|---|---|---|
| nodeAffinity | 主机 | In, NotIn, Exists, DoesNotExist, Gt, Lt | 否 | 指定主机 |
| podAffinity | POD | In, NotIn, Exists, DoesNotExist | 是 | POD与指定POD同一拓扑域 |
| podAntiAffinity | POD | In, NotIn, Exists, DoesNotExist | 是 | POD与指定POD不在同一拓扑域 |
AI 总结
本小节重点讲解了Kubernetes调度器亲和性的核心概念与实验验证：亲和性是实现调度灵活性、表达管理员调度偏好的核心特性，分为软硬两类策略，软策略为偏好型不强制，硬策略为强制型不满足则无法调度；进一步区分了节点亲和性（匹配节点标签）、Pod亲和性/反亲和性（匹配Pod标签）三类配置，其中Pod亲和性需要通过拓扑域明确「在一起」的范围标准。通过多组实验验证了不同策略的生效逻辑与适用场景，为后续自定义调度规则、实现业务亲和性部署提供了基础。