5.pod调度

写在前面

上一篇文章资源管理和服务质量初步介绍了kubernetes中的resource资源调度和服务质量Qos,介绍了kubernetes中如何定义pod的资源和资源调度,以及设置resource之后的优先级别Qos,接下来介绍pod的调度机制。

1. Pod调度

1.1 pod调度概述

kubernets是容器编排引擎,其中最主要的一个功能是容器的调度,通过kube-scheduler实现容器的完全自动化调度,调度周期分为:调度周期Scheduling Cycle和绑定周期Binding Cycle,其中调度周期细分为过滤filter和weight称重,按照指定的调度策略将满足运行pod节点的node赛选出来,然后进行排序;绑定周期是经过kube-scheduler调度优选的pod后,由特定的node节点watch然后通过kubelet运行。

imgPod调度机制

过滤阶段包含预选Predicate和scoring排序,预选是筛选满足条件的node,排序是最满足条件的node打分并排序,预选的算法包含有:

  • CheckNodeConditionPred 节点是否ready
  • MemoryPressure 节点内存是否压力大(内存是否足够)
  • DiskPressure 节点磁盘压力是否大(空间是否足够)
  • PIDPressure 节点Pid是否有压力(Pid进程是否足够)
  • GeneralPred 匹配pod.spec.hostname字段
  • MatchNodeSelector 匹配pod.spec.nodeSelector标签
  • PodFitsResources 判断resource定义的资源是否满足
  • PodToleratesNodeTaints 能容忍的污点pod.spec.tolerations
  • CheckNodeLabelPresence
  • CheckServiceAffinity
  • CheckVolumeBinding
  • NoVolumeZoneConflict

过滤条件需要检查node上满足的条件,可以通过kubectl describe node node-id方式查看,如下图:

imgnode调度条件condition

优选调度算法有:

  • least_requested 资源消耗最小的节点
  • balanced_resource_allocation 各项资源消耗最均匀的节点
  • node_prefer_avoid_pods 节点倾向
  • taint_toleration 污点检测,检测有污点条件的node,得分越低
  • selector_spreading 节点selector
  • interpod_affinity pod亲和力遍历
  • most_requested 资源消耗最大的节点
  • node_label node标签

1. 2 指定nodeName调度

nodeName是PodSpec中的一个字段,可以通过pod.spec.nodeName指定将pod调度到某个具体的node节点上,该字段比较特殊一般都为空,如果有设置nodeName字段,kube-scheduler会直接跳过调度,在特定节点上通过kubelet启动pod。通过nodeName调度并非是集群的智能调度,通过指定调度的方式可能会存在资源不均匀的情况,建议设置Guaranteed的Qos,防止资源不均时候Pod被驱逐evince。如下以创建一个pod运行在node-3上为例:

  1. 编写yaml将pod指定在node-3节点上运行

    [root@node-1 demo]# cat nginx-nodeName.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx-run-on-nodename
    annotations:
    kubernetes.io/description: "Running the Pod on specific nodeName"
    spec:
    containers:
    - name: nginx-run-on-nodename
    image: nginx:latest
    ports:
    - name: http-80-port
      protocol: TCP
      containerPort: 80 
    nodeName: node-3       #通过nodeName指定将nginx-run-on-nodename运行在特定节点node-3
    
  2. 运行yaml配置使之生效

    [root@node-1 demo]# kubectl apply -f nginx-nodeName.yaml 
    pod/nginx-run-on-nodename created
    
  3. 查看确认pod的运行情况,已运行在node-3节点

    [root@node-1 demo]# kubectl get pods nginx-run-on-nodename -o wide 
    NAME                    READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
    nginx-run-on-nodename   1/1     Running   0          6m52s   10.244.2.15   node-3   <none>           <none>
    

1.2. 通过nodeSelector调度

nodeSelector是PodSpec中的一个字段nodeSelector是最简单实现将pod运行在特定node节点的实现方式其通过指定key和value键值对的方式实现需要node设置上匹配的Labels节点调度的时候指定上特定的labels即可如下以node-2添加一个app:web的labels调度pod的时候通过nodeSelector选择该labels
  1. 给node-2添加labels

    [root@node-1 demo]# kubectl label node node-2 app=web
    node/node-2 labeled
    
  2. 查看校验labels设置情况,node-2增加多了一个app=web的labels

    [root@node-1 demo]# kubectl get nodes --show-labels 
    NAME     STATUS   ROLES    AGE   VERSION   LABELS
    node-1   Ready    master   15d   v1.15.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,node-role.kubernetes.io/master=
    node-2   Ready    <none>   15d   v1.15.3   app=web,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-2,kubernetes.io/os=linux
    node-3   Ready    <none>   15d   v1.15.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-3,kubernetes.io/os=linux
    
  3. 通过nodeSelector将pod调度到app=web所属的labels

    [root@node-1 demo]# cat nginx-nodeselector.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx-run-on-nodeselector
    annotations:
    kubernetes.io/description: "Running the Pod on specific node by nodeSelector"
    spec:
    containers:
    - name: nginx-run-on-nodeselector
    image: nginx:latest
    ports:
    - name: http-80-port
      protocol: TCP
      containerPort: 80 
    nodeSelector:     #通过nodeSelector将pod调度到特定的labels
    app: web
    
  4. 应用yaml文件生成pod

    [root@node-1 demo]# kubectl apply -f nginx-nodeselector.yaml 
    pod/nginx-run-on-nodeselector created
    
  5. 检查验证pod的运行情况,已经运行在node-2节点

    [root@node-1 demo]# kubectl get pods nginx-run-on-nodeselector -o wide 
    NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
    nginx-run-on-nodeselector   1/1     Running   0          51s   10.244.1.24   node-2   <none>           <none>
    

系统默认预先定义有多种内置的labels,这些labels可以标识node的属性,如arch架构,操作系统类型,主机名等

  • beta.kubernetes.io/arch=amd64
  • beta.kubernetes.io/os=linux
  • kubernetes.io/arch=amd64
  • kubernetes.io/hostname=node-3
  • kubernetes.io/os=linux

1.3 node Affinity and anti-affinity

affinity/anti-affinity和nodeSelector功能相类似,相比于nodeSelector,affinity的功能更加丰富,未来会取代nodeSelector,affinity增加了如下的一些功能增强:

  • 表达式更加丰富,匹配方式支持多样,如In,NotIn, Exists, DoesNotExist. Gt, and Lt;
  • 可指定soft和preference规则,soft表示需要满足的条件,通过requiredDuringSchedulingIgnoredDuringExecution来设置,preference则是优选选择条件,通过preferredDuringSchedulingIgnoredDuringExecution指定
  • affinity提供两种级别的亲和和反亲和:基于node的node affinity和基于pod的inter-pod affinity/anti-affinity,node affinity是通过node上的labels来实现亲和力的调度,而pod affinity则是通过pod上的labels实现亲和力的调度,两者作用的范围有所不同。

下面通过一个例子来演示node affinity的使用,requiredDuringSchedulingIgnoredDuringExecution指定需要满足的条件,preferredDuringSchedulingIgnoredDuringExecution指定优选的条件,两者之间取与关系。

  1. 查询node节点的labels,默认包含有多个labels,如kubernetes.io/hostname

    [root@node-1 ~]# kubectl get nodes --show-labels 
    NAME  STATUS  ROLES AGE  VERSION  LABELS
    node-1  Ready master  15d  v1.15.3  beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,node-role.kubernetes.io/master=
    node-2  Ready <none>  15d  v1.15.3  app=web,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-2,kubernetes.io/os=linux
    node-3  Ready <none>  15d  v1.15.3  beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-3,kubernetes.io/os=linux
    
  2. 通过node affiinity实现调度,通过requiredDuringSchedulingIgnoredDuringExecution指定满足条件kubernetes.io/hostname为node-2和node-3,通过preferredDuringSchedulingIgnoredDuringExecution优选条件需满足app=web的labels

    [root@node-1 demo]# cat nginx-node-affinity.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx-run-node-affinity
    annotations:
    kubernetes.io/description: "Running the Pod on specific node by node affinity"
    spec:
    containers:
    - name: nginx-run-node-affinity
    image: nginx:latest
    ports:
    - name: http-80-port
      protocol: TCP
      containerPort: 80 
    affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - node-1
            - node-2
            - node-3
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: app
            operator: In
            values: ["web"] 
    
  3. 应用yaml文件生成pod

    [root@node-1 demo]# kubectl apply -f nginx-node-affinity.yaml 
    pod/nginx-run-node-affinity created
    
  4. 确认pod所属的node节点,满足require和 preferre条件的节点是node-2

    [root@node-1 demo]# kubectl get pods --show-labels nginx-run-node-affinity -o wide 
    NAME                      READY   STATUS    RESTARTS   AGE    IP            NODE     NOMINATED NODE   READINESS GATES   LABELS
    nginx-run-node-affinity   1/1     Running   0          106s   10.244.1.25   node-2   <none>           <none>            <none>
    

写在最后

本文介绍了kubernetes中的调度机制,默认创建pod是全自动调度机制,调度由kube-scheduler实现,调度过程分为两个阶段调度阶段(过滤和沉重排序)和绑定阶段(在node上运行pod)。通过干预有四种方式:

  1. 指定nodeName
  2. 通过nodeSelector
  3. 通过node affinity和anti-affinity
  4. 通过pod affinity和anti-affinity

附录

调度框架介绍:https://kubernetes.io/docs/concepts/configuration/scheduling-framework/

Pod调度方法:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

2. Jobs让单次任务跑起来

2.1 Jobs简介

Windows下可以通过批处理脚本完成批处理任务,脚本运行完毕后任务即可终止,从而实现批处理任务运行工作,类似的任务如何在kubernetes中运行呢?答案是Jobs,Jobs是kubernetes中实现一次性计划任务的Pod控制器—JobController,通过控制Pod来执行任务,其特点为:

  • 创建Pod运行特定任务,确保任务运行完成
  • 任务运行期间节点异常时会自动重新创建Pod
  • 支持并发创建Pod任务数和指定任务数

imgjobs

Jobs任务运行方式有如下三种:

  • 运行单个Jobs任务,一般运行一个pod,pod运行结束任务运行完成;
  • 运行特定数量的任务,通过completion指定总计运行任务;
  • 并发运行任务,通过parallelism指定并发数

2.2 运行单个Jobs任务

1、 定义一个jobs任务,通过在command中运行特定一个脚本,将当前的时间打印100次

apiVersion: batch/v1
kind: Job
metadata:
  name: jobs-demo
  labels:
    controller: jobs
spec:
  parallelism: 1        #并发数默认为1即创建pod副本的数量
  template:
    metadata:
      name: jobs-demo
      labels:
        controller: jobs
    spec:
      containers:
      - name: echo-time
        image: centos:latest
        imagePullPolicy: IfNotPresent
        command:
        - /bin/sh
        - -c
        - "for i in `seq 0 100`;do echo ${date} && sleep 1;done"
      restartPolicy: Never  #设置为Neverjobs任务运行完毕即可完成

2、 运行Jobs任务

[root@node-1 happylau]# kubectl apply -f job-demo.yaml 
job.batch/job-demo created
[root@node-1 happylau]# kubectl get jobs job-demo 
NAME       COMPLETIONS   DURATION   AGE
job-demo   0/1           41s        41s

3、 此时jobs控制器创建了一个pod容器运行任务,此时处于Running状态,任务处在运行过程中,如果运行完毕则会变为completed状态

[root@node-1 happylau]# kubectl get pods  |grep job
job-demo-ssrk7                         1/1     Running   0          97s

4、查看jobs日志日志数据,可以看到当前jobs创建的任务是持续在终端中打印数字,且每次打印暂停1s钟

imgjobs任务输出

5、再次查看jobs的任务,可以看到任务已经completions,运行时长为103s,对应的pod状态处于completed状态

[root@node-1 ~]# kubectl get jobs 
NAME       COMPLETIONS   DURATION   AGE
job-demo   1/1           103s       5m12s

imgjobs之pod状态

2.3 Jobs运行多个任务

Jobs控制器提供了两个控制并发数的参数:completions和parallelism,completions表示需要运行任务数的总数,parallelism表示并发运行的个数,如设置为1则会依次运行任务,前面任务运行再运行后面的任务,如下以创建5个任务数为例演示Jobs控制器实现并发数的机制。

1、 定义计算圆周率的Jobs任务

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(100)"]
      restartPolicy: Never
  parallelism: 1
  completions: 5

2、运行jobs任务,并用kubectl get jobs –watch查看jobs创建过程,可以看到pod任务是依次运行,直至达到completions所定义的数量

imgjobs创建并发任务

3、Jobs任务都已运行完毕,查看Jobs列表可以看到任务都处于Completed状态,查看pod日志可以看到Pi圆周率计算的结果

imgjobs批量运行并发任务

2.4 Jobs运行并发任务

Jobs控制器支持运行并发任务,并发任务即Jobs控制器一次运行多个Pod执行任务处理,如下以一次性运行3个Pod并发数为例演示通过Jobs控制器实现并发任务

1、定义Jobs任务,设置3个并发数任务

apiVersion: batch/v1
kind: Job
metadata:
  name: jobs-demo
  labels:
    controller: jobs
spec:
  parallelism: 3    #运行并发数为3一次性创建3个pod
  template:
    metadata:
      name: jobs-demo
      labels:
        controller: jobs
    spec:
      containers:
      - name: echo-time
        image: centos:latest
        imagePullPolicy: IfNotPresent
        command: 
        - /bin/sh
        - -c 
        - "for i in `seq 0 10`;do echo `date` && sleep 1;done"
      restartPolicy: Never

2、运行Jobs任务并查看,Jobs控制器同时创建了3个并发任务

imgJobs并发运行任务

3、通过上面的演示可知,通过parallelism指定并发数量,Jobs控制器会创建出多个Pod副本并运行直至任务completed,同时parallelism可以配合completions一起使用,通过并发创建特定数量的任务,如下以单次运行3个并发任务实现9个任务的Jobs任务

apiVersion: batch/v1
kind: Job
metadata:
  name: jobs-demo
  labels:
    controller: jobs
spec:
  parallelism: 3    #并发任务为3
  completions: 9    #任务数为9
  template:
    metadata:
      name: jobs-demo
      labels:
        controller: jobs
    spec:
      containers:
      - name: echo-time
        image: centos:latest
        imagePullPolicy: IfNotPresent
        command: 
        - /bin/sh
        - -c 
        - "for i in `seq 0 10`;do echo `date` && sleep 1;done"
      restartPolicy: Never

4、运行Jobs任务并观察创建过程,在describe jobs的详情events日志中可以看到一共创建了9个任务,每3个任务创建时间一样,即并发创建的任务

img并发运行多任务

总结:通过前面的例子解析可得知,Jobs能在kubernetes中实现类似Windows下批处理或Linux下shell任务的功能,通过运行特定任务数+并发数控制创建Pod任务。需要注意一点的是,Jobs控制器和Deployments副本控制器不一样,其不支持修改Jobs的yaml文件,如果有需要修改则需要提前将Jobs任务删除,然后再将修改后的yaml提交任务。

3. CronJobs周期性运转

3.1 CronJobs简介

CronJobs用于实现类似Linux下的cronjob周期性计划任务,CronJobs控制器通过时间线创建Jobs任务,从而完成任务的执行处理,其具有如下特点:

  • 实现周期性计划任务
  • 调用Jobs控制器创建任务
  • CronJobs任务名称小于52个字符
  • 应用场景如:定期备份,周期性发送邮件

imgCronjob

CronJobs可通过schedule指定任务运行的周期,其使用参数和cronjob类似,分别使用:分时日月星5个参数表示周期性,其中*表示任意时间点,/表示每隔多久,-表示范围

  • 分钟 范围为0-59
  • 小时 范围为0-23
  • 日期 范围为1-31
  • 月份 范围为1-12
  • 星期 范围为0-7,其中0和7表示星期日

举例子说明:

1、 /1 * * * 表示每隔1分钟运行任务

2、 1 0 * * 6-7 表示每周六日的0点01分运行任务

3.2 运行Cronjobs任务

CronJobs任务是编写和Deployments类似,需啊哟一个schedule定期任务调度周期,通过jobTemplate定义生成Jobs任务的模版,定义一个任务为例:

1、 定义一个CronJobs任务,每隔5分钟运行一个任务

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-demo
  labels:
    jobgroup: cronjob-demo
spec:
  schedule: "*/5 * * * *"       #调度任务周期
  jobTemplate:                    #创建Jobs任务模版
    spec:
      template:
        spec:
          containers:
          - name: cronjob-demo
            image: busybox:latest
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - "for i in `seq 0 100`;do echo ${i} && sleep 1;done"
          restartPolicy: Never

2、 运行CronJobs并查看任务列表

img运行cronjobs任务

3、校验CronJobs任务运行的情况,可以看到CronJobs任务调用Jobs控制器创建Pod,Pod创建周期和schedule中定义的周期一致

img校验cronjobs

当然,CronJobs中通过Jobs的模版也可以定义运行任务的数量和并发数,实现计划时间范围内并发运行多个任务的需求。

写在最后

文章总结了在kubernetes集群中运行Jobs批处理任务和CronJobs两种控制器的功能使用,适用于特定场景下任务,Jobs任务执行完毕即completed,CronJobs周期性调用Jobs控制器完成任务的创建执行。

参考文章

不错的博客:https://draveness.me/kubernetes-job-cronjob

运行Jobs任务:https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

计划任务ConJobs:https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

自动运行任务:https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

TKE创建Jobs任务:https://cloud.tencent.com/document/product/457/31708

TKE创建CronJobs:https://cloud.tencent.com/document/product/457/31709


当你的才华撑不起你的野心时,你就应该静下心来学习

返回kubernetes系列教程目录

如果觉得文章对您有帮助,请订阅专栏,分享给有需要的朋友吧😊

关于作者 刘海平(HappyLau )云计算高级顾问 目前在腾讯云从事公有云相关工作,曾就职于酷狗,EasyStack,拥有多年公有云+私有云计算架构设计,运维,交付相关经验,参与了酷狗,南方电网,国泰君安等大型私有云平台建设,精通Linux,Kubernetes,OpenStack,Ceph等开源技术,在云计算领域具有丰富实战经验,拥有红帽RHCA/RHCE和OpenStack/Linux授课经验

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

这些信息有用吗?
Do you have any suggestions for improvement?

Thanks for your feedback!