【kubernetes】节点选择器，节点亲和力，Pod亲和力与反亲和力

一，节点选择器

1，nodeName

可以指定pod运行在哪个具体node上，例如node01节点

# cat pod-node.yaml

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  namespace: default  
spec:
  nodeName: node01   # 指定nodeName 值为node01
  containers:
  - name:  tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat:8.5-jre8-alpine
    imagePullPolicy: IfNotPresent
  ....

2，nodeSelector

指定pod调度到具有哪些标签的node节点上，例如 具有disk=ceph标签的某个node节点

# cat pod-1.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod-1
  namespace: default
  labels:
    app: myapp
    env: dev
spec:
  nodeSelector:   # 通过 nodeSelector选择器
    disk: ceph    # 定位到disk=ceph标签的某个node机器上
  containers:
  - name: tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat:8.5-jre8-alpine
    imagePullPolicy: IfNotPresent

【注意】：同一个yaml文件里定义pod资源，如果同时定义了nodeName和NodeSelector，那么条件必须都满足才可以，有一个不满足都会调度失败

二，Node节点亲和力

1，Node节点亲和力(NodeAffinity)

1，requiredDuringSchedulingIgnoredDuringExecution

硬亲和力，即支持必须部署在指定的节点上，也支持必须不部署在指定的节点上。

2，preferredDuringSchedulingIgnoredDuringExecution

软亲和力，即尽量部署在满足条件的节点上，或尽量不要部署在被匹配的节点上。

3，层级关系

4，operator匹配取值

• in : 满足一个就行
• Notin ： 一个都不满足，反亲和力
• Exists ： 只要存在，就满足
• DoesNotExists ：只有不存在，才满足
• Gt ：必须要大于节点上的数值，才满足
• Lt ：必须要小于节点上的数值，才满足

案例1：

使用requiredDuringSchedulingIgnoredDuringExecution硬亲和性

# cat pod-nodeaffinity-demo.yaml 

apiVersion: v1
kind: Pod
metadata:
  name:  pod-node-affinity-demo
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  affinity:
    nodeAffinity:
     requiredDuringSchedulingIgnoredDuringExecution:
       nodeSelectorTerms:
       - matchExpressions:
         - key: zone
           operator: In
           values: 
           - foo
           - bar
  containers:
  - name: myapp

说明：当前node节点中，有任意一个节点拥有zone标签的值是foo或者bar，就可以把pod调度到这个node节点上。

status的状态是pending，上面说明没有完成调度，因为没有一个拥有zone的标签的值是foo或者bar，而且使用的是硬亲和性，必须满足条件才能完成调度

案例2：

使用preferredDuringSchedulingIgnoredDuringExecution软亲和性

# cat pod-nodeaffinity-demo-2.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: pod-node-affinity-demo-2
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: myapp
    image: docker.io/ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - preference:
          matchExpressions: 
          - key: zone1
            operator: In
            values:
            - foo1
            - bar1
        weight: 10
      - preference:
          matchExpressions:
          - key: zone2
            operator: In
            values:
            - foo2
            - bar2
        weight: 20

说明：软亲和性是可以运行这个pod的，尽管没有运行这个pod的节点定义的zone1标签。

Node节点亲和性针对的是pod和node的关系，Pod调度到node节点的时候匹配的条件。

【测试weight权重】：
weight是相对权重，权重越高，pod调度的几率越大。

三，Pod容器亲和力

第一个pod随机选则一个节点，做为评判后续的pod能否到达这个pod所在的节点上的运行方式，这就称为pod亲和性。

我们怎么判定哪些节点是相同位置的，哪些节点是不同位置的？

pod自身的亲和性调度有两种表示形式：

1，亲和力 (PodAffinity)

Pod 亲和力: 将与指定 pod 亲和力相匹配的另外的pod 部署在同一位置的同一节点上。

pod和pod更倾向腻在一起，把相近的pod结合到相近的位置，如同一区域，同一机架，这样的话pod和pod之间更好通信。

kubectl explain pods.spec.affinity.podAffinity

• requiredDuringSchedulingIgnoredDuringExecution ：硬亲和力，同上

• preferredDuringSchedulingIgnoredDuringExecution ：软亲和力，同上

案例

第一个pod做为基准：

# cat pod-required-affinity-demo-1.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  labels:
    app2: myapp2
    tier: frontend
spec:
    containers:
    - name: myapp
      image: ikubernetes/myapp:v1
      imagePullPolicy: IfNotPresent

第二个pod跟随第一个：

# cat pod-required-affinity-demo-2.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: pod-second
  labels:
    app: backend
    tier: db
spec:
    containers:
    - name: busybox
      image: busybox:latest
      imagePullPolicy: IfNotPresent
      command: ["sh","-c","sleep 3600"]
    affinity:
      podAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
              matchExpressions:
              - {key: app2, operator: In, values: ["myapp2"]}
           topologyKey: kubernetes.io/hostname

说明：
上面表示创建的pod必须与拥有app=myapp标签的pod在一个节点上，第一个pod调度到哪，第二个pod也调度到哪，这就是pod节点亲和性。

2，反亲和力 (PodAntiAffinity)

Pod 反亲和力: 根据策略，与相匹配的另外的pod ，尽量部署或不部暑到一块。

pod和pod更倾向不腻在一起，如果部署两套程序，那么这两套程序更倾向于反亲和性，这样相互之间不会有影响。

1，requiredDuringSchedulingIgnoredDuringExecution ：硬亲和力，同上

2，preferredDuringSchedulingIgnoredDuringExecution ：软亲和力，同上

案例

第一个pod做为基准：

# cat pod-required-anti-affinity-demo-1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  labels:
    app1: myapp1
    tier: frontend
spec:
    containers:
    - name: myapp
      image: ikubernetes/myapp:v1
      imagePullPolicy: IfNotPresent

第二个pod跟它调度节点相反：

# cat pod-required-anti-affinity-demo-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-second
  labels:
    app: backend
    tier: db
spec:
    containers:
    - name: busybox
      image: busybox:latest
      imagePullPolicy: IfNotPresent
      command: ["sh","-c","sleep 3600"]
    affinity:
      podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
              matchExpressions:
              - {key: app1, operator: In, values: ["myapp1"]}
           topologyKey: kubernetes.io/hostname

说明：

kubectl get pods -o wide 显示两个pod不在一个node节点上，这就是pod节点反亲和性。

案例

换一个topologykey

第一个pod：

# cat pod-first-required-anti-affinity-demo-1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  labels:
    app3: myapp3
    tier: frontend
spec:
    containers:
    - name: myapp
      image: ikubernetes/myapp:v1
      imagePullPolicy: IfNotPresent

第二个pod：

# cat pod-second-required-anti-affinity-demo-1.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: pod-second
  labels:
    app: backend
    tier: db
spec:
    containers:
    - name: busybox
      image: busybox:latest
      imagePullPolicy: IfNotPresent
      command: ["sh","-c","sleep 3600"]
    affinity:
      podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
              matchExpressions:
              - {key: app3 ,operator: In, values: ["myapp3"]}
           topologyKey:  zone

#kubectl get pods -o wide 显示如下：
pod-first              running         xianchaonode1
pod-second            pending         <none>

第二个pod是pending，因为两个节点是同一个位置，现在没有不是同一个位置的了，而且我们要求反亲和性，所以就会处于pending状态，如果在反亲和性这个位置把required改成preferred，那么也会运行。

总结：

nodeaffinity：node亲和性，pod倾向于哪个node节点调度。
podaffinity：pod亲和性，pod倾向于向哪个pod调度。
poduntiaffinity：pod反亲和性，pod倾向于远离哪个pod的地方调度。