k8s调度

目录

nodeSelector 是节点选择约束的最简单推荐形式。

节点亲和性和反亲和性

pod 亲和性和反亲和性

Taints(污点)

---

调度器通过 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 在 PodSpec 中指定了，则它优先于其他的节点选择方法 

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

如果指定的节点不存在。

如果指定的节点没有资源来容纳 pod，则pod 调度失败。

云环境中的节点名称并非总是可预测或稳定的

nodeSelector 是节点选择约束的最简单推荐形式。

kubectl -n kube-system get pod
kubectl get node
cd pod/
ls
cd
kubectl get node

mkdir node
cd node/
ls
vim pod.yaml 添加 nodeSelector 字段到 pod 配置中
kubectl apply -f pod.yaml
kubectl get pod #可以看到一直处于pending,因为没有匹配的节点标签
kubectl get node --show-labels #查看节点标签
kubectl describe pod nginx
kubectl label nodes server3 disktype=ssd #添加pod所需的标签到server3
kubectl get pod #状态就绪
kubectl get node --show-labels #可以看到添加的标签
kubectl label nodes server3 disktype- #去除标签
kubectl get pod #状态还是running，标签只对pod就绪时有影响，一旦运行状态保持不变
kubectl delete -f pod.yaml
ls

 亲和性调度可以分为软策略和硬策略两种方式：

1.软策略就是如果现在没有满足调度要求的节点的话，pod就会忽略这条规则，继续完成调度过程

2.硬策略比较强硬，如果没有满足条件的节点的话，就不断重试直到满足条件为止。

亲和与反亲和 nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。

你可以发现规则是“软”/“偏好”，而不是硬性要求，因此，如果调度器无法满足该要求，仍然调度该 pod

你可以使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起

节点亲和性和反亲和性

1.requiredDuringSchedulingIgnoredDuringExecution     必须满足 2.preferredDuringSchedulingIgnoredDuringExecution    倾向满足 

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

nodeaffinity还支持多种规则匹配条件的配置如
 In：label 的值在列表内
 NotIn：label 的值不在列表内
 Gt：label 的值大于设置的值，不支持Pod亲和性
 Lt：label 的值小于设置的值，不支持pod亲和性
 Exists：设置的label 存在
 DoesNotExist：设置的 label 不存在

节点亲和性pod示例

vim pod.yaml #设定必须满足标签为disktype=ssd

kubectl apply -f pod.yaml
kubectl get pod
kubectl label nodes server4 disktype=ssd #server4上加标签
kubectl get pod #处于pending
kubectl get pod -o wide #调度到server4上
kubectl delete -f pod.yaml
kubectl label nodes server3 disktype=ssd #给server3上也加标签
kubectl apply -f pod.yaml
kubectl get pod
kubectl get pod -o wide #又调度到server3上
kubectl get node --show-labels
kubectl delete -f pod.yaml

vim pod.yaml #设定满足两者其一即可
kubectl apply -f pod.yaml
kubectl describe pod nginx #查看调度到server3
kubectl delete -f pod.yaml
kubectl label nodes server4 role=prod #节点加标签
kubectl get node --show-labels
kubectl apply -f pod.yaml
kubectl describe pod nginx #重新调度到server4

 

pod 亲和性和反亲和性

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

kubectl get pod
kubectl get pod --show-labels #查看已经运行的pod的标签

vim pod2.yaml
kubectl apply -f pod2.yaml
kubectl get pod -o wide #调度到同一个节点
kubectl delete -f pod2.yaml

pod亲和性示例

 pod反亲和性示例:

 vim pod2.yaml #设定反亲和性
kubectl apply -f pod2.yaml
kubectl get pod -o wide #调度到不同节点上

Taints(污点)

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

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

kubectl get node
kubectl describe nodes server2|grep Taint #查询server2上存在污点
kubectl delete -f pod2.yaml
kubectl delete -f pod.yaml
kubectl get pod
kubectl taint node server3 key1=v1:NoSchedule #使用命令 kubectl taint 给server3增加一个 taint
kubectl describe nodes server3|grep Taint 

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

NoSchedule：POD 不会被调度到标记为 taints 节点。

PreferNoSchedule：NoSchedule 的软策略版本。

NoExecute：该选项意味着一旦 Taint 生效，如该节点内正在运行的 POD 没有对应 Tolerate 设置，会直接被逐出。 

cd
cd pod/
ls
vim deploy.yml #部署nginx deployment
kubectl apply -f deploy.yml
kubectl get pod #运行3个pod
kubectl get pod -o wide #全部调度到server4上，因为server3上有污点
kubectl taint node server4 key2=v2:NoExecute #添加污点NoExecute
kubectl get pod -o wide #发现pod处于pending,无法调度

vim deploy.yml #在PodSpec中为容器设定容忍标签
kubectl apply -f deploy.yml
kubectl get pod
kubectl get pod -o wide #调度到server3

tolerations中定义的key、value、effect，要与node上设置的taint保持一直：
  如果 operator 是 Exists ，value可以省略。
  如果 operator 是 Equal ，则key与value之间的关系必须相等。
  如果不指定operator属性，则默认值为Equal。
  还有两个特殊值：
  当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。
  当不指定effect ，则匹配所有的effect

vim deploy.yml #设置忽略value
kubectl apply -f deploy.yml
kubectl get pod -o wide

vim deploy.yml #设置容忍所有污点
kubectl apply -f deploy.yml
kubectl get pod -o wide #所有都可以调度

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

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

kubectl cordon server4 #停止调度到server4
kubectl get node #将node调为SchedulingDisabled
kubectl delete -f deploy.yml
kubectl taint node server3 key1- #去除污点
kubectl taint node server4 key2-
vim deploy.yml #注释掉容忍
kubectl apply -f deploy.yml
kubectl get pod -o wide #只能调度到server3

drain 驱逐节点： 首先驱逐node上的pod，在其他节点重新创建，然后将节点调为SchedulingDisabled
kubectl drain server4 #驱离server4
kubectl drain server4 --ignore-daemonsets
kubectl delete nodes server4#下线节点
kubectl get node

在server4上重启kubelet

kubectl get node #可以看到server4又加入集群
kubectl get pod
vim deploy.yml #修改副本数为6
kubectl apply -f deploy.yml
kubectl get pod -o wide #server3和server4上都有调度
kubectl delete -f deploy.yml
kubectl get pod