Kubernetes调度管理(上)

fldj
发布于 2022-9-6 11:56
浏览
0收藏

作者 | 老郑

来源 |运维开发故事(ID:mygsdcsf)

转载请联系授权(微信ID:wanger5354)

基本介绍
在日常工作中,每个机场都有调度室,用来管理飞机应该从哪里降落,停在什么地方。在Kubernetes也有这样的调度器,主要作用就是将Pod安排到合适的节点上。

Kubernetes中的调度器是kube-scheduler,工作流程如下:

  1. 在集群中所有Node中,根据调度算法挑选出可以运行该Pod的所有Node;
  2. 在上一步的基础上,再根据调度算法给筛选出的Node进行打分,筛选出分数最高的Node进行调度;
  3. 将Pod的spec.nodeName填上调度结果的Node名字;
    其原理图如下: 

Kubernetes调度管理(上)-鸿蒙开发者社区

由上图可知,Kubernetes的调度器核心是两个相互独立的控制循环。1、Informer Path其主要作用是启动一个Informer来监听Etcd中Pod,Node,Service等与调度器相关的API对象的变化。当一个Pod被创建出来后,就被通过Informer Handler将待调度的Pod放入调度队列中,默认情况下,Kubernetes的调度策略是一个优先级队列,并且当集群信息发生变化的时候,调度器还会对调度队列里的内容进行一些特殊操作。而且Kubernetes的默认调度器还负责对调度器缓存(scheduler cache)进行更新,以执行调度算法的执行效率。

2、Scheduler Path其主要逻辑是不断从队列中出一个Pod,然后调用Predicates进行过滤,然后得到一组Node(也就是可运行Pod的所有Node信息,这些信息都是来自scheduler cache),接下来调用Priorities对筛选出的Node进行打分,然后分数最高的Node会作为本次调度选择的对象。调度完成后,调度器需要将Pod的spec.nodeName的值修改为调度的Node名字,这个步骤称为Bind。

但是在Bind阶段,Kubernetes默认调度器只会更新scheduler cache中的信息,这种基于乐观假设的API对象更新方式被称为Assume。在Assume之后,调度器才会向API Server发起更新Pod的请求,来真正完成Bind操作。如果本次Bind失败,等到scheduler cache更新之后又会恢复正常。

正是由于有Assume的原因,当一个Pod完成调度需要在某个Node节点运行之前,kubelet还会进行一步Admit操作来验证该Pod是否能够运行在该Node上,作为kubelet的二次验证。

常用的预算策略有:

  • CheckNodeCondition
  • GeneralPredication:
    HostName, PodFitsHostPort, MatchNodeSelector, PodFitsResources
  • NoDiskConflict
    优先级和抢占机制
    正常情况下,当一个Pod调度失败后,它会被搁置起来,直到Pod被更新,或者集群状态发生变化,调度器才会对这个Pod进行重新调度。但是有的时候我们不希望一个高优先级的Pod在调度失败就被搁置,而是会把某个Node上的一些低优先级的Pod删除,来保证高优先级的Pod可以调度成功。

Kubernetes中优先级是通过ProrityClass来定义,如下:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for high priority service pods only."

其中的value就是优先级数值,数值越大,优先级越高。优先级是一个32bit的整数,最大值不超过10亿,超过10亿的值是被Kubernetes保留下来作为系统Pod使用的,就是为了保证系统Pod不会被抢占。另外如果globalDefault的值设置为 true的话表明这个PriorityClass的值会成为系统默认值,如果是false就表示只有在申明这个PriorityClass的Pod才会拥有这个优先级,而对于其他没有申明的,其优先级为0。

如下定义Pod并定义优先级:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

上面的PriotiryClassName就是定义我们的PriorityClass,当这个Pod提交给Kubernetes之后,Kubernetes的PriorityAdmissionController会自动将这个Pod的spec.priority字段设置为我们定义的值。而当这个Pod拥有这个优先级之后,高优先级的Pod就可能比低优先级的Pod先出队,从而尽早完成调度。

而当一个高优先级的Pod调度失败后,其抢占机制就会被触发,这时候调度器就会试图从当前的集群中寻找一个节点,使得这个节点上的一个或多个低优先级的Pod被删除,然后这个高优先级的Pod就可以被调度到这个节点上。当抢占发生时,这个高优先级Pod并不会立即调度到即将抢占的节点上,调度器只会将这个Pod的spec.nominatedNodeName的值设置为被抢占节点的Node名字,然后这个Pod会重新进入下一个调度周期,然后会在这个周期内决定这个Pod被调度到哪个节点上。在这个重新调度期间,如果有一个更高的优先级Pod也要抢占这个节点,那么调度器就会清空原Pod的nominatedNodeName的值,而更高优先级的Pod将会抢占这个值。

实现原理:Kubernetes用两个队列来实现抢占算法:ActiveQ和unschedulableQ。

  1. ActiveQ:凡是在ActiveQ里的Pod,都是下一个周期需要调度的对象,所以当Kubernetes创建一个新的Pod,这个Pod就会被放入ActiveQ里;
  2. unschedulableQ:专门用来存放调度失败的Pod;
    那么如果一个Pod调度失败,调度器就会将其放入unschedulableQ里,然后调度器会检查这个调度失败的原因,分析并确认是否可以通过抢占来解决此次调度问题,如果确定抢占可以发生,那么调度器就会把自己缓存的所有信息都重新复制一份,然后使用这个副本来模拟抢占过程。如果模拟通过,调度器就会真正开始抢占操作了:

调度器会检查牺牲者列表,清空这些Pod所携带的nominatedNodeName字段;
调度器会把抢占者的nominatedNodeName的字段设置为被抢占的Node名字;
调度器会开启Goroutine,同步的删除牺牲者;
接下来调度器就会通过正常的调度流程,把抢占者调度成功。在这个过程中,调度器会对这个Node,进行两次Predicates算法:

假设上述抢占者已经运行在这个节点上,然后运行Predicates算法;
调度器正常执行Predicates算法;
只有上述者两个都通过的情况下,这个Node和Pod才会被 绑定。

高级调度
上面介绍的是Kubernetres默认的调度策略,有时候默认的调度策略不能满足我们的需求,比如想把Pod调度到指定的节点,或者不让某些节点调度Pod。这时候就要用到更高级的调度策略,主要有如下几种:

  • nodeSelector
  • nodeName
  • nodeAffinity
  • podAffinity
  • podAntiAffinity
  • 污点调度
    nodeSelector
    nodeSelector也可以叫做节点选择器,其原理是通过在节点上定义label标签,然后Pod中指定选择这些标签,让Pod能够调度到指定的节点上。

比如给kk-node01指定env=uat标签,命令如下:

$ kubectl label nodes kk-node01 env=uat

现在在Pod的YAML清单中配置nodeSelector,如下:

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  nodeSelector:
    env: uat

这样,该Pod就会调度到kk-node01节点上,如果该Pod指定为env=prod,则调度不到kk-node01节点。

nodeName
nodeName也是节点选择器,和nodeSelector不同之处在于nodeName是直接指定节点名,这属于强调度,定义方式如下:

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodename
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  nodeName: kk-node01     # 节点名字

nodeAffinity
nodeAffinity叫做节点亲和性调度,其调度方式比nodeSelector和nodeName更强大。

目前,nodeAffinity支持两种调度策略:

  • preferredDuringSchedulingIgnoredDuringExecution
  • requiredDuringSchedulingIgnoredDuringExecution
    preferredDuringSchedulingIgnoredDuringExecution表示如果有Node匹配,则优先调度到该Node,如果没有,可以根据配置调度到其他节点。requiredDuringSchedulingIgnoredDuringExecution则表示必须满足条件的节点才允许调度。

定义preferredDuringSchedulingIgnoredDuringExecution的例子如下:

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-preferred
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - preference:
          matchExpressions:
          - key: disktype
            operator: In
            values: ["ssd", "harddisk"]
        weight: 60

requiredDuringSchedulingIgnoredDuringExecution的例子如下:

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-required
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values: ["ssd", "harddisk"]

其中,operator支持In,NotIn, Exists, DoesNotExist. Gt, and Lt。

podAffinity
上面介绍的nodeSelector,nodeName,nodeAffinity都是针对节点的,下面介绍的podAffinity和podAntiAffinity则是针对Pod。

podAffinity表示Pod亲和性调度,意识就是把Pod调度到与它比较紧密的Pod上,如下:

apiVersion: v1
kind: Pod
metadata:
  name: fronted
  labels:
    app: myapp
    row: fronted
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: db
    row: backend
spec:
  containers:
  - name: db
    image: busybox
    imagePullPolicy: IfNotPresent
    command:
    - "/bin/sh"
    - "-c"
    - "sleep 3600"
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["myapp"]
        topologyKey: kubernetes.io/hostname

这表示把后端pod和前端pod调度在一起。

podAffinity也有preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution,也就是硬亲和和软亲和,其使用情况和nodeAffinity一样。

分类
标签
已于2022-9-6 11:56:37修改
收藏
回复
举报
回复
    相关推荐