工作负载调度策略概述
在Kubernetes中，工作负载调度的基本单位是Pod。创建工作负载时，调度器会自动对工作负载中的Pod进行合理分配，例如将Pod分散到资源充足的节点上。
虽然调度器的默认行为已经能够满足许多基本需求，但在一些特定场景下，用户可能需要更精细的控制Pod的部署位置。为了实现这一点，Kubernetes允许用户在工作负载定义中配置调度策略。例如：
- 将前端应用和后端应用部署在一起，有助于减少延迟，因为这两种类型的Pod可以共享相同的物理资源。
- 某类应用部署到某些特定的节点，确保关键应用总是运行在最优的硬件或配置上。
- 不同应用部署到不同的节点，有助于隔离应用，防止一个应用的问题影响到其他应用。
您可以使用以下方式来选择Kubernetes对Pod的调度策略：
|
调度策略 |
YAML字段定义 |
说明 |
参考文档 |
|---|---|---|---|
|
节点选择 |
nodeSelector |
最简单的调度形式，通过节点所具有的标签选择希望调度的目标节点，Kubernetes只会将Pod调度到拥有指定标签的节点上。 |
|
|
节点亲和 |
nodeAffinity |
节点亲和可以实现nodeSelector的能力，但其表达能力更强，您可以根据节点上的标签，使用标签选择器来筛选需要亲和的节点，支持必须满足和尽量满足的亲和性规则。
说明：
如果同时指定nodeSelector和nodeAffinity，则两者必须都要满足，才能将Pod调度到候选节点上。 |
|
|
工作负载亲和/反亲和 |
podAffinity/podAntiAffinity |
您可以根据工作负载标签，使用标签选择器来筛选需要亲和/反亲和的Pod，并将新建的工作负载调度/不调度至目标Pod所在的节点（或节点组），同时支持必须满足和尽量满足的亲和性规则。
说明：
工作负载亲和性和反亲和性需要一定的计算时间，因此在大规模集群中会显著降低调度的速度。在包含数百个节点的集群中，不建议使用这类设置。 |
亲和性规则
基于节点亲和或工作负载亲和/反亲和的调度策略还可以设置必须满足的硬约束和尽量满足的软约束，以满足更复杂的调度情况。
|
规则类型 |
YAML字段定义 |
说明 |
配置示例 |
|---|---|---|---|
|
必须满足 |
requiredDuringSchedulingIgnoredDuringExecution |
硬约束，即调度器只有在规则被满足的时候才能执行调度。 |
|
|
尽量满足 |
preferredDuringSchedulingIgnoredDuringExecution |
软约束，即调度器会尝试寻找满足对应规则的目标对象。即使找不到匹配的目标，调度器仍然会调度该Pod。 在使用尽量满足的亲和性类型时，您可以为每个实例设置weight字段，其取值范围是1到100。 权重越高，调度的优先级越高。 |
在上述亲和规则中，YAML字段前半段requiredDuringScheduling或preferredDuringScheduling表示在调度时需要强制满足（require）或尽量满足（prefer）定义的标签规则。而后半段IgnoredDuringExecution表示如果节点标签在Kubernetes调度Pod后发生了变更，Pod仍将继续运行不会重新调度。但是如果该节点上的kubelet重启，kubelet会重新对节点亲和性规则进行校验，Pod仍会被调度至其他节点。
标签选择器
在创建调度策略时，您需要使用标签选择器的逻辑运算符来筛选标签值，最终确定需要亲和/反亲和的对象。
|
参数 |
说明 |
YAML示例 |
|---|---|---|
|
key |
标签键名，满足筛选条件的对象需包含该键名的标签，且标签的取值满足标签值列表（values字段）和逻辑运算符的运算关系。 |
以下示例中，满足筛选条件的对象需包含键名为topology.kubernetes.io/zone的标签，并且该标签的取值为az1或az2。 matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- az1
- az2 |
|
operator |
您可以使用逻辑运算符来确定标签值的筛选规则，所有逻辑运算符如下：
|
|
|
values |
标签值的列表。 |
