企业项目实战k8s篇（十一）kubernetes调度

一.kubernetes调度概述

调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。

kube-scheduler 是 Kubernetes 集群的默认调度器，并且是集群控制面的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。

在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。

默认策略可以参考：https://kubernetes.io/zh/docs/concepts/scheduling/kube-scheduler/

调度框架：https://kubernetes.io/zh/docs/concepts/configuration/scheduling-framework/

二.nodename节点选择约束

nodeName 是节点选择约束的最简单方法，但一般不推荐。如果 nodeName 在 PodSpec 中指定了，则它优先于其他的节点选择方法。

使用 nodeName 来选择节点的一些限制：

• 如果指定的节点不存在。
• 如果指定的节点没有资源来容纳 pod，则pod 调度失败。
• 云环境中的节点名称并非总是可预测或稳定的。

脚本内容，指定nodename server2

[root@server1 schedu]# cat pod1.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:

  - name: nginx
    image: nginx
      nodeName: server2

执行脚本,nginx部署在server2上

[root@server1 schedu]# kubectl  apply  -f pod1.yml 
pod/nginx created
[root@server1 schedu]# kubectl  get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          5s
[root@server1 schedu]# kubectl  get pod  -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP               NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          19s     10.244.179.115   server2   <none>           <none>

三.nodeSelector节点选择约束

脚本内容，指定标签disktype=ssd，具有标签内容的节点可以部署

[root@server1 schedu]# vim pod2.yml
[root@server1 schedu]# kubectl  delete  pod nginx
pod "nginx" deleted
[root@server1 schedu]# vim pod
pod1.yml  pod2.yml  
[root@server1 schedu]# vim pod2.yml 
[root@server1 schedu]# cat pod2.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:

  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
      nodeSelector:
    disktype: ssd

执行脚本，查看pod，由于未识别到指定标签节点，处于pending状态，

[root@server1 schedu]# kubectl  apply  -f pod2.yml 
pod/nginx created
[root@server1 schedu]# kubectl  get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   0/1     Pending   0          5s

为server2添加标签，查看pod，部署成功

[root@server1 schedu]# kubectl label nodes server2 disktype=ssd
node/server2 labeled

[root@server1 schedu]# kubectl  get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          20s

四.亲和与反亲和

亲和与反亲和

• nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。
• 你可以发现规则是“软”/“偏好”，而不是硬性要求，因此，如果调度器无法满足该要求，仍然调度该 pod
• 你可以使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。

1.节点亲和

• requiredDuringSchedulingIgnoredDuringExecution 必须满足
• preferredDuringSchedulingIgnoredDuringExecution 倾向满足

IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。

nodeaffinity还支持多种规则匹配条件的配置如

• In：label 的值在列表内
• NotIn：label 的值不在列表内
• Gt：label 的值大于设置的值，不支持Pod亲和性
• Lt：label 的值小于设置的值，不支持pod亲和性
• Exists：设置的label 存在
• DoesNotExist：设置的 label 不存在

参考：https://kubernetes.io/zh/docs/concepts/configuration/assign-pod-node/

节点反亲和

脚本内容，指定pod node-affinity不在server4上部署

[root@server1 schedu]# cat pod3.yml 
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  containers:

  - name: nginx
    image: nginx
    affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: kubernetes.io/hostname
               operator: NotIn
               values:
               - server4
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd 

执行脚本，查看node-affinity部署于server2

[root@server1 schedu]# kubectl apply  -f pod3.yml 
pod/node-affinity created
[root@server1 schedu]# kubectl  get pod
NAME            READY   STATUS    RESTARTS   AGE
node-affinity   1/1     Running   0          8s
[root@server1 schedu]# kubectl  get pod -o wide
NAME            READY   STATUS    RESTARTS   AGE     IP               NODE      
node-affinity   1/1     Running   0          15s     10.244.179.117   server2   <none>           <none>

节点亲和

脚本内容，指定pod node-affinity在server4上部署

[root@server1 schedu]# cat pod3.yml 
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  containers:

  - name: nginx
    image: nginx
    affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: kubernetes.io/hostname
               operator: In
               values:
               - server4
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd 

执行脚本，查看node-affinity部署于server4

[root@server1 schedu]# kubectl  apply  -f pod3.yml 
pod/node-affinity created
[root@server1 schedu]# kubectl  get pod -o wide
NAME            READY   STATUS    RESTARTS   AGE     IP               NODE      NOMINATED NODE   READINESS GATES
node-affinity   1/1     Running   0          5s      10.244.22.61     server4   <none>           <none> 

2.pod亲和与反亲和

pod 亲和性和反亲和性

• podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题（拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的cluster、zone等。）
• podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
• Pod 间亲和与反亲和在与更高级别的集合（例如 ReplicaSets，StatefulSets，Deployments 等）一起使用时，它们可能更加有用。可以轻松配置一组应位于相同定义拓扑（例如，节点）中的工作负载。

pod亲和

脚本内容，设置nginx与mysql为pod亲和，即二者需要部署在同一节点上

[root@server1 schedu]# cat pod4.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  containers:
  - name: mysql
    image: mysql
    env:
     - name: "MYSQL_ROOT_PASSWORD"
       value: "westos"
      affinity:
      podAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - nginx
          topologyKey: kubernetes.io/hostname

执行脚本，mysql与nginx均位于server2

[root@server1 schedu]# kubectl apply  -f pod4.yml 
pod/nginx created
pod/mysql created
[root@server1 schedu]# kubectl  get pod -o wide
NAME            READY   STATUS    RESTARTS   AGE     IP               NODE      NOMINATED NODE   READINESS GATES
mysql           1/1     Running   0          11s     10.244.179.125   server2   <none>           <none>
nginx           1/1     Running   0          11s     10.244.179.124   server2   <none>           <none>

pod反亲和

脚本内容，设置nginx与mysql为pod反亲和，即二者需要部署在不同节点上

[root@server1 schedu]# cat pod4.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  containers:
  - name: mysql
    image: mysql:5.7
    env:
     - name: "MYSQL_ROOT_PASSWORD"
       value: "westos"
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - nginx
        topologyKey: kubernetes.io/hostname

执行脚本，mysql与nginx分别位于server4和server2

[root@server1 schedu]# kubectl apply -f pod4.yml 
pod/nginx unchanged
pod/mysql created

[root@server1 schedu]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP               NODE      NOMINATED NODE   READINESS GATES
mysql   1/1     Running   0          36s     10.244.22.63     server4   <none>           <none>
nginx   1/1     Running   0          7m8s    10.244.179.64    server2   <none>           <none>

五.Taints(污点)

1.Taints(污点)简介

NodeAffinity节点亲和性，是Pod上定义的一种属性，使Pod能够按我们的要求调度到某个Node上，而Taints则恰恰相反，它可以让Node拒绝运行Pod，甚至驱逐Pod。

Taints(污点)是Node的一个属性，设置了Taints后，所以Kubernetes是不会将Pod调度到这个Node上的，于是Kubernetes就给Pod设置了个属性Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去。

如Kubernetes集群主机，就是被设置了污点，因此一般部署pod时候不选择该节点为部署节点
查看matser的污点 master:NoSchedule

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

可以使用命令 kubectl taint 给节点增加一个 taint：

• $ kubectl taint nodes node1 key=value:NoSchedule //创建
• $ kubectl describe nodes server1 |grep Taints //查询
• $ kubectl taint nodes node1 key:NoSchedule- //删除

其中[effect] 可取值： [ NoSchedule | PreferNoSchedule | NoExecute ]

• NoSchedule：POD 不会被调度到标记为 taints 节点。
• PreferNoSchedule：NoSchedule 的软策略版本。
• NoExecute：该选项意味着一旦 Taint 生效，如该节点内正在运行的 POD 没有对应 Tolerate 设置，会直接被逐出。

2.Nodename可以无视任何污点

设置指定nodename： server1 上部署，server1为集群master

[root@server1 schedu]# cat pod1.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: server1

server1污点

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

查看pod，已经部署在server1，说明nodename可以掩盖污点

[root@server1 schedu]# kubectl  get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          94s   10.244.116.142   server1   <none>  

3.标签方式选择node

[root@server1 schedu]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 0/1 Pending 0 13s
脚本内容，指定标签 roles=master节点安装

[root@server1 schedu]# cat pod1.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    roles: master

授予server1 标签

[root@server1 schedu]# kubectl label nodes server1 roles=master
node/server1 labeled

执行脚本，查看pod部署，处于pending状态，说明污点优先级高于标签选择

[root@server1 schedu]# kubectl  get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
nginx   0/1     Pending   0          13s   <none>   <none>   <none>           <none>

删除标签

[root@server1 schedu]# kubectl label nodes server2 roles-
node/server2 labeled

4.容忍标签

tolerations中定义的key、value、effect，要与node上设置的taint保持一直：

• 如果 operator 是 Exists ，value可以省略。
• 如果 operator 是 Equal ，则key与value之间的关系必须相等。
• 如果不指定operator属性，则默认值为Equal。

还有两个特殊值：

• 当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。
• 当不指定effect ，则匹配所有的effect

NoSchedule

设置sevrer2 taint key=value:NoSchedule

[root@server1 schedu]# kubectl  taint nodes server2 key=value:NoSchedule
node/server2 tainted

测试部署,由于server2有污点，部署在server4

[root@server1 schedu]# kubectl  get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          8s    10.244.22.4   server4   <none>           <none>

设置容忍标签，容忍effect: "NoSchedule"

[root@server1 schedu]# cat pod1.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    roles: master
  tolerations:
  - operator: "Exists"
    effect: "NoSchedule"

执行脚本，为server2添加rules=master，查看到nginx部署到server2，容忍标签生效

[root@server1 schedu]# kubectl  apply  -f pod1.yml 
pod/nginx created
[root@server1 schedu]# kubectl label nodes server2 roles=master
node/server2 labeled
[root@server1 schedu]# kubectl  get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          43s   10.244.179.70   server2   <none>           <none>
[root@server1 schedu]# 

污点注销

[root@server1 schedu]# kubectl taint nodes server2 key:NoSchedule-
node/server2 untainted

NoExecute

查看pod，分别部署于server2和server4

[root@server1 schedu]# kubectl  get pod -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
myapp-deployment-67f8c948cf-5l5vd   1/1     Running   0          8s    10.244.179.71   server2   <none>           <none>
myapp-deployment-67f8c948cf-zffpv   1/1     Running   0          8s    10.244.179.74   server2   <none>           <none>
myapp-deployment-67f8c948cf-zhzmm   1/1     Running   0          8s    10.244.22.5     server4   <none>           <none>
nginx                               1/1     Running   0          13m   10.244.179.70   server2   <none>           <none>
nginx-deployment-6456d7c676-8lc4p   1/1     Running   0          8s    10.244.179.75   server2   <none>           <none>
nginx-deployment-6456d7c676-9jhdv   1/1     Running   0          8s    10.244.22.3     server4   <none>           <none>
nginx-deployment-6456d7c676-znjfr   1/1     Running   0          8s    10.244.22.6     server4   <none>           <none>

给Server2节点打上taint： key1=v1:NoExecute

kubectl taint node  server2 key1=v1:NoExecute
node/server1 tainted

可以看到server1上的Pod被驱离：

[root@server1 schedu]# kubectl  get pod -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
myapp-deployment-67f8c948cf-h6zmg   1/1     Running   0          15s   10.244.22.8    server4   <none>           <none>
myapp-deployment-67f8c948cf-m886n   1/1     Running   0          15s   10.244.22.13   server4   <none>           <none>
myapp-deployment-67f8c948cf-zhzmm   1/1     Running   0          47s   10.244.22.5    server4   <none>           <none>
nginx-deployment-6456d7c676-9jhdv   1/1     Running   0          47s   10.244.22.3    server4   <none>           <none>
nginx-deployment-6456d7c676-rrbf2   1/1     Running   0          15s   10.244.22.7    server4   <none>           <none>
nginx-deployment-6456d7c676-znjfr   1/1     Running   0          47s   10.244.22.6    server4   <none>           <none>

在PodSpec中为容器设定容忍标签：

 tolerations:
   - key: "key1"
     operator: "Equal"
     value: "v1"
     effect: "NoExecute"

为Pod设置容忍后会，server1又可以运行Pod了。

[root@server1 schedu]# kubectl  apply  -f pod1.yml 
pod/nginx created
[root@server1 schedu]# kubectl  get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          6s    10.244.179.72   server2   <none>           <none>

5.cordon、drain、delete

影响Pod调度的指令还有：cordon、drain、delete，后期创建的pod都不会被调度到该节点上，但操作的暴力程度不一样。

cordon 停止调度

影响最小，只会将node调为SchedulingDisabled，新创建pod，不会被调度到该节点，节点原有pod不受影响，仍正常对外提供服务。

$ kubectl cordon server3

$ kubectl  get node
NAME      STATUS                     ROLES    AGE   VERSION
server1   Ready                      <none>   29m   v1.17.2
server2   Ready                      <none>   12d   v1.17.2
server3   Ready,SchedulingDisabled   <none>   9d    v1.17.2

$ kubectl uncordon server3 		//恢复

drain 驱逐节点

首先驱逐node上的pod，在其他节点重新创建，然后将节点调为SchedulingDisabled。
$ kubectl drain server3

node/server3 cordoned

evicting pod "web-1"
evicting pod "coredns-9d85f5447-mgg2k"
pod/coredns-9d85f5447-mgg2k evicted
pod/web-1 evicted
node/server3 evicted

$ kubectl uncordon server3

delete 删除节点

最暴力的一个，首先驱逐node上的pod，在其他节点重新创建，然后，从master节点删除该node，master失去对其控制，如要恢复调度，需进入node节点，重启kubelet服务

$ kubectl delete node server3
```# systemctl restart kubelet		//基于node的自注册功能,恢复使用

```powershell
# systemctl restart kubelet		//基于node的自注册功能,恢复使用