k8s nodeSelector和affinity 调度亲和性

nodeSelector

1.分配pod到node的方法

经过node label selector实现约束pod运行到指定节点,有两种方法 nodeSelector 以及affinity

2.nodeSelector 是k8s早起提供的节点选择器实现

1）首先为nodes打对应的label
kubectl label nodes master disktype=ssd
2)建立yaml文件，nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx

建立pod

kubectl create -f nginx-pod.yaml
节点默认的label
kubectl get nodes -o yaml 能够看到默认节点的label,也可使用这些label进行约束

alpha.kubernetes.io/fluentd-ds-ready: "true"
beta.kubernetes.io/arch: amd64
beta.kubernetes.io/os: linux
disktype: ssd
kubeadm.alpha.kubernetes.io/role: master
kubernetes.io/hostname: master

亲和性和反亲和性

根据类型有

nodeAffinity（主机亲和性），
podAffinity（POD亲和性）
podAntiAffinity（POD反亲和性）。

三种亲和性和反亲和性策略的比较以下表所示：

策略名称	匹配目标	支持的操做符	支持拓扑域	设计目标
nodeAffinity	主机标签	In，NotIn，Exists，DoesNotExist，Gt，Lt	不支持	决定Pod能够部署在哪些主机上
podAffinity	Pod标签	In，NotIn，Exists，DoesNotExist	支持	决定Pod能够和哪些Pod部署在同一拓扑域
PodAntiAffinity	Pod标签	In，NotIn，Exists，DoesNotExist	支持	决定Pod不能够和哪些Pod部署在同一拓扑域

对于亲和性和反亲和性，每种都有三种规则能够设置：

RequiredDuringSchedulingRequiredDuringExecution ：在调度期间要求知足亲和性或者反亲和性规则，若是不能知足规则，则POD不能被调度到对应的主机上。在以后的运行过程当中，若是由于某些缘由（好比修改label）致使规则不能知足，系统会尝试把POD从主机上删除（如今版本还不支持）。

RequiredDuringSchedulingIgnoredDuringExecution ：在调度期间要求知足亲和性或者反亲和性规则，若是不能知足规则，则POD不能被调度到对应的主机上。在以后的运行过程当中，系统不会再检查这些规则是否知足。

PreferredDuringSchedulingIgnoredDuringExecution ：在调度期间尽可能知足亲和性或者反亲和性规则，若是不能知足规则，POD也有可能被调度到对应的主机上。在以后的运行过程当中，系统不会再检查这些规则是否知足。

使用场景介绍

nodeAffinity使用场景 ：

• 将S1服务的全部Pod部署到指定的符合标签规则的主机上。
• 将S1服务的全部Pod部署到除部分主机外的其余主机上。

podAffinity使用场景 ：

• 将某一特定服务的pod部署在同一拓扑域中，不用指定具体的拓扑域。
• 若是S1服务使用S2服务，为了减小它们之间的网络延迟（或其它缘由），把S1服务的POD和S2服务的pod部署在同一拓扑域中。

podAntiAffinity使用场 景：

• 将一个服务的POD分散在不一样的主机或者拓扑域中，提升服务自己的稳定性。
• 给POD对于一个节点的独占访问权限来保证资源隔离，保证不会有其它pod来分享节点资源。
• 把可能会相互影响的服务的POD分散在不一样的主机上。

NodeAffinity

参考：https://k8smeetup.github.io/docs/concepts/configuration/assign-pod-node/#node-亲和性beta-特性

requiredDuringSchedulingIgnoredDuringExecution的示例

下面这个例子使用nodeAffinity把POD部署到主机mesos-slave1和mesos-slave2上面

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
  annotations:
    scheduler.alpha.kubernetes.io/affinity: >
      {
        "nodeAffinity": {
          "requiredDuringSchedulingIgnoredDuringExecution": {
            "nodeSelectorTerms": [
              {
                "matchExpressions": [
                  {
                    "key": "kubernetes.io/hostname",
                    "operator": "In",
                    "values": [“mesos-slave1″,”mesos-slave2”]
                  }
                ]
              }
            ]
          }
        }
      }
    another-annotation-key: another-annotation-value
spec:
  containers:
  - name: with-node-affinity
    image: gcr.io/google_containers/pause:2.0

咱们能够看到NodeSelectorTerms能够有多个，之间是或的关系，知足任意一个既知足，，MatchExpressions也能够有多个，他们之间是且的关系 必须都知足。

preferredDuringSchedulingIgnoredDuringExecution 例子

apiVersion: v1
kind: Pod
metadata:
  name: with-labels
  annotations:
    scheduler.alpha.kubernetes.io/affinity: >
    {
       "nodeAffinity": {
          "preferredDuringSchedulingIgnoredDuringExecution": [
                {
                    "weight" : 1,
                    "preference": {
                        "matchExpressions": [
                            {
                                "key": "disktype",
                                "operator": "In",
                                "values": ["ssd"]
                            }
                        ]
                    }
                }
            ]
        }
    }
    another-annotation-key: another-annotation-value
spec:
  containers:
  - name: test-affinity
    env:
      - name: MYSQL_ROOT_PASSWORD
        value: pass
    image: mysql

•  

preferredDuringSchedulingIgnoredDuringExecution值为列表，根据权重决定顺序
MatchExpressions 值为列表 关系为且，必须都知足

Inter-pod affinity and anti-affinity

Inter-pod affinity 是根据经过已运行在节点上的pod的标签而不是node的标签来决定被调度pod的运行节点，由于pod运行在指定的namespace因此须要本身指定运行pod的namesapce

anti-affinity 和Inter-pod affinity相反

在下面这个例子中，定义了一个Pod亲和性和一个Pod反亲和性规则。其中Pod亲和性规则是必定要知足的，Pod反亲和性规则是参考知足的。

Pod亲和性规则的含义是：Pod必须部署在一个节点上，这个节点上至少有一个正在运行的Pod，这个Pod的security属性取值是“S1”，而且要求部署的节点同正在运行的Pod所在节点都在相同的云服务区域中，也就是“topologyKey:failure-domain.beta.kubernetes.io/zone”。换言之，一旦某个区域出了问题，咱们但愿这些 Pod 可以再次迁移到同一个区域。

Pod反亲和性规则的含义是，Pod不能部署在一个节点上，这个节点上正在运行的Pod中security属性取值是“S2”，而且新部署的Pod不能同security属性取值是“S2”的Pod在相同的主机上，也就是“topologyKey: kubernetes.io/hostname”。

matchExpressions中operator的取值包括In、NotIn、Exists、DoesNotExist、Gt和Lt。topologyKey的取值包括：

1. kubernetes.io/hostname       同一个主机

   • 1

2. failure-domain.beta.kubernetes.io/zone      同一个云服务区

   • 1

3. failure-domain.beta.kubernetes.io/region    同一个区域

   • 1

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
  annotations:
    scheduler.alpha.kubernetes.io/affinity: >
        {
          "podAffinity": {
            "requiredDuringSchedulingIgnoredDuringExecution": [
              {
                "labelSelector": {
                  "matchExpressions": [
                    {
                      "key": "security",
                      "operator": "In",
                      "values": ["S1"]
                    }
                  ]
                },
                "topologyKey": "failure-domain.beta.kubernetes.io/zone"
             }
            ]
           },
          "podAntiAffinity": {
            "requiredDuringSchedulingIgnoredDuringExecution": [
              {
                "labelSelector": {
                  "matchExpressions": [
                    {
                      "key": "security",
                      "operator": "In",
                      "values": ["S2"]
                    }
                  ]
                },
                "topologyKey": "kubernetes.io/hostname"
             }
            ]
           }
         }
spec:
  containers:
  - name: with-pod-affinity
    image: gcr.io/google_containers/pause:2.0