一、前言

Scheduler本质是Kubernetes中的一个静态Pod。

Scheduler作用：决定哪个Pod被调度到哪个Node上。

二、kubectl命令对节点操作 Taint 属性

kubectl命令对节点操作 taint 属性
yaml文件：yaml文件对pod操作 tolerations 属性
kubectl对节点的unschedulable错误

2.1 kubectl命令对节点操作 Taint 属性

给主节点打上污点，不允许主节点分配pod

将master节点设置为NoScheduler,使用kubeadm安装集群初始master节点就是这个

解释：在主节点上执行kubectl taint打污点就是主节点不想要pod，除非在yaml中指定容忍

## 查看节点
kubectl get nodes

## 查看污点(有污点)  （是grep Taint ，不是grep taint，别搞错了）
kubectl describe node w1 | grep Taint

## 去除污点  （返回值 node/w1 untainted）
kubectl taint nodes --all node-role.kubernetes.io/master-

## 查看污点(没有污点了) 
kubectl describe node w1 | grep Taint

## 重新加上污点  （返回值 node/w1 tainted）
kubectl taint nodes w1 special=true:NoSchedule 

## 查看污点(又有污点了)
kubectl describe node w1 | grep Taint

## 删除污点
kubectl taint nodes --all special:NoSchedule-
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

小结：
添加污点的方式：kubectl taint nodes node1 key=value:NoSchedule
删除污点的方式：kubectl taint nodes node1 key:NoSchedule-
kubectl describe node node-name | grep taint 查看污点

参考资料：https://blog.csdn.net/weixin_42495873/article/details/103364868
参考资料：https://blog.csdn.net/hefashion0190/article/details/122637074
参考资料：https://blog.csdn.net/zhaikaiyun/article/details/104523637

2.2 yaml文件：yaml文件对pod操作 tolerations 属性

tolerations 是 yaml 文件中的一个属性，Taint 是 Node节点的一个属性，Scheduler就是为了完成决定将哪个pod被调度到node上，tolerations 和 Taint 的解释如下：

想要分配到主节点：要么主节点去掉污点 ，要么yaml 配置容忍，两种居其一就好

想不要分配到主节点：同时满足 “保持默认主节点不去掉污点” 并且 “保持默认 yaml 中不配置容忍”，两个有一个就可以分配到主节点了

yaml文件中配置tolerations，如下图：

2.3 节点操作：节点的unschedulable错误

执行 kubectl get nodes -o wide 这条命名，一般都是Ready或者NotReady，但是有的时候会看到node中出现UnSchedulable错误。

两个开发技巧：
kubectl get nodes 变成 kubectl get nodes -o wide，多了 -o wide，这样可以看到每个节点的内网ip
kubectl get pod 变成 kubectl get pod -o wide ，多了一个 -o wide，这样可以看到每个pod被调度到哪个node上

报错如下：kubectl describe pod pod-name -n ns-name 看到错误是 were unschedulable，kubectl get nodes看到唯一的 w1 节点是 SchedulingDisabled 错误，然后 kubectl describe nodes w1 看到 Taints

解决方案两句
kubectl taint nodes --all node-role.kubernetes.io/master-
kubectl patch nodes w1 --patch '{"spec":{"unschedulable": false}}'
1
2
3

第一步，执行 kubectl taint nodes --all node-role.kubernetes.io/master- 去掉污点

去掉了一个污点，还有一个污点，且Unschedule 仍然为true

第二步，执行 kubectl patch nodes w1 --patch '{"spec":{"unschedulable": false}}' 表示可以使用被调度

参考资料：https://blog.csdn.net/echo245/article/details/119011043

2.4 节点小结：kubectl describe node w1 查看节点与scheduler相关的三个属性

三个属性： Taint Unschedulable Labels

对于 Labels 属性，表示对 node 打上一个标签
对于 Taint 属性，不为 none 就是有污点
对于 Unschedulable 属性，不为false，就是表示该节点不允许调度

三、yaml文件将pod调度到指定node节点的两种方案

yaml文件将pod调度到指定node节点，存在两种方案：
(1) Pod.spec.nodeName (deployment.template.spec.nodeName)
(2) Pod.spec.nodeSelector (deployment.template.spec.nodeSelector)
这两种方式都可以指定分配到当前pod yaml，分配到哪个node上。

Pod.spec.nodeName + node节点需要设置为对应名称 【直接选择节点名】
Pod.spec.nodeSelector + node节点需要设置为对应的label 【给节点打上标签+yaml里面添加nodeSelector选择器】

Pod.spec.nodeName将 Pod 直接调度到指定的 Node 节点上，其底层原理是：会跳过 Scheduler 的调度策略，该匹配规则是强制匹配，这种方式的缺点写成的 yaml 不具备模板的通用性(类似于绝对路径)，因为每个集群的节点的名称是不同的（需要对节点重命名）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      nodeName: node1 # 关键的代码在于这里 Pod.spec.nodeName (deployment.template.spec.nodeName)
      containers:
      - name: myweb
        image: nginx
        ports:
        - containerPort: 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Pod.spec.nodeSelector：通过 kubernetes 的 label-selector 机制选择节点，底层原理是由调度器调度策略匹配 label，而后调度 Pod 到目标节点，该匹配规则属于强制约束，这种方式也不具备迁移性（需要对节点打标签）

# 先给节点node1打个标签
kubectl label nodes worker node1 key=web1
1
2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      nodeSelector:
        key: web1 #关键的代码在这里Pod.spec.nodeSelector(deployment.template.spec.nodeSelector)
      containers:
      - name: myweb
        image: nginx
        ports:
        - containerPort: 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

参考资料：https://blog.csdn.net/qq_39122146/article/details/110483253

四、 Pod和Node都有一个亲和力属性

4.1 Node的亲和力

对于一个 nodes 如下：

如果这里有一个 Pod，如下：

4.2 Pod的亲和力

上面是node亲和力，也可以有Pod亲和力，如下：

affinity: 
  podAffinity: 
    requiredDuringSchedulingIgnoredDuringExecution: 
    - labelSelector: 
        matchExpressions: 
        - key: app 
          operator: In 
          values: 
          - k8s 
      topologyKey: kubernetes.io/hostname
1
2
3
4
5
6
7
8
9
10

表示的含义是：required当前的pod创建，要能够找到有另外的pod app=k8s 和它在同一个node上。

五、尾声

Kubernetes Scheduler全解析，完成了。