一种基于Kubernetes的容器调度方法与流程

一种基于kubernetes的容器调度方法
【技术领域】
1.本技术涉及一种基于kubernetes的容器调度方法，属于容器管理技术领域。


背景技术：

2.kubernetes是一个开源的容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。而carina为在kubernetes集群中为pod提供存储卷的项目。
3.carina提供了spreadout策略及binpack策略。其中，spreadout策略会尝试把每个容器平均地部署到每个节点上，而binpack策略会把容器尽量部署在主要的负载节点上。
4.然而，目前的容器调度策略并没有将节点磁盘容量考虑在内，也就是说这部分内容是缺失的，用户难以预见性的得知容器会调度到哪个节点，用户对于存储卷可能扩容或者需要存储拓扑分布是无法提前维护。


技术实现要素：

5.本技术提供了一种基于kubernetes的容器调度方法，可以解决目前的容器调度策略并没有将节点磁盘容量考虑在内，导致对于存储卷可能扩容或者需要存储拓扑分布无法提前维护的问题。本技术提供如下技术方案：
6.提供一种基于kubernetes的容器调度方法，用于kubernetes集群中的管理节点中，所述管理节点安装有carina；所述方法包括：
7.响应于调度器监听到容器创建请求，通过所述调度器获取容器申请的资源信息和所述kubernetes集群中各个节点的磁盘使用信息；
8.通过所述调度器基于所述资源信息和所述磁盘使用信息，从各个节点中确定创建所述容器的目标节点。
9.可选地，所述通过所述调度器基于所述资源信息和所述磁盘使用信息，从各个节点中确定创建所述容器的目标节点，包括：
10.对于每个节点，确定所述节点的磁盘使用信息指示的可分配容量是否大于或等于所述资源信息指示的待使用容量；
11.在所述可分配容量是小于所述待使用容量的情况下，将所述节点筛除；
12.使用所述资源信息和所述磁盘使用信息，确定各个未筛除的节点的调度评分；
13.从各个未筛除的节点中确定调度评分符合预设条件的目标节点。
14.可选地，所述使用所述资源信息和所述磁盘使用信息，确定各个未筛除的节点的调度评分，包括：
15.对于每个未筛除的节点，计算所述未筛除的节点的可分配容量与所述待使用容量的比值；
16.基于所述比值确定所述未筛除的节点的调度评分。
17.可选地，所述基于所述比值确定所述未筛除的节点的调度评分，包括：
18.在所述比值大于预设阈值的情况下，确定所述未筛除的节点的调度评分为预设评
分；
19.在所述比值小于或等于预设阈值的情况下，确定所述未筛除的节点的调度评分为所述比值；其中，所述预设评分大于所述预设阈值。
20.可选地，所述从各个未筛除的节点中确定调度评分符合预设条件的目标节点，包括：
21.将调度评分为期望评分的未筛除的节点确定为所述目标节点。
22.可选地，所述从各个未筛除的节点中确定调度评分符合预设条件的目标节点，包括：
23.从各个未筛除的节点中确定调度评分最大的节点，得到所述目标节点。
24.可选地，在所述调度评分符合预设条件的未筛除的节点的数量为至少两个的情况下，所述从各个未筛除的节点中确定调度评分符合预设条件的目标节点，包括：
25.从至少两个符合预设条件的未筛除的节点中，随机选择一个节点确定为所述目标节点；
26.或者，
27.从至少两个符合预设条件的未筛除的节点中，确定负载信息最小的节点确定为所述目标节点。
28.可选地，所述基于所述资源信息和所述磁盘使用信息，从各个节点中确定创建所述容器的目标节点之后，还包括：
29.通过控制器在获取到所述调度器选择出的所述目标节点后，在所述目标节点创建所述容器；
30.创建持久卷pv；
31.在所述容器创建成功后，将所述pv挂载至所述目标节点。
32.可选地，在所述容器创建成功后，所述方法还包括：
33.在所述容器销毁重建的情况下，再次执行所述通过所述调度器获取容器申请的资源信息和所述kubernetes集群中各个节点的磁盘使用信息；通过所述调度器基于所述资源信息和所述磁盘使用信息，从各个节点中确定创建所述容器的目标节点的步骤。
34.可选地，所述方法还包括：
35.在所述kubernetes集群中创建持久化卷声明pvc，所述pvc携带有资源信息；
36.在所述kubernetes集群中创建部署物deployment；所述pvc和所述deployment创建完成后，所述调度器监听到容器创建请求。
37.本技术的有益效果至少包括：通过响应于调度器监听到容器创建请求，通过调度器获取容器申请的资源信息和kubernetes集群中各个节点的磁盘使用信息；通过调度器基于资源信息和磁盘使用信息，从各个节点中确定创建容器的目标节点；可以解决目前的容器调度策略并没有将节点磁盘容量考虑在内，导致对于存储卷可能扩容或者需要存储拓扑分布无法提前维护的问题；通过基于节点磁盘容量进行容器调度，可以保证容器不会调度到无法创建对应volume的节点，提高容器创建的效率。
38.另外，通过根据配置策略将容器分散调度或者调度到刚好满足存储需求的节点，可以提高容器调度的灵活性。
39.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，
并可依照说明书的内容予以实施，以下以本技术的较佳实施例并配合附图详细说明如后。
【附图说明】
40.图1是本技术一个实施例提供的一种基于kubernetes的容器调度方法的流程图；
41.图2是本技术一个实施例提供的一种基于kubernetes的容器调度过程的示意图；
42.图3是本技术一个实施例提供的pv挂载至目标节点的整体流程图。
【具体实施方式】
43.下面结合附图和实施例，对本技术的具体实施方式做进一步详细描述。以下实施例用于说明本技术，但不用来限制本技术的范围。
44.首先，对于本技术涉及的若干名词进行介绍。
45.kubernetes：简称k8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。kubernetes是一个开源的容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问。
46.kubelet：kubernetes的核心组件，是kubernetes工作节点上的一个代理组件，运行在每个节点上。kubelet定期从kube-apiserver组件接收新的或修改的pod规范，并确保pod及其容器在期望规范下运行。同时该组件作为工作节点的监控组件，向kube-apiserver汇报主机的运行状况。换言之，kubelet负责每个节点的运行状态(即确保节点上的所有容器都正常运行)。它按照控制面板的指示来处理启动，停止和维护应用程序容器pod。
47.其中，kube-apiserver组件提供了k8s各类资源对象(容器集(pod)、复制控制器(replication controller，rc)、服务(service)等)的增删改查及监控(watch)等http rest接口，是整个系统的数据总线和数据中心。
48.容器集(pod)：是kubernetes管理的最小单元，多个容器组合在一起叫做pod。pod是运行应用的载体，pod是由多个容器组成，是kubernetes的最小调度单元、pod共享底层资源、由kubernetes来管理生命周期。
49.部署物(deployment)：在kubernetes中一个deployment代表一组容器组。一般情况下，我们并不直接创建pod，而是通过deployment来创建pod，由deployment来负责创建、更新、维护其所管理的所有pods。
50.调度器(scheduler)：是kubernetes的一个核心组件，主要负责进行pod的调度。具体地，在用户或者控制器创建一个pod后，scheduler在对象存储数据里监控未被分配的pod，并将pod分配到某个节点。然后，kubelet在对象存储数据里监控已分配的pod，并运行该pod。
51.存储卷(volume)：容器在服务器中是无状态的，需要挂载存储卷将数据保存到本地磁盘。kubernetes的存储卷有自己的生命周期，它的生命周期与使用的它pod生命周期一致。相比于在pod中运行的容器来说，存储卷的存在时间会比的其中的任何容器都长，并且在容器重新启动时会保留数据。当然，当pod停止存在时，存储卷也将不再存在。
52.持久化卷声明(persistent volume claim，pvc)：是用户存储的一种声明，或者说
是用户的一种存储请求。pvc和pod比较类似，pod消耗的是节点，pvc消耗的是pv资源；pod可以请求cpu和内存，而pvc可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用pvc即可。在kubernetes中创建存储卷，需要创建pvc资源申请。
53.持久卷(persistent volume，pv)：是集群内由管理员提供的网络存储的一部分。就像集群中的节点一样，pv也是集群中的一种资源。它也像volume一样，是一种volume插件，但是它的生命周期却是和使用它的pod相互独立的。pv是在kubernetes中创建的存储卷信息。
54.pvc和pv的关系与pod和节点关系类似，前者消耗后者的资源。pvc可以向pv申请指定大小的存储资源并设置访问模式,这就可以通过provision-》claim的方式，来对存储资源进行控制。
55.carina：是基于kubernetes csi标准实现的存储插件。在kubernetes集群中为pod提供存储卷的项目。carina能够自动发现本地裸盘，并根据其磁盘特性划分为硬盘驱动器(hard disk drive，hdd)磁盘卷组及固态硬盘(solid state disk或solid state drive，ssd)磁盘卷组等。
56.carina主要有三部分组成，分别是carina-controller、carina-scheduler和carina-node。其中，carina-node是运行在每个节点上的代理(agent)服务，利用逻辑卷管理(logical volume manager,lvm)技术管理本地磁盘，按照类别将本地磁盘划分到不同的卷组(volume group)，并从中划分逻辑卷(logical volumes，lv)提供给pod使用。carina-scheduler是kubernetes的调度插件，负责基于申请的pv大小，节点剩余磁盘空间大小，节点负载使用情况进行合理的调度。默认提供了spreadout策略及binpack策略。carina-controller是carina的控制平面，监听pvc等资源，维护pvc和lv之间的关系。
57.下面对本技术提供的基于kubernetes的容器调度方法进行介绍。本实施例以该方法用于kubernetes集群中的管理节点中为例进行说明。管理节点中安装有carina。carina包括控制器carina-controller和调度器carina-scheduler。
58.参考图1，本实施例提供的一种基于kubernetes的容器调度方法至少包括以下几个步骤：
59.步骤101，响应于调度器监听到容器创建请求，通过调度器获取容器申请的资源信息和kubernetes集群中各个节点的磁盘使用信息。
60.在一个示例中，在kubernetes集群中创建pvc，pvc携带有资源信息(如申请10g的存储空间，在实际实现时，资源信息也可以请求其它数值的存储空间)；在kubernetes集群中创建deployment；pvc和deployment创建完成后，调度器自动监听到容器创建请求。
61.步骤102，通过调度器基于资源信息和磁盘使用信息，从各个节点中确定创建容器的目标节点。
62.在一个示例中，通过调度器基于资源信息和磁盘使用信息，从各个节点中确定创建容器的目标节点，包括：对于每个节点，确定节点的磁盘使用信息指示的可分配容量是否大于或等于资源信息指示的待使用容量；在可分配容量是小于待使用容量的情况下，将节点筛除；使用资源信息和磁盘使用信息，确定各个未筛除的节点的调度评分；从各个未筛除的节点中确定调度评分符合预设条件的目标节点。
63.本实施例中，首先判断节点磁盘容量是否能够满足申请值，如果不满足则直接拒绝调度到该节点，可以避免对该节点进行后续的调度评分的计算，以节省计算资源。
64.在其它实施例中，也可以对各个节点的调度评分均进行计算，而不进行节点筛除，本实施例不对节点筛除的执行方式作限定。
65.其中，使用资源信息和磁盘使用信息，确定各个未筛除的节点的调度评分，包括：对于每个未筛除的节点，计算未筛除的节点的可分配容量与待使用容量的比值；基于比值确定未筛除的节点的调度评分。
66.基于比值确定未筛除的节点的调度评分，包括但不限于以下几种方式：
67.第一种：在比值大于预设阈值的情况下，确定未筛除的节点的调度评分为预设评分；在比值小于或等于预设阈值的情况下，确定未筛除的节点的调度评分为比值；其中，预设评分大于预设阈值。
68.预设阈值大于1，且预设阈值的取值预存在管理节点中。预设阈值可以为10、5等，本实施例不对预设阈值的取值作限定
69.由于如果磁盘可分配容量比申请容量大预设阈值倍，则所有节点的调度评分是一致的，此时，由于各个节点的容量都远远大于申请容量，因此，容器创建在哪个节点都是可以的，因此，可以为各个节点设置相同的调度评分。
70.第二种：未筛除的节点的调度评分为比值。在这种方式中，无论比值是否大于预设阈值，都将比值作为节点的调度评分。
71.可选地，从各个未筛除的节点中确定调度评分符合预设条件的目标节点，包括：将调度评分为期望评分的未筛除的节点确定为目标节点；或者，从各个未筛除的节点中确定调度评分最大的节点，得到目标节点。
72.其中，期望评分可以为用户设置的，或者是预存在管理节点中的默认值，比如：期望评分为1分，此时，将恰好满足申请容量的节点确定为目标节点。
73.可选地，在调度评分符合预设条件的未筛除的节点的数量为至少两个的情况下，从各个未筛除的节点中确定调度评分符合预设条件的目标节点，包括：从至少两个符合预设条件的未筛除的节点中，随机选择一个节点确定为目标节点；或者，从至少两个符合预设条件的未筛除的节点中，确定负载信息最小的节点确定为目标节点。
74.为了方便理解本技术提供的基于kubernetes的容器调度方法，下面对该方法举一个实例进行说明。参考图2，首先在kubernetes集群中创建申请存储资源请求pvc，然后创建容器服务deployment申请该资源的使用。当在kubernetes集群中创建完成这两种资源后，调度器会自动发现该请求，并开始收集申请资源的请求信息已经各个节点磁盘的使用情况，当数据收集完成之后，则开始进行调度计算。
75.在计算过程中，第一步对于节点磁盘容量明显无法满足需求的直接排除掉。第二步对基本满足情况的磁盘节点进行评分以此来选出最优调度节点，通过调度权重＝申请容量/节点可分配容量来计算出每个节点的调度权重。如果该权重值大于预设阈值，则这些节点的调度评分是一致。因为节点磁盘容量与申请容量相差巨大磁盘对容器调度的影响可以忽略；然后将调度权重通过按比例缩小处理成容器调度评分，进而得出容器对每个节点的调度评分。
76.根据用户配置的调度策略，策略一将节点磁盘容器最大的节点的调度评分设置为
最大，策略二将节点磁盘刚刚满足需求的节点调度评分设置为最大；由此来实现用户预见性的得知容器将会调度到哪个目标节点。
77.比如：用户可以通过配置调度策略来影响调度算法的运行结果。因为可以满足不同类型的存储需求，比如a服务的存储将来会频繁扩容则采用将容器调度到存储容器最大的节点，b服务对于容量的需求一旦申请几乎不变，则调度到刚好满足需求的节点，这样其他服务容量增长需求也更容易满足。
78.可选地，参考图3所示的整体流程，基于资源信息和磁盘使用信息，从各个节点中确定创建容器的目标节点之后，还包括：通过控制器在获取到调度器选择出的目标节点后，在目标节点创建容器；创建持久卷pv；在容器创建成功后，将pv挂载至目标节点。
79.可选地，参考图3，在容器创建成功后，在容器销毁重建的情况下，再次执行通过调度器获取容器申请的资源信息和kubernetes集群中各个节点的磁盘使用信息；通过调度器基于资源信息和磁盘使用信息，从各个节点中确定创建容器的目标节点的步骤。
80.综上所述，本实施例提供的基于kubernetes的容器调度方法，通过响应于调度器监听到容器创建请求，通过调度器获取容器申请的资源信息和kubernetes集群中各个节点的磁盘使用信息；通过调度器基于资源信息和磁盘使用信息，从各个节点中确定创建容器的目标节点；可以解决目前的容器调度策略并没有将节点磁盘容量考虑在内，导致对于存储卷可能扩容或者需要存储拓扑分布无法提前维护的问题；通过基于节点磁盘容量进行容器调度，可以保证容器不会调度到无法创建对应volume的节点，提高容器创建的效率。
81.另外，通过根据配置策略将容器分散调度或者调度到刚好满足存储需求的节点，可以提高容器调度的灵活性。
82.以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
83.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。