TOC

调度器

    在Kubernetes集群系统之上的masteri节点有一个非常重要的组件,kube-scheduler,它内部有一个调度器程序,kube-scheduler是kube-apiserver的客户端,其主要作用在于注册并监听kube-apiserver上每一个Pod资源,并关注这个Pod资源的调度结果当中的属性字段是不是为空,Pod其中有一个字段会指明Pod被调度到哪一个目标节点上去了,那个字段如果为空,那么就说明还没调度完成,因此一旦通过kube-apiserver注册监听Pod,如果发现其指定的目标Pod的nodename字段为空的话,就开始视图由自己为此Pod从当前集群的众多节点当中选择一个最佳的节点,来运行此Pod,选定完以后,它就把这个选出的节点名放在,这个Pod.spec当中的nodename字段,并回存kube-apiserver,一旦存储到kube-apiserver之后,kube-apiserver会看到这个Pod被调度到某一个节点,接下来kube-apiserver会通知给这个节点的kubelet程序由kubelet负责去读取这个Pod的所有定义,而后调用本地的Docker引擎,将其运行起来;
    那么这众多节点当中,kube-scheduler从中挑选节点的策略是什么呢,它一定有一个评判标准,就像一些常见的负载均衡调度算法一样,根据不同的调度算法,可能每次挑选的后端节点是不同的,kube-scheduler也是这样的, 因此,在Kubernetes内部,有一个调度器,这个调度器可以受影响于很多来计算调度目标结果排序的方式;
    对于Kubernetes来讲,每次当一个新Pod来创建的时候,kube-scheduler一旦发现调度结果为空,也就是发现出一个未经调度的Pod资源时,此时,kube-scheduler就会基于自己的调度算法,将所有节点拿来做一个评估,评估完以后,从中选择一个最优的,而评估过程大体分为三个阶段;

    第一阶段(Predicate),预选阶段,先去评估哪些至少在基本条件上能满足此Pod的运行节点,什么是基本条件呢,比如说如果我们节点有污点的话,这Pod不能容忍污点,那么这些所有的不能容忍的污点就要被排除在外了,只能留下没有污点的或者此Pod能容忍的污点的节点,这叫预选,但预选中的节点应该有很多个,这很多个应该有一个是最佳的;
    第二阶段(Priority),优选阶段,通过优选函数拿到优选结果,如果依然有可能存在有多个,所谓优选就是评估运行此Pod,满足它运行需要的优先级,而这个优先级通畅是一个评分,是一个分值,这个分值如果正好有一个是最高的,那么这个结果就是已既定了,如果有多个最高分的节点,那么这个还需要随机挑选一个,进入第三阶段;
    第三阶段(Select), 随机挑选;
调度器基本工作流程
    对于预选,Kubernetes有很多预选器来帮忙完成这个节点是否符合Pod的基本要求,对于Predicate来讲,它是一个或者一组程序,会将Kubernetes之上的所有节点拿来,进行一次计算,如果其中有一组程序声明这个节点不符合运行此Pod的条件,那么这就被预选排除了,以此类推,这些左右节点都经过这一组Predicate进行评估之后,留下的都是至少能符合运行此Pod的基本条件;
    于是这些节点谁是最好的,因此就需要进入第二步,Priority也是有一组优先函数组成的,这个函数不像Predicate它合不合理,而评估的是这个节点和运行此Pod的评估分数,比如node1进来,进入第一个Priority函数计算得两分,进入第二个Priority函数计算得三分,最终所有的Priority函数的分值的和就是这个node节点的整体得分分值,而后基于得分进行排序,逆序排序;
    排完序之后,就看得分最高的有几个,然后会将得分最高的挑选出来,进入Select流程,进行随机挑选;

调度器的实现

    其实Kubernetes的调度器也是插件实现的,我们可以使用内建调度器叫default-scheduler来调度,用户也可以自定义调度器,并且在创建Pod时还可以指定使用什么调度器来调度Pod;
指定调度器:kubectl explain pods.spec.schedulerName
查看默认使用的调度器
    其实我们在创建Pod的时候,是没有指定调度器的,准入控制器会为我们补齐该字段,当我们未定义的时候,直接使用默认值;
# 挑选一个已创建的Pod查看调度器默认值
[root@node1 ~]# kubectl get pods -n dev  dev-pod -o yaml|grep schedulerName
  schedulerName: default-scheduler
节点过滤
    节点过滤其实有很多评估几个简单的示例解说如下;
Volumes Filters:如果某一个Pod要求要使用本地的临时存储,而且需要至少有20G的存储空间,正好所有节点当中有的节点有20G有的节点没有20G,那么没有20G的就会被排除掉;
Resources Filters:如果某一节点要求resource,CPU至少有四核,那么CPU也需要经过一次筛选;
Topology Filters:
预选策略
    自上而下,依次进行,源码地址:https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/algorithm/predicates/predicates.go;

CheckNodeCondition: 检查节点是否符合调度条件;
GeneralPredicates:
    HostName: 这种是判断Pod是否定义了pod.spec.hostname属性,若定义了,就在预选时,看看这些Node上是否存在相同主机名的Pod,若有,就排除该Node; 这可能是因为,某些Pod是需要有固定主机名,才会使用;
    PodFitsHostPorts: 此预选策略是判断 pods.spec.containers.ports.hostPort 属性是否定义了,若定义了就表示该Pod要绑定到Node上指定的Port上,这时在进行预选时,就要判断这个端口是否被占用了,若占用就会排除该Node;
    MatchNodeSeletctor:此预选策略会判断 pods.spec.nodeSelector 属性是否定义了,若定义了就根据Pod所定义的NodeSelector来选出匹配指定标签的Node;
    PodFitsResources: 此预选策略会判断 Node上是否符合运行Pod所需的最小空闲资源;
NoDiskConfict: 用于判断若Pod定义了存储卷,则要检查该存储卷在该Node上是否可用,若Node能满足Pod存储卷的使用需求,则表示此Node可用;
PodToleratesNodeTaints:检查Pod上的spec.tolerations可容忍的污点是否完全包含Node上定义的污点,若完全包含,则表示Pod能容忍该Node节点的污点,否则该Node不会通过预选;
PodToleratesNodeNoExecuteTaints;首先,污点并非单一属性,它有三种属性,NoExcute是污点的一种属性,此检查是,若Pod被调度到某Node上时,最初Node上没有Pod不能容忍的污点,但后来N,第二种是不接受,也就是检查此属性,此时Node会驱逐该Pod,让该Pod重新调度到新Node上;
CheckNodeLabelPresence:这是定义在选择Node时,检查Node上是否存在指定的标签,若存在则可调度。此规则默认不启用;
CheckServiceAffinity: 当我们需要创建一些Pod时,这些Pod都使用相同的Serivce,这时,若启用该预选策略,则将这些Pod优先调度到 已存在较多该Service下的Pod的Node上;
#下面三个默认启用,因为这三个是最大的三个云运营商;
MaxEBSVolumeCount:此预选策略是指若Pod需要使用亚马逊的EBS(弹性块存储服务),则检查该EBS是否已经达到最大运行挂载数39个,若没有,则表示还有存储空间可用;
MaxGCEPDVolumeCount: GCEPD:是Google的云环境中的持久存储,默认是16个;
MaxAzureDiskVolumeCount: 最大是16个;
CheckVolumeBinding:检查Node上是否存在以绑定 和 未绑定的PVC,若Node上有PVC,并且没有被绑定则能满足Pod运行的需求;
NoVolumeZoneConflict:它是在给定了区域限制的情况下,Zone在IDC机房是有限制的,他们通常会按房间,机柜,机架来划分范围,假如机架上有20台服务器,每2台一个区域,这个就是一个逻辑区域,此配置项的含义就是检查区域中Node上是否存在逻辑卷冲突;
CheckNodeMemoryPressure:检查Node上是否存在内存压力,即若某Node上已经出现内存紧张的情况了,那就不要在往它上面调度了;
CheckNodePIDPressure:检查Node上是否存在PID压力过大的情况,即若某Node上运行的进程过多,导致PID可能紧张,这时在选择调度时,也不会选择它;
CheckNodeDiskPressure:检查Node上是否存在磁盘使用压力过大的情况;
MatchInterPodAffinity:检查Node上是否满足Pod的亲和性,假如Pod是Nginx,它是要为Tomcat Pod做代理的,那么在调度tomcat Pod时,就会检查Node上是否有Nginx Pod,若有这个非常亲和的Pod则优先调度到该Node上; 
优选策略
    自上而下,依次优选,源码地址:https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler/algorithm/priorities;
LeastRequested:CPU和memory最少请求的资源,它就是由节点空闲资源,与节点容量比值计算得来,如果这个节点有8颗核心,现在已经分配了1个,那么已分配比例是八分之一,也就是7比1,每一个节点都依次这样进行评估,哪个节点的比值最小,那么就优先哪个节点(cpu(capacity-sum(requested))*10/capacity)+(memory(capacity-sum(requested))*10/capacity)/2;
BalancedResourceAllocation:CPU和内存资源的被占用率相近的胜出;目的是平衡节点资源的使用率;
NodePreferAvoidPods:节点注解信息"scheduler.alpha.kubernetes.io/preferAvoidPods";
TaintToleration:将Pod对象的spec.tolerations与节点的taints列表项进行匹配度检查,污点分值,匹配的条目越多得分越低;
SelectorSpreading:调度器将pod分散调度,尽可能将Pod分散到多个节点运行,如果此节点被之前同一个调度器已经调度到已选出的节点,那么尽量不在此节点再创建Pod;
InterPodAffinity:根据Pod间的亲和性;
NodeAffinity:根据节点亲和性;
MostRequested:根据最多被请求的节点,和LeastRequested是相反的,所以这个默认没有启用;
NodeLabel:根据节点标签;
ImageLocality:根据满足当前Pod对象需求的已有镜像的体积大小之和;
随机挑选
    当一个Pod被调度的时候,所有通过预选策略的node都会进行一些硬性条件检查,而后经过优选策略进行软性分值计算,而后通过分值进行排序,接下来进行选择阶段了,最高分胜出;

Kuberntes调度器

    任何时候我们所创建一个Pod时,都不可避免要被我们的kube-scheduler当中的default-scheduler进行调度,当然如果不想使用默认的的default-scheduler,那么Kubernetes也允许用户自定义kube-scheduler,并在创建Pod的时候指明调度器,而不使用default-scheduler,目前来讲,Kubernetes内部只有一个调度器,但是它支持插件式调度器,允许用户自定义调度器对接到已有的调度程序上,可被用户选择使用其他调度器;
    即便Pod的调度,是由default-scheduler来负责完成的,但我们还是可以在外部施加各种条件,来影响调度结果,比如我们的定义Pod时,在Pod的spec字段加上一个nodeName来影响它的调度结果,也可以使用nodeSeletor来指定只将此Pod运行在匹配到的node节点上,至少一个节点符合,如果没有任何节点被匹配,那么就会Pending,被挂起了,这都是一种硬性调度机制;
    也可以有一些柔性调度机制,比如Affinity,亲和性也分硬亲和和软亲和,硬亲和指的是,如果满足它的亲和性,它就可以把node作为调度节点,如果不满足,就直接排除,而软亲和指的是如果我们经过亲和性检测,发现没有一个节点符合这个亲和性,那么就随机亲和;
    当然我们也可以使用污点, 从上面描述的来看可以看出node都是等待着被选择,那么我们也可以赋予node的主动权,给node加上一个污点,如果节点不能容忍这个污点,那么就不会调度上面来,这就给了node主动控制权;
高级调度机制
    可以看出,用户可以自己在必要时,去施加在Pod上一些条件,或者施加在node上的一些控制机制,来确定Pod只能够或者更愿意调度于哪些节点,以及节点是否要挑选哪些Pod能够运行于当前节点,这些我们就称之为高级调度机制,如果我们把nodeName和nodeSelector排除在外的话,我们还有NodeAffinity,叫做node的亲和性,意思是Pod更愿意运行在哪些节点上;
    PodAffinity表示两个Pod能不能运行在同一个节点上,Pod和Pod之间可以不可以在一起,有亲和性表示应该在一起,反亲和那就是不能在一起,比如两个Pod不能运行在同一个节点上,但是这个一起可以是一个机房或者是一个机架,也可以是一个节点;
    还有一种高级调度机制,也就是我们可以允许节点以获取调度控制的主动权,让节点通过赋予自身污点,并通过Pod是否能容忍这些污点,来定义出它到底是允许该Pod运行在此节点上,还是驱离此Pod,那么这个时候,需要在两个维度上协同定义,首先Pod得有容忍度的定义,节点要有污点的定义,必要时Kubernetes也允许用户给节点打上污点,以避免节点多次被调度Pod运行;
nodeAffinity的生效方式
1、同事指定了nodeAffinity和nodeSeletor那么他们是“与”关系,即符合条件的Node需要同时满足两个条件;
2、为nodeAffinity同时指定多个nodeSelectorTerms时,各条目间取逻辑“或”关系,即满足一个条件即可;
3、同一个nodeSeletorTerms中的多个matchExpression存在逻辑“与”关系,即Node需要同时满足多个条件;
4、如果调度以及完成了,后来将节点的label删除了,导致这个节点不能再满足这个亲和性了,那么已调度的Pod不会被remove,这个亲和性仅仅发生在调度的过程当中,调度完成后label的变动将不再有任何影响;
5、对于软亲和来讲,可以指定weight权重,如果有多个preferredDuringSchedulingIgnoredDuringExecution,多个preferredDuringSchedulingIgnoredDuringExecution的权限可以不一样;
nodeAffinity
    节点亲和性,主要是定义Pod运行于哪个节点的亲和性,Pod更期望运行与哪种Pod;
硬限制:kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution  # 只能运行与满足这个亲和性的节点
软限制:kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution # 即使不满足不会不调度Pod,能满足亲和性就以亲和性为准,不能满足的时候以其他优选函数为准;
评估亲和程度语法:In、NotIn、Exists、DoesNotExist、Gt、Lt
示例
spec:
  affinity:
    nodeAffinity:  # 节点亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和,必须满足
        nodeSelectorTerms: # 节点选择
        - matchExpressions: # 选择表达式
          - key: kubernetes.io/e2e-az-name
            operator: In # 基于集合的标签选择器
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution: # 软亲和,尽量满足
      - weight: 1  # 这个判断权重为
        preference: # 定义亲和度
          matchExpressions: # 选择表达式
          - key: another-node-label-key
            operator: In # 基于集合的标签选择器
            values:
            - another-node-label-key

# 存在性判断
spec:
  containers:
  - name: dev-container
    image: ikubernetes/myapp:v1
  affinity:
    nodeAffinity:  # 节点亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和,必须满足
        nodeSelectorTerms: # 节点选择
        - matchExpressions: # 选择表达式
          - key: node-core-number # 定义核心数
            operator: Exists # 存在性判断
实战示例
    分别演示硬亲和性,和软亲和性;
# 使用硬限制定义Pod的affinity,只在CPU核心数大于2的节点上运行;
[root@node1 ~]# cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dev-pod
spec:
  containers:
  - name: dev-container
    image: ikubernetes/myapp:v1
  affinity:
    nodeAffinity:  # 节点亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和,必须满足
        nodeSelectorTerms: # 节点选择
        - matchExpressions: # 选择表达式
          - key: node-core-number # 定义核心数
            operator: Gt # 大于
            values: 
            - "2" # 2
[root@node1 ~]# kubectl apply -f pod.yaml 
pod/dev-pod created
# 可以看到没有一个node的labels符合我们定义的硬限制
[root@node1 ~]# kubectl get nodes --show-labels 
NAME            STATUS   ROLES    AGE   VERSION   LABELS
node1.cce.com   Ready    master   39d   v1.16.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1.cce.com,kubernetes.io/os=linux,node-role.kubernetes.io/master=
node2.cce.com   Ready    <none>   39d   v1.16.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2.cce.com,kubernetes.io/os=linux
node3.cce.com   Ready    <none>   39d   v1.16.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node3.cce.com,kubernetes.io/os=linux
# 查看此时Pod的状态
[root@node1 ~]# kubectl get pods 
NAME      READY   STATUS    RESTARTS   AGE
dev-pod   0/1     Pending   0          74s  # 等待状态
# 手动给node添加labels
[root@node1 ~]# kubectl label nodes node3.cce.com node-core-number=4
node/node3.cce.com labeled
# 当手动添加labels之后会立马进行调度
[root@node1 ~]# kubectl get pods --show-labels -o wide              
NAME      READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE   READINESS GATES   LABELS
dev-pod   1/1     Running   0          18s   10.244.2.11   node3.cce.com   <none>           <none>            <none>

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注