K8s--调度

一、简介

调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。kube-scheduler 是 Kubernetes 集群的默认调度器,并且是集群控制面的一部分。在做调度决定时需要考虑的因素包括:单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。
在这里插入图片描述

二、nodeName

nodeName 是节点选择约束的最简单方法,但一般不推荐。如果 nodeName 在 PodSpec 中指定了,则它优先于其他的节点选择方法。
使用 nodeName 来选择节点的一些限制:
如果指定的节点不存在则调度失败。
如果指定的节点没有资源来容纳 pod,则pod 调度失败。
云环境中的节点名称并非总是可预测或稳定的

默认情况下,由集群默认调度器统一调度,当某个节点处于ready状态时,运行pod可能会随机调度到该节点上:
在这里插入图片描述
通过指定nodeName的方式来干预集群的调度:

vim pod.yaml:
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: myapp:v1
  nodeName: server4

在这里插入图片描述

三、nodeSlector

可以给想要被调度的节点加上标签,并将nodeSelector字段添加到调度文件中,这样该节点将会被优先调度,这种方式的好处是只要有该标签的节点都可能会被调度,因此当一个节点挂掉之后如果其它节点也有用该标签则将会调度到另外一个节点上从而保证该pod的存活:

kubectl label nodes server3 disktype=ssd
cat pod.yml    %执行这个yml文件的时候如果没有与nodeSelector字段所匹配的节点,将会调度失败
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd    

在这里插入图片描述
在这里插入图片描述

kubectl get node --show-lables  %查看所有节点的标签 

在这里插入图片描述

四、亲和与反亲和性

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

注意:当有多个硬限时,pod将会被优先调度到之前调度到的有硬限的节点上

1.节点亲和

当有硬限有软限的时候将会被优先调度到既满足硬限又满足软限的节点上:
cat pod.yml 
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:   %定义硬限
           nodeSelectorTerms:
           - matchExpressions:
             - key: disktype
               operator: In
               values:
                 - ssd
                 - sata
      preferredDuringSchedulingIgnoredDuringExecution:  %定义软限
      - weight: 1
        preference:
          matchExpressions:
          - key: roles
            operator: In
            values:
            - nginx

在这里插入图片描述
在这里插入图片描述

kubectl lable node nodename disktype-  %删除节点上的标签

在这里插入图片描述

2.pod亲和与反亲和

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

pod亲和:

cat pod.yml:
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: myapp:v1
  affinity:             %优先与具有nginx标签的pod调度在同一个节点上
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - nginx
        topologyKey: kubernetes.io/hostname

在这里插入图片描述
pod反亲和:

cat pod.yml:
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: myapp:v1
  affinity:             %不与具有nginx标签的pod调度在同一个节点上
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - nginx
        topologyKey: kubernetes.io/hostname

在这里插入图片描述

五、Taints(污点)

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

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 设置,会直接被逐出。

在这里插入图片描述
删除污点:
在这里插入图片描述
设置容忍:

tolerations示例:
tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"
---
tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"

tolerations中定义的key、value、effect,要与node上设置的taint保持一直:
如果 operator 是 Exists ,value可以省略。
如果 operator 是 Equal ,则key与value之间的关系必须相等。
如果不指定operator属性,则默认值为Equal。
还有两个特殊值:
当不指定key,再配合Exists 就能匹配所有的key与value ,可以容忍所有污点。
当不指定effect ,则匹配所有的effect。
cat pod.yml: 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 10
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
      tolerations:
      - operator: "Exists"

在这里插入图片描述

六、其它调度

cordon 停止调度:
影响最小,只会将node调为SchedulingDisabled,新创建pod,不会被调度到该节点,节点原有pod不受影响,仍正常对外提供服务。
drain 驱逐节点:
首先驱逐node上的pod,在其他节点重新创建,然后将节点调为SchedulingDisabled。
delete 删除节点
最暴力的一个,首先驱逐node上的pod,在其他节点重新创建,然后,从master节点删除该node,master失去对其控制,如要恢复调度,需进入node节点,重启kubelet服务

// An highlighted block
var foo = 'bar';

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/nk298120/article/details/115123914
今日推荐