Kubernetes 亲和性调度

一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们内部的一些服务gitlab 之类的也是跑在Kubernetes 集群上的，我们就不希望对外的一些服务和内部的服务跑在同一个节点上了，害怕内部服务对外部的服务产生影响；但是有的时候我们的服务之间交流比较频繁，又希望能够将这两个服务的 Pod 调度到同一个的节点上。这就需要用到 Kubernetes 里面的一个概念：亲和性和反亲和性。

亲和性又分成节点亲和性( nodeAffinity )和 Pod 亲和性( podAffinity )。

nodeSelector

在了解亲和性之前，我们先来了解一个非常常用的调度方式：nodeSelector。我们知道label 是kubernetes 中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，比如最常见的一个就是 service 通过匹配 label 去匹配 Pod 资源，而 Pod 的调度也可以根据节点的 label 来进行调度。

可以通过下面的命令查看我们的 node 的 label：

[root@master ~]# kubectl  get nodes --show-labels 
NAME     STATUS   ROLES    AGE   VERSION   LABELS
master   Ready    master   23d   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
node1    Ready    <none>   23d   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2    Ready    <none>   23d   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

现在我们先给节点node02增加一个com=kcc的标签，命令如下：

添加标签
[root@master ~]# kubectl  label nodes node2 com=kcc
node/node2 labeled
删除标签
[root@master ~]# kubectl  label node node2 com-
node/node2 labeled

我们可以通过上面的–show-labels 参数可以查看上述标签是否生效。当node 被打上了相关标签后，在调度的时候就可以使用这些标签了，只需要在 Pod 的spec字段中添加 nodeSelector 字段，里面是我们需要被调度的节点的 label 即可。比如，下面的 Pod 我们要强制调度到 node02 这个节点上去，我们就可以使用 nodeSelector 来表示了：(node-selector-demo.yaml)

[root@master ~]# kubectl  get nodes --show-labels 
NAME     STATUS   ROLES    AGE   VERSION   LABELS
master   Ready    master   23d   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
node1    Ready    <none>   23d   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2    Ready    <none>   23d   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,com=kcc,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux


apiVersion: v1
kind: Pod
metadata:
  name: node-scheduler
spec:
  nodeSelector:
    com: kcc
  containers:
  - name: busybox
    image: busybox
    command: ["sh","-c","sleep 3600"]
[root@master ~]# kubectl get pods -o wide -w| grep node-scheduler 
node-scheduler                            0/1     ContainerCreating   0          42s     <none>         node2   <none>           <none>
node-scheduler                            1/1     Running             0          2m2s    10.244.3.51    node2   <none>           <none>

[root@master ~]# kubectl  describe pods node-scheduler 
Events:
  Type    Reason     Age        From               Message
  ----    ------     ----       ----               -------
  Normal  Scheduled  <unknown>  default-scheduler  Successfully assigned default/node-scheduler to node2

我们可以看到 Events 下面的信息，我们的 Pod 通过默认的 default-scheduler 调度器被绑定到了k8s-node02节点。不过需要注意的是nodeSelector 属于强制性的，如果我们的目标节点没有可用的资源，我们的 Pod 就会一直处于 Pending 状态，这就是nodeSelector 的用法。

nodeSelector 的方式比较直观，但是还不够灵活，控制粒度偏大，接下来我们再和大家了解下更加灵活的方式：节点亲和性( nodeAffinity )。

亲和性和反亲和性调度

我们知道默认的调度器在使用的时候，经过了 predicates 和 priorities 两个阶段，但是在实际的生产环境中，往往需要根据自己的一些实际需求来控制 pod 的调度，这就需要用到 nodeAffinity(节点亲和性)、podAffinity(pod 亲和性) 以及podAntiAffinity(pod 反亲和性)。

亲和性调度可以分成软策略和硬策略两种方式:

  1. 软策略 就是如果你没有满足调度要求的节点的话，pod 就会忽略这条规则，继续完成调度过程，说白了就是满足条件最好了，没有的话也无所谓了的策略
  2. 硬策略 就比较强硬了，如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然我就不干的策略。

对于亲和性和反亲和性都有这两种规则可以设置：

preferredDuringSchedulingIgnoredDuringExecution  软策略
requiredDuringSchedulingIgnoredDuringExecution   硬策略  
   太反人类了

nodeAffinity

节点亲和性主要是用来控制 pod 要部署在哪些主机上，以及不能部署在哪些主机上的。它可以进行一些简单的逻辑组合，不只是简单的相等匹配。

我们用一个 Deployment 来管理2个 pod 副本，现在我们来控制下这些 pod 的调度，如下例子：（node-affinity-demo.yaml）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: affinity
  labels:
    app: affinity
spec:
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: affinity
  template:
    metadata:
      labels:
        app: affinity
    spec:
      containers:
      - name: busybox
        image: busybox
        ports:
        - containerPort: 80
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernets.io/hostname
                operator: NotIn
                values:
                - node1
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              preference:
                matchExpressions:
                - key: com
                  operator: In
                  values:
                  - kcc

[root@master ~]# kubectl  get pods -o wide -w | grep affinity
affinity-57cc5bc8b6-dlrfb                 0/1     ContainerCreating   0          54s     <none>         node2   <none>           <none>
affinity-57cc5bc8b6-t2mdh                 0/1     ContainerCreating   0          54s     <none>         node2   <none>           <none>
affinity-57cc5bc8b6-t2mdh                 1/1     Running             0          107s    10.244.3.52    node2   <none>           <none>
affinity-57cc5bc8b6-dlrfb                 1/1     Running             0          108s    10.244.3.53    node2   <none> 
都调度到了node2节点上

现在Kubernetes 提供的操作符有下面的几种：

  1. In：label 的值在某个列表中
  2. NotIn：label 的值不在某个列表中
  3. Gt：label 的值大于某个值
  4. Lt：label 的值小于某个值
  5. Exists：某个 label 存在
  6. DoesNotExist：某个 label 不存在
如果nodeSelectorTerms 下面有多个选项的话，满足任何一个条件就可以了；如果matchExpressions 有多个选项的话，则必须同时满足这些条件才能正常调度 POD。

podAffinity

pod 亲和性主要解决 pod 可以和哪些 pod 部署在同一个拓扑域中的问题（其中拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的 cluster、zone 等等），而 pod 反亲和性主要是解决 pod 不能和哪些pod 部署在同一个拓扑域中的问题，它们都是处理的 pod 与 pod 之间的关系，比如一个 pod 在一个节点上了，那么另一个也得在这个节点，或者你这个 pod 在节点上了，那么我就不想和你待在同一个节点上。

由于我们这里只有一个集群，并没有区域或者机房的概念，所以直接使用主机名来作为拓扑域，把 pod 创建在同一个主机上面。

同样，还是针对上面的资源对象，我们来测试下 pod 的亲和性：（pod-affinity-demo.yaml）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-affinity
  labels:
    app: pod-affinity
spec:
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: pod-affinity
  template:
    metadata:
      labels:
        app: pod-affinity
    spec:
      containers:
      - name: nginx
        image: nignx
        imagePullPolicy: IfNotPresent
        ports:
        - name: web
          containerPort: 80
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - busybox-pod
            topologyKey: kubernets.io/hostname


[root@master ~]# kubectl  get pods -o wide | grep pod-affinity
pod-affinity-574bdbdcbc-qtrc6             0/1     Pending     0          27s     <none>         <none>   <none>           <none>
pod-affinity-574bdbdcbc-xs9sn             0/1     Pending     0          27s     <none>         <none>   <none>           <none>

由于没有busybox-pod标签的pod在运行所以出于pending状态，所以需要创建一个busybox-pod标签的pod

[root@master ~]# kubectl  get pods -o wide -w | grep pod
busybox-pod-6ccd67db74-5lpkj              1/1     Running       0          15m     10.244.3.56    node2   <none>           <none>
pod-affinity-75cb6d79c8-58xz8             1/1     Running             0          21s     10.244.3.61    node2   <none>           <none>
pod-affinity-75cb6d79c8-68qbc             1/1     Running             0          22s     10.244.3.60    node2   <none>           <none>

我们这个地方使用的是kubernetes.io/hostname这个拓扑域，意思就是我们当前调度的 pod 要和目标的 pod 处于同一个主机上面，因为要处于同一个拓扑域下面，为了说明这个问题，我们把拓扑域改成beta.kubernetes.io/os，同样的我们当前调度的 pod 要和目标的 pod处于同一个拓扑域中，目标的 pod 是不是拥有beta.kubernetes.io/os=linux 的标签，而我们这里3个节点都有这样的标签，这也就意味着我们3个节点都在同一个拓扑域中，所以我们这里的pod 可能会被调度到任何一个节点：

podAntiAffinity

这就是 pod 亲和性的用法，而 pod 反亲和性则是反着来的，比如一个节点上运行了某个 pod，那么我们的 pod 则希望被调度到其他节点上去，同样我们把上面的 podAffinity 直接改成 podAntiAffinity，(pod-antiaffinity-demo.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-antiaffinity
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pod-antiaffinity
  template:
    metadata:
      labels:
        app: pod-antiaffinity
    spec:
      containers:
      - name: antiaffinity
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - name: web
          containerPort: 80
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - busybox-pod
            topologyKey: kubernetes.io/hostname

[root@master ~]# kubectl  get pods -o wide -w | grep pod
busybox-pod-6ccd67db74-5lpkj              1/1     Running             0          41m     10.244.3.56    node2   <none>           <none>
pod-antiaffinity-896c6574-76vmj           0/1     ContainerCreating   0          19s     <none>         node1   <none>           <none>
pod-antiaffinity-896c6574-8pfbm           0/1     ContainerCreating   0          19s     <none>         node1   <none>           <none>
pod-antiaffinity-896c6574-76vmj           1/1     Running             0          69s     10.244.1.60    node1   <none>           <none>
pod-antiaffinity-896c6574-8pfbm           1/1     Running             0          71s     10.244.1.61    node1   <none>           <none>

可以看到分配到了不同节点上

这里的意思就是如果一个节点上面有一个app=busybox-pod 这样的 pod 的话，那么我们的 pod 就别调度到这个节点上面来，上面我们把app=busybox-pod 这个 pod 固定到了 node02 这个节点上面来，所以正常来说我们这里的 pod 不会出现在 node02 节点上：

污点（taints）与容忍（tolerations）

对于nodeAffinity 无论是硬策略还是软策略方式，都是调度 pod 到预期节点上，而Taints 恰好与之相反，如果一个节点标记为 Taints ，除非pod 也被标识为可以容忍污点节点，否则该 Taints 节点不会被调度 pod。

比如用户希望把 Master 节点保留给 Kubernetes 系统组件使用，或者把一组具有特殊资源预留给某些 pod，则污点就很有用了，pod 不会再被调度到 taint 标记过的节点。我们使用kubeadm搭建的集群默认就给 master 节点添加了一个污点标记，所以我们看到我们平时的 pod 都没有被调度到master 上去：

[root@master ~]# kubectl  describe node master | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule

我们可以使用上面的命令查看 master 节点的信息，其中有一条关于 Taints的信息：node-role.kubernetes.io/master:NoSchedule，就表示给master 节点打了一个污点的标记，其中影响的参数是NoSchedule ，表示pod 不会被调度到标记为 taints 的节点，除了 NoSchedule 外，还有另外两个选项：

  1. PreferNoSchedule ：NoSchedule 的软策略版本，表示尽量不调度到污点节点上去
  2. NoExecute ：该选项意味着一旦 Taint 生效，如该节点内正在运行的pod 没有对应 Tolerate 设置，会直接被逐出

污点 taint 标记节点的命令如下：

[root@master ~]# kubectl taint nodes node2 test=node2:NoSchedule
[root@master ~]# kubectl describe node node2 | grep Taints
Taints:             kubernetes.io/node2:NoSchedule

上面的命名将 node02 节点标记为了污点，影响策略是 NoSchedule，只会影响新的 pod 调度，如果仍然希望某个 pod 调度到 taint 节点上，则必须在 Spec 中做出Toleration 定义，才能调度到该节点，比如现在我们想要将一个 pod 调度到 node2 节点：(taint-demo.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: taint
  labels:
    app: taint
spec:
  replicas: 3
  revisionHistoryLimit: 10
  selectoy:
    matchLabels:
      labels:
        app: taint
  template:
    metadata:
      app: taint
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - name: web
          containerPort: 80
        tolerations:
        - key: "kubernetes.io/node2"
          operator: "Exists"
          effect: "NoSchedule"

[root@master ~]# kubectl get pods -o wide  -w | grep taint
taint-6bc9dc576d-9z26p                    1/1     Running     0          36s    10.244.3.63    node2   <none>           <none>
taint-6bc9dc576d-cqkwg                    1/1     Running     0          36s    10.244.3.62    node2   <none>           <none>
taint-6bc9dc576d-m9zmq                    1/1     Running     0          36s    10.244.1.62    node1   <none>           <none>

由于 node2 节点被标记为了污点节点，所以我们这里要想 pod 能够调度到 node2 节点去，就需要增加容忍的声明
tolerations:
        - key: "kubernetes.io/node2"
          operator: "Exists"
          effect: "NoSchedule"

对于 tolerations 属性的写法，其中的 key、value、effect 与 Node 的Taint 设置需保持一致， 还有以下几点说明：

  1. 如果 operator 的值是 Exists，则 value 属性可省略
  2. 如果 operator 的值是 Equal，则表示其 key 与 value 之间的关系是equal(等于)
  3. 如果不指定 operator 属性，则默认值为 Equal另外，还有两个特殊值：
  4. 空的 key 如果再配合 Exists 就能匹配所有的 key 与 value，也是是能容忍所有 node 的所有 Taints
  5. 空的 effect 匹配所有的 effect

最后，如果我们要取消节点的污点标记，可以使用下面的命令：

kubectl taint nodes node2 kubernetes.io/node2:NoSchedule-
kubectl taint node node1 key1-  删除指定key所有的effect
# linux # docker # 容器 # 运维
Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods