python的kubernetes模块 网络 kubernetes nodeselector

文章目录

• 一、前言

• 1. 概述
• 2. 亲和性和反亲和性的类型
• 3.硬亲和与软亲和
• 4.亲和性支持的运算符

• 二、nodeAffinity（节点亲和）

• 1. 测试环境准备
• 2. 节点硬亲和
• 3. 节点软亲和

• 三、podAffinity（pod亲和）podAntiAffinity（pod反亲和）

• 1. 测试环境准备
• 2. pod亲和性
• 3. pod反亲和性

---

一、前言

以下概述比较啰嗦，可直接跳过看例子

1. 概述

在k8s集群中，pod的调度是通过Scheduler组件来完成的。如果我们想要把pod调度到我们指定的节点，就需要管理员手动的进行操作。
nodeSelector 提供了一种将pod限制在节点的标签上。从而实现pod的固定调度，但是这种方式比较死板。
亲和性和反亲和性不同于nodeSelector的是可以极大的扩展了表达的约束类型，语言更具表达性，提供多种匹配规则，可以指定规则是优选项而不是硬要求，调度器不满足，pod仍然会被调度，可以不依赖与节点之间的标签，还可以针对pod之间的标签来做亲和与反亲和

2. 亲和性和反亲和性的类型

nodeAffinity（节点亲和）
节点亲和针对的是节点的标签，和nodeSelector相似，都是通过节点标签来约束pod的调度
podAffinity（pod亲和）podAntiAffinity（pod反亲和）
pod亲和针与反亲和针对的是pod的标签，虽然是针对pod的标签来约束，但是也不能够少一个条件，就是topologkey(拓扑域 多个node节点具有相同的标标签，键值键名相同)，pod标签辅助topologkey来选择pod调度的节点。
简而言之，pod的亲和性和反亲和性调度是根据拓扑域来调度的，而不是根据node节点

3.硬亲和与软亲和

不管是节点亲和还是pod亲和都具有硬亲和与软亲和两种类型
requiredDuringSchedulingIgnoredDuringExecution（硬 必须满足条件）
pod调度到节点必须满足规则条件，不满足则不会调度，pod会一致处于pending状态
preferredDuringSchedulingIgnoredDuringExecution（软 优先满足符合条件的节点）
表示优先调度到满足规则条件的节点，如果不能满足在调度到其他节点

4.亲和性支持的运算符

IN ：label的值在某个列表中
Notln：label 的值不在某个列表中
Exists：某个label存在
DoesNotExist：某个label不存在
Gt：label的值大于某个值
Lt：label的值小于某个值

二、nodeAffinity（节点亲和）

1. 测试环境准备

为节点打标签
[root@master ~]# kubectl label node node1 type=test1
node/node1 labeled
[root@master ~]# kubectl label node node2 type=test2
node/node2 labeled
[root@master ~]# kubectl label node node1 num=1
node/node1 labeled
[root@master ~]# kubectl label node node2 num=3
node/node2 labeled

[root@master ~]# kubectl get node --show-labels
NAME     STATUS   ROLES    AGE   VERSION   LABELS
master   Ready    master   12d   v1.18.2   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>   12d   v1.18.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux,num=1,type=test1
node2    Ready    <none>   12d   v1.18.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux,num=3,type=test2

node1的标签为type=test1 num=1
node2的标签为type=test2 num=3

2. 节点硬亲和

[root@master ~]# vi affinity_node.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx
spec:
  replicas: 3 
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
      affinity:
        nodeAffinity: #节点亲和
          requiredDuringSchedulingIgnoredDuringExecution: #节点硬亲和
            nodeSelectorTerms:  #node标签选择对象
            - matchExpressions: 
              - key: type
                operator: In  #运算符
                values: #存在多个值满足一个即可
                - test1
                - test2 
              - key: num
                operator: Gt  #大于符号
                values:
                - "2"

综上所写我们最终可以知道pod会被调度到node2节点

注：
1.当存在多个nodeSelectorTerms的时候，只有最后一个会生效，因为不能够包含多个对象
2.当存在多个matchExpressions列表，只需要满足其中一个即可将pod调度
3.当存在多个key值时，必须所有key值都要满足，否则会显示pending状态
4.当pod已经通过亲和性规则调度到指定的节点了，删除节点的标签，pod是不会被驱逐的

3. 节点软亲和

[root@master ~]# vi affinity_node.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx
spec:
  replicas: 3 
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution: #节点软亲和
          - weight: 20 #权重 范围为1-100
            preference:
              matchExpressions:
              - key: type
                operator: In
                values:
                - test1
                - test2 
              - key: num
                operator: Gt
                values:
                - "2"
          - weight: 30
            preference:
              matchExpressions:
              - key: type
                operator: In
                values:
                - test1
                - test2
              - key: num
                operator: Lt
                values:
                - "2"     

综上所写pod最终会被调度到node1节点，优先调度到node1节点，因为配置的权重较高

注：权重值高的优先调用，如果不满足在使用其他 然后在进行权重之间进行比对

三、podAffinity（pod亲和）podAntiAffinity（pod反亲和）

1. 测试环境准备

为节点打标签，在上面打标签不变，增加如下标签
[root@master ~]# kubectl label node master key=a
[root@master ~]# kubectl label node node2 key=a

[root@master ~]# kubectl get node --show-labels
NAME     STATUS   ROLES    AGE   VERSION   LABELS
master   Ready    master   12d   v1.18.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,key=a,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
node1    Ready    <none>   12d   v1.18.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux,num=c,type=test1
node2    Ready    <none>   12d   v1.18.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,key=a,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux,num=3,type=test2

master的标签有 key=a 
node1的标签有 type=test1 num=1
node2的标签有 key=a type=test2 num=3

根据具有相同键名键值标签的节点处于同一个拓扑域，我们就可以晓得
master和node2为同一个拓扑域
然后在使用系统默认的beta.kubernetes.io/arch标签，这样三个节点也为同一个拓扑域

2. pod亲和性

在写pod亲和性之前我们先运行如下的pod用于测试
[root@master ~]# kubectl get pods --show-labels
NAME    READY   STATUS    RESTARTS   AGE    LABELS
myapp   1/1     Running   0          19s    app=myapp

[root@master ~]# vi affinity_pod.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:#硬亲和
          - labelSelector:
              matchExpressions:
              - key: app #已经运行pod的标签
                operator: In
                values:
                - myapp
            topologyKey: key #拓扑域标签的键名

综上所写最终pod将会在node2和master节点之间进行调用，node1节点不会进行调度
上述yaml文件的意思是在key标签拓扑域中，如果存在标签为app=nginx的主机，那么就将该pod调度到该拓扑域的范围，没有则显示pending

3. pod反亲和性

[root@master ~]# vi affinity_pod.yaml                
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx
spec:
  replicas: 6 
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution: #软亲和
          - weight: 100  #权重
            podAffinityTerm:
              labelSelector:
                matchExpressions: 
                - key: app
                  operator: In
                  values:
                  - myapp
              topologyKey: key #拓扑域
      
 综上所写pod最终会优先调度到node1节点上，因为node2和master在同一个拓扑域中，且运行了标签为app=myapp的pod
pod的反亲和就是针对拓扑域来约束的，如果判断的pod在指定的拓扑域当中，那么就不优先调度该拓扑域中的pod，而会优先选择其他pod来进行调度

简而言之，反亲和就是调度到除了本身定义的拓扑域之外的节点