【Kubernetes】Pod 资源调度之亲和性调度

Pod 资源调度之亲和性调度

1.Node 亲和性调度
- 1.1 Node 硬亲和性
- 1.2 Node 软亲和性
2.Pod 亲和性调度
- 2.1 Pod 硬亲和
- 2.2 Pod 软亲和
- 2.3 Pod 反亲和

Kubernetes 的 默认调度器 以预选、优选、选定机制 完成将每个新的 Pod 资源绑定至为其选出的目标节点上，不过，它只是 Pod 对象的默认调度器，默认情况下调度器考虑的是资源足够，并且负载尽量平均。

在使用中，用户还可以 自定义调度器插件，并在定义 Pod 资源配置清单时通过 spec.schedulerName 指定即可使用，这就是 亲和性调度。

1.Node 亲和性调度

NodeAffinity 意为 Node 节点亲和性的调度策略，是用于替换 NodeSelector 的全新调度策略。

🚀 Affinity：密切关系；喜好

这些规则基于节点上的自定义标签和 Pod 对象上指定的标签选择器进行定义。节点亲和性允许 Pod 对象定义针对一组可以调度于其上的节点的亲和性或反亲和性，不过，它无法具体到某个特定的节点。

例如，将 Pod 调度至有着特殊 CPU 的节点或一个可用区域内的节点之上。

定义节点亲和性规则时有两种类型的节点亲和性规则：硬亲和性 required 和软亲和性 preferred。

硬亲和性 实现的是强制性规则，它是 Pod 调度时必须要满足的规则，而在不存在满足规则的节点时， Pod 对象会被置为 Pending 状态。
而 软亲和性 规则实现的是一种柔性调度限制，它倾向于将 Pod 对象运行于某类特定的节点之上，而调度器也将尽量满足此需求，但在无法满足调度需求时它将退而求其次地选择一个不匹配规则的节点。

定义节点亲和规则的关键点有两个，一是为节点配置合乎需求的标签，另一个是为 Pod 对象定义合理的标签选择器，从而能够基于标签选择出符合期望的目标节点。

不过，如 preferredDuringSchedulingIgnoredDuringExecution 和 requiredDuringSchedulingIgnoredDuringExecution 名字中的后半段符串 IgnoredDuringExecution 隐含的意义所指，在 Pod 资源基于节点亲和性规则调度至某节点之后，节点标签发生了改变而不再符合此节点亲和性规则时，调度器不会将 Pod 对象从此节点上移出，因为，它仅对新建的 Pod 对象生效。节点亲和性模型如图所示：

在这里插入图片描述

1.1 Node 硬亲和性

为 Pod 对象使用 nodeSelector 属性可以基于节点标签匹配的方式将 Pod 对象强制调度至某一类特定的节点之上，不过它仅能基于简单的等值关系定义标签选择器，而 nodeAffinity 中支持使用 matchExpressions 属性构建更为复杂的标签选择机制。例如，下面的配置清单示例中定义的 Pod 对象，其使用节点硬亲和规则定义可将当前 Pod 对象调度至拥有 zone 标签且其值为 foo 的节点之上。

apiVersion: v1
kind: Pod
metadata:
  name: with-required-nodeaffinity
spec:
  affinity:
    nodeAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - {key: zone, operator: In, values: ["foo"]}
  containers:
  - name: nginx
    image: nginx

将上面配置清单中定义的资源创建于集群之中，由其状态信息可知它处于 Pending 阶段，这是由于强制型的节点亲和限制场景中不存在能够满足匹配条件的节点所致：

# kubectl apply -f required-nodeAffinity-pod.yaml 
pod/with-required-nodeaffinity created
# kubectl get pods with-required-nodeaffinity 
NAME                         READY   STATUS    RESTARTS   AGE
with-required-nodeaffinity   0/1     Pending   0          8s

通过 describe 查看对应的 events。

# kubectl describe pods with-required-nodeaffinity
...
Events:
  Type     Reason            Age        From               Message
  ----     ------            ----       ----               -------
  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 3 node(s) didn't match node selector.

规划为各节点设置节点标签，这也是设置节点亲和性的前提之一。

# kubectl label node k8s-node-01 zone=foo
node/k8s-node-01 labeled
# kubectl label node k8s-node-02 zone=foo
node/k8s-node-02 labeled
# kubectl label node k8s-node-03 zone=bar
node/k8s-node-03 labeled

查看调度结果。

# kubectl describe pods with-required-nodeaffinity
...
Events:
  Type     Reason            Age        From                  Message
  ----     ------            ----       ----                  -------
  Warning  FailedScheduling  <unknown>  default-scheduler     0/3 nodes are available: 3 node(s) didn't match node selector.
  Normal   Scheduled         <unknown>  default-scheduler     Successfully assigned default/with-required-nodeaffinity to k8s-node-01

在定义节点亲和性时，requiredDuringSchedulinglgnoredDuringExecution 字段的值是一个对象列表，用于定义节点硬亲和性，它可由一到多个 nodeSelectorTerm 定义的对象组成，彼此间为 “逻辑或” 的关系，进行匹配度检查时，在多个 nodeSelectorTerm 之间只要满足其中之一即可。nodeSelectorTerm 用于定义节点选择器条目，其值为对象列表，它可由一个或多个 matchExpressions 对象定义的匹配规则组成，多个规则彼此之间为 “逻辑与” 的关系，这就意味着某节点的标签需要完全匹配同一个 nodeSelectorTerm 下所有的 matchExpression 对象定义的规则才算成功通过节点选择器条目的检查。而 matchExmpressions 又可由一到多个标签选择器组成，多个标签选择器彼此间为 “逻辑与” 的关系。

下面的资源配置清单示例中定义了调度拥有两个标签选择器的节点挑选条目，两个标签选择器彼此之间为 “逻辑与” 的关系，因此，满足其条件的节点为 node01 和 node03。

apiVersion: v1
kind: Pod
metadata:
  name: with-required-nodeaffinity-2
spec:
  affinity:
    nodeAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - {key: zone, operator: In, values: ["foo", "bar"]}
          - {key: ssd, operator: Exists, values: []}
  containers:
  - name: nginx
    image: nginx

构建标签选择器表达式中支持使用操作符有 In、Notln、Exists、DoesNotExist、Lt 和 Gt 等。

In：label 的值在某个列表中。
NotIn：label 的值不在某个列表中。
Gt：label 的值大于某个值。
Lt：label 的值小于某个值。
Exists：某个 label 存在。
DoesNotExist：某个 label 不存在。

另外，调度器在调度 Pod 资源时，节点亲和性 MatchNodeSelector 仅是其节点预选策略中遵循的预选机制之一，其他配置使用的预选策略依然正常参与节点预选过程。例如将上面资源配置清单示例中定义的 Pod 对象容器修改为如下内容并进行测试。

apiVersion: v1
kind: Pod
metadata:
  name: with-required-nodeaffinity-3
spec:
  affinity:
    nodeAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - {key: zone, operator: In, values: ["foo", "bar"]}
          - {key: ssd, operator: Exists, values: []}
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: 6
        memory: 20Gi

在预选策略 PodFitsResources 根据节点资源可用性进行节点预选的过程中，它会获取给定节点的可分配资源量（资源问题减去已被运行于其上的各 Pod 对象的 requests 属性之和），去除那些无法容纳新 Pod 对象请求的资源量的节点，如果资源不够，同样会调度失败。

由上述操作过程可知，节点硬亲和性实现的功能与节点选择器 nodeSelector 相似，但亲和性支持使用匹配表达式来挑选节点，这一点提供了灵活且强大的选择机制，因此可被理解为新一代的节点选择器。

1.2 Node 软亲和性

节点软亲和性为节点选择机制提供了一种柔性控制逻辑，被调度的 Pod 对象不再是 “必须” 而是 “应该” 放置于某些特定节点之上，当条件不满足时它也能够接受被编排于其他不符合条件的节点之上。另外，它还为每种倾向性提供了 weight 属性以便用户定义其优先级，取值范围是 $1 ～ 100$ ，数字越大优先级越高。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy-with-node-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 60
            preference:
              matchExpressions:
              - {key: zone, operator: In, values: ["foo"]}
          - weight: 30
            preference:
              matchExpressions:
              - {key: ssd, operator: Exists, values: []}
      containers:
      - name: nginx
        image: nginx

Pod 资源模板定义了节点软亲和性以选择运行在拥有 zone=foo 和 ssd 标签（无论其值为何）的节点之上，其中 zone=foo 是更为重要的倾向性规则，它的权重为 $60$ ，相比较来说，ssd 标签就没有那么关键，它的权重为 $30$ 。这么一来，如果集群中拥有足够多的节点，那么它将被此规则分为四类：同时满足拥有 zone=foo 和 ssd 标签、仅具有 zoo=foo 标签、仅具有 ssd 标签，以及不具备此两个标签。如下图所示：

在这里插入图片描述
示例环境共有三个节点，相对于定义的节点亲和性规则来说，它们所拥有的倾向性权重分别如图所示。在创建需要 $3$ 个 Pod 对象的副本时，其运行效果为三个 Pod 对象被分散运行于集群中的三个节点之上，而非集中运行于某一个节点。

之所以如此，是因为使用了节点软亲和性的预选方式，所有节点均能够通过调度器上 MatchNodeSelector 预选策略的筛选，因此，可用节点取决于其他预选策略的筛选结果。在第二阶段的优选过程中，除了 NodeAffinityPriority 优选函数之外，还有其他几个优选函数参与优先级评估，尤其是 SelectorSpreadPriority，它会将同一个 ReplicaSet 控制器管控的所有 Pod 对象分散到不同的节点上运行以抵御节点故障带来的风险。不过，这种节点亲和性的权重依然在发挥作用，如果把副本数量扩展至越过节点数很多，如 $15$ 个，那么它们将被调度器以接近节点亲和性权重比值 $90 : 60 : 30$ 的方式分置于相关的节点之上。

2.Pod 亲和性调度

Pod 亲和性调度 需要各相关的 Pod 对象运行于 “同一位置”，而反亲和性调度则要求它们不能运行于 “同一位置” 。同一位置取决于节点的 位置拓扑，拓扑的方式不同。

如果以基于各节点的 kubernetes.io/hostname 标签作为评判标准，那么很显然，“同一位置” 意味着同一个节点，不同节点即不同的位置。如下图所示：

在这里插入图片描述
如果是基于所划分的故障转移域来进行评判，server1 和 server3 属于同一位置，而 server2 和 server4 属于另一个意义上的同一位置。

在 Kubernetes 中，故障迁移域（Fault Domain）是指能够共同处理故障的节点集合。Kubernetes 通过标签（Labels）和亲和性（Affinity）规则来实现对 Pod 调度时的故障迁移。假设我们有一个多区域的 Kubernetes 集群，每个区域有多个可用区（AZ）。我们可以为每个区域和可用区创建标签，并在 Pod 规范中使用亲和性规则来指定 Pod 应该被调度到特定的区域或可用区。

在这里插入图片描述
因此，在定义 Pod 对象的亲和性与反亲和性时，需要借助于标签选择器来选择被依赖的 Pod 对象，并根据选出的 Pod 对象所在节点的标签来判定 “同一位置” 的具体意义。

2.1 Pod 硬亲和

Pod 强制约束的亲和性调度也使用 requiredDuringSchedulinglgnoredDuringExecution 属性进行定义。Pod 亲和性用于描述一个 Pod 对象与具有某特征的现存 Pod 对象运行位置的依赖关系，因此，测试使用 Pod 亲和性约束，需要事先存在被依赖的 Pod 对象，它们具有特别的识别标签。例如创建一个有着标签 app=tomcat 的 Deployment 资源部署一个 Pod 对象。

kubectl run tomcat -l app=tomcat --image tomcat:alpine

再通过资源清单定义一个 Pod 对象，它通过 labelSelector 定义的标签选择器挑选感兴趣的现存 Pod 对象，而后根据挑选出的 Pod 对象所在节点的标签 kubernetes.io/hostname 来判断 同一位置 的具体含义，并将当前 Pod 对象调度至这一位置的某节点之上。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity-1
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - {key: app, operator: In, values: ["tomcat"]}
        topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx

事实上，kubernetes.io/hostname 标签是 Kubernetes 集群节点的内建标签，它的值为当前节点的节点主机名称标识，对于各个节点来说，各有不同。因此，新建的 Pod 镜象将被部署至被依赖的 Pod 对象的同一节点上，requiredDuringSchedulingIgnoredDuringExecution 表示这种亲和性为强制约束。

基于单一节点的 Pod 亲和性只在极个别的情况下才有可能会用到，较为常用的通常是基于同一地区 region、区域 zone 或机架 rack 的拓扑位置约束。例如部署应用程序服务 myapp 与数据库 db 服务相关的 Pod 时，db Pod 可能会部署于如上图所示的 foo 或 bar 这两个区域中的某节点之上，依赖于数据服务的 myapp Pod 对象可部署于 db Pod 所在区域内的节点上。当然，如果 db Pod 在两个区域 foo 和 bar 中各有副本运行，那么 myapp Pod 将可以运行于这两个区域的任何节点之上。

依赖于亲和于这两个 Pod 的其他 Pod 对象可运行于 zone 标签值为 foo 和 bar 的区域内的所有节点之上。资源配置清单如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-with-pod-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp
      labels:
        app: myapp
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - {key: app, operator: In, values: ["db"]}
            topologyKey: zone
      containers:
      - name: nginx
        image: nginx

在调度示例中的 Deployment 控制器创建的 Pod 资源时，调度器首先会基于标签选择器查询拥有标签 app=db 的所有 Pod 资源，接着获取到它们分别所属的节点的 zone 标签值，接下来再查询拥有匹配这些标签值的所有节点，从而完成节点预选。而后根据优选函数计算这些节点的优先级，从而挑选出运行新建 Pod 对象的节点。

需要注意的是，如果节点上的标签在运行时发生了更改，以致它不再满足 Pod 上的亲和性规则，但该 Pod 还将继续在该节点上运行，因此它仅会影响新建的 Pod 资源；另外，labelSelector 属性仅匹配与被调度器的 Pod 在同一名称空间中的 Pod 资源，不过也可以通过为其添加 namespace 字段以指定其他名称空间。

2.2 Pod 软亲和

类似于节点亲和性机制，Pod 也支持使用 preferredDuringSchedulinglgnoredDuringExecution 属性定义柔性亲和机制，调度器会尽力确保满足亲和约束的调度逻辑，然而在约束条件不能得到满足时，它也允许将 Pod 对象调度至其他节点运行。下面是一个使用了 Pod 软亲和性调度机制的资源配置清单示例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-with-preferred-pod-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp
      labels:
        app: myapp
    spec:
      affinity:
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 80
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - {key: app, operator: In, values: ["cache"]}
              topologyKey: zone
          - weight: 20
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - {key: app, operator: In, values: ["db"]}
              topologyKey: zone
      containers:
      - name: nginx
        image: nginx

它定义了两组亲和性判定机制，一个是选择 cache Pod 所在节点的 zone 标签，并赋予了较高的权重 $80$ ，另一个是选择 db Pod 所在节点的 zone 标签，它有着略低的权重 $20$ 。于是，调度器会将目标节点分为四类：cache Pod 和 db Pod 同时所属的 zone、cache Pod 单独所属的 zone、db Pod 单独所属的 zone，以及其他所有的 zone。

2.3 Pod 反亲和

podAffinity 用于定义 Pod 对象的亲和约束，对应地，将其替换为 podAntiAffinty 即可用于定义 Pod 对象的 反亲和约束。不过，反亲和性调度一般用于分散同一类应用的 Pod 对象等，也包括将不同安全级别的 Pod 对象调度至不同的区域、机架或节点等。下面的资源配置清单中定义了由同一 Deployment 创建但彼此基于节点位置互斥的 Pod 对象。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-with-pod-anti-affinity
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp
      labels:
        app: myapp
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - {key: app, operator: In, values: ["myapp"]}
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: nginx

由于定义的强制性反亲和约束，因此，创建的 $4$ 个 Pod 副本必须运行于不同的节点中。不过，如果集群中一共只存在 $3$ 个节点，因此，必然地会有一个 Pod 对象处于 Pending 状态。

类似地，Pod 反亲和性调度也支持使用柔性约束机制，在调度时，它将尽量满足不把位置相斥的 Pod 对象调度于同一位置，但是，当约束关系无法得到满足时，也可以违反约束而调度。可参考 podAffinity 的柔性约束示例将上面的 Deployment 资源 myapp-with-pod-anti-affinity 修改为柔性约束并进行调度测试。