20. 资源的调度——Node 亲和性

本章讲解知识点

• Node Affinity 概念
• 实验
• Node亲和性（Node Affinity）的注意点

<br>

1. Node Affinity 概念

亲和性和反亲和性是 Kubernetes 中用于描述 Pod 和 Node 之间关系的概念。亲和性（Affinity）指的是在 Pod 调度时，根据 Pod 和 Node 之间的匹配程度来进行选择的策略；而反亲和性（Anti-Affinity）则是在 Pod 调度时，根据 Pod 和 Node 之间的不匹配程度来进行选择的策略。

通过使用亲和性和反亲和性，可以使 Pod 和 Node 之间的关系更加灵活，从而更好地满足应用程序的需求。比如，可以将相关的 Pod 调度到同一组 Node 上，从而提高应用程序的性能和可靠性。另外，可以使用反亲和性来避免将相同类型的 Pod 调度到同一组 Node 上，以避免出现单点故障。

在 Kubernetes 中，Node 亲和性（Node Affinity）是一种策略，用于指定一个 Pod 可以调度到哪些节点上。Node 亲和性可以基于节点的标签和 Pod 的标签进行匹配，以便将 Pod 调度到具有特定标签的节点上。

Node 亲和性有两种类型：

• requiredDuringSchedulingIgnoredDuringExecution：这种类型的 Node 亲和性是必需的，并且在调度 Pod 时必须考虑。如果没有符合条件的节点，Pod 将无法调度。这是一种硬限制。
• preferredDuringSchedulingIgnoredDuringExecution：这种类型的 Node 亲和性是一种软限制，并且可以被忽略。如果没有符合条件的节点，Pod 仍然可以被调度。但是，如果有多个节点符合条件，可以设置权重值，则将尽可能选择优先级最高的节点。

IgnoredDuringExecution的意思是，如果在 Pod 运行时节点的标签被更改或删除，则不会将 Pod 驱逐出该节点。

<br>

2. 实验

比如上一节我们通过打标签的方式来选择调度，接下来我们采用 Node 亲和性来实现相同的功能。我们在 deployment 定义文件中加入 affinity 相关定义

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-first-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-first-deploy
  template:
    metadata:
      labels:
        app: my-first-deploy
    spec:
      containers:
      - name: my-first-container
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
      tolerations:
      - key: CriticalAddonsOnly
        operator: Exists
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
      affinity:
        nodeAffinity:  // 相关定义
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: app
                operator: In
                values:
                - my-first-deploy

创建应用：

[root@master mtuser]# kubectl create -f my-first-deploy.yaml
deployment.apps/my-first-deploy created

[root@master mtuser]# kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
my-first-deploy-788dcd94d5-pm8k5   0/1     Pending   0          108s

但是我们发现 Pod 呈现 Pending 状态，我们来 describe 一下：

[root@master mtuser]# kubectl describe pod my-first-deploy-788dcd94d5-pm8k5 | tail -10
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     CriticalAddonsOnly
                 node-role.kubernetes.io/master:NoSchedule
                 node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason            Age                  From               Message
  ----     ------            ----                 ----               -------
  Warning  FailedScheduling  81s (x3 over 2m49s)  default-scheduler  0/2 nodes are available: 2 node(s) didn't match node selector.

这个报错的意思就是两个节点都没有相关的标签，我们在 affinity 中定义的标签是 app=my-first-deploy

[root@master mtuser]# kubectl get node -l app=my-first-deploy
No resources found.

我们发现节点都没有打 app=my-first-deploy 标签，此时 Pod 默认调度方式也失效。说明了requiredDuringSchedulingIgnoredDuringExecution的强匹配模式。

我们来个节点打上标签：

[root@master mtuser]# kubectl label node node1 app=my-first-deploy
node/node1 labeled
[root@master mtuser]#
[root@master mtuser]# kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
my-first-deploy-788dcd94d5-pm8k5   1/1     Running   0          6m11s

[root@node1 mtuser]# docker ps | grep my-firs
6700022f144e   605c77e624dd           "/docker-entrypoint.…"   27 seconds ago   Up 26 seconds             k8s_my-first-container_my-first-deploy-788dcd94d5-pm8k5_default_3b5b30e7-90ea-4ae9-9b3e-d930597abb1c_0
318f9d75ffba   k8s.gcr.io/pause:3.1   "/pause"                 29 seconds ago   Up 27 seconds             k8s_POD_my-first-deploy-788dcd94d5-pm8k5_default_3b5b30e7-90ea-4ae9-9b3e-d930597abb1c_0

我们发现 Pod 成功调度到了工作节点上了，达到了我们的预期。

在 Kubernetes 中，Node 亲和性可以使用不同的操作符（ope