在Kubernetes体系内，Pod构成了工作负载调度的核心单元。当创建工作负载时，调度系统会自动为Pod分配合理的位置，例如将它们分散到资源充裕的节点上。尽管调度器的默认设置足以应对许多基础需求，但在特定场景下，用户可能希望对Pod的部署位置进行更为精细的控制。为此，Kubernetes提供了在工作负载定义中自定义调度策略的功能。具体示例如下：
将前端与后端应用部署在同一位置，有助于缩减延迟，因为它们可以共享物理资源。
某些应用需部署在特定节点上，以确保关键应用始终运行在最优硬件或配置上。
不同应用部署在不同节点上，有助于实现应用隔离，防止问题扩散。
Kubernetes中Pod调度策略
节点选择（nodeSelector）：这是最简单的调度方式，通过节点标签选择目标节点，仅将Pod调度到拥有特定标签的节点。参考指引：设置负载的节点选择器（nodeSelector）
节点亲和性（nodeAffinity）：节点亲和性不仅具备nodeSelector的功能，而且更为强大。它允许您根据节点标签使用标签选择器筛选亲和节点，支持必须满足和尽量满足的规则。参考指引：设置节点亲和调度（nodeAffinity）
工作负载亲和性/反亲和性（podAffinity/podAntiAffinity）：根据工作负载标签，使用标签选择器筛选亲和/反亲和的Pod，并将新工作负载调度/不调度至目标Pod所在节点（或节点组），同样支持必须满足和尽量满足的规则。参考指引：设置工作负载亲和/反亲和调度（podAffinity/podAntiAffinity）
注意
- 若同时指定nodeSelector和nodeAffinity，则两者条件均需满足，Pod才能被调度到候选节点。
在大规模集群中，由于工作负载亲和性和反亲和性需要额外计算时间，可能会显著降低调度速度，因此不建议在包含数百个节点的集群中使用节点亲和性调度策略。
亲和性规则
基于节点亲和性或工作负载亲和性/反亲和性的调度策略还可以设定硬约束（必须满足）和软约束（尽量满足），以适应更复杂的调度场景。
必须满足
requiredDuringSchedulingIgnoredDuringExecution：硬约束，调度器仅在规则满足时执行调度。
尽量满足
preferredDuringSchedulingIgnoredDuringExecution：软约束，调度器会尝试寻找满足规则的目标对象，即使找不到匹配对象，也会调度Pod。在使用时，可为每个实例设置weight字段（1-100），权重越高，调度优先级越高。
参考指引：设置节点亲和调度（nodeAffinity）、设置工作负载亲和/反亲和调度（podAffinity/podAntiAffinity）
注意
在亲和规则中，requiredDuringScheduling或preferredDuringScheduling表示调度时需强制满足或尽量满足定义的标签规则；IgnoredDuringExecution表示若节点标签在Pod调度后变更，Pod将继续运行而不会重新调度，但kubelet重启时会重新校验节点亲和性规则，并可能将Pod调度至其他节点。
标签选择器
在创建调度策略时，需使用标签选择器的逻辑运算符筛选标签值，确定亲和/反亲和对象。
key：标签键名，满足条件的对象需包含此键名的标签，且标签值需满足标签值列表（values字段）和逻辑运算符的关系。
operator：使用逻辑运算符确定标签值的筛选规则，运算符包括：
In：亲和/反亲和对象的标签在标签值列表中。
NotIn：亲和/反亲和对象的标签不在标签值列表中。
Exists：亲和/反亲和对象存在指定标签名（无需填写标签值列表）。
DoesNotExist：亲和/反亲和对象不存在指定标签名（无需填写标签值列表）。
Gt（仅节点亲和性）：调度节点的标签值大于列表值（字符串比较）。
Lt（仅节点亲和性）：调度节点的标签值小于列表值（字符串比较）。
values：标签值的列表。
示例：对象需包含键名为topology.kubernetes.io/zone的标签，且标签值为az1或az2
matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- az1
- az2
