【Kubernetes 015】pod调度之Affinity亲和性

默认情况下pod被分配到哪个node都是随机的，但是很多情况下这不太符合预期。例如有多台node，有的属于cpu密集型适合逻辑运算，有的属于gpu密集型适合机器学习。这时候就需要对pod调度的node有所规划，这一节学习第一种方式，根据亲和性进行调度。

我是T型人小付，一位坚持终身学习的互联网从业者。喜欢我的博客欢迎在csdn上关注我，如果有问题欢迎在底下的评论区交流，谢谢。

一些概念

Affinity对应pod的pod.spec.affinity字段，下面有多种组合配置，需要先明白一些概念

Affinity和Anti-affinity

亲和性分为正向的Affinity，表示愿意被分配至目标node，和反向的Anti-affinity，表示不愿意被分配至目标node。

NodeAffinity和PodAffinity

两个不同维度的亲和性策略，NodeAffinity是根据node的标签去决定是否分配。而PodAffinity是根据pod的标签去决定要不要和别的pod分配到一个node。

软策略和硬策略

软策略字段以preferred开头，表示尽量达到，没满足也没关系，多个软策略之间会有各自权重。硬策略字段以required开头，表示必须满足。

实际操作

因为本节的概念理解起来相对容易，所以直接上手操作。不过因为字段组合较多，建议多利用kubectl explain pod.spec.affinity查看各个字段的含义。

以下所有yaml文件托管在我的Github仓库

NodeAffinity实际操作

硬策略

通过下面的yaml文件test-nodeaffinity-hard.yaml来验证下node亲和性的硬策略

apiVersion: v1
kind: Pod
metadata:
  name: test-nodeaffinity-hard
  labels:
    app: app1
spec:
  containers:
    - name: mynginx
      image: mynginx:v2
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - k8s-node3

这里的matchExpressions是比配node的labels，底下的三个字段如下

字段	类型	说明
key	string	node的标签的key
operator	string	判断符号，可以选In/NotIn/Exists/DoesNotExist/Gt/Lt
values	list	一组值，结合上面的运算符号进行判断

node的labels可以用如下方式查看

[root@k8s-master affinity]# kubectl get node --show-labels
NAME         STATUS   ROLES    AGE   VERSION    LABELS
k8s-master   Ready    master   14d   v1