CN114661419A - 一种服务质量控制系统及方法 - Google Patents

Abstract

本发明实施例提供了一种服务质量控制系统及方法，该系统包括：控制节点和工作负载节点；其中，控制节点，用于对所创建的对外服务进程进行监听，当监听到对外服务进程中有第一目标对象更新时，根据第一目标对象更新相应的第二目标对象；工作负载节点，用于访问对外服务进程并监听，当监听到所述对外服务进程中有第二目标对象更新时，根据第二目标对象更新所述第二目标对象关联容器的资源配置。该系统基于监听到资源配置策略或容器的更新，更新资源配置规则；然后基于资源配置规则的更新确定IO资源限制，利用Linux操作系统自身的cgroup的IO限制功能或其他数据路径技术，实现了容器云平台本地块存储具有服务质量控制的目的。

Description

一种服务质量控制系统及方法

技术领域

本发明涉及云计算技术领域，尤其涉及一种服务质量控制系统及方法。

背景技术

云原生是一种在云环境中构建和运行应用程序的方法，在实际应用中，可以通过容器、容器编排、微服务等云原生技术构建容错性好、易于管理和便于观察的云原生应用，不同的云原生应用对于块存储卷的IO质量服务(Quality of Service，QoS)保障需求不同。

目前云原生应用主要以容器化的方式在Kubernetes上运行，当云原生应用进行读写操作时，会占用节点上的中央处理器、内存、IO等资源。而Kubernetes目前仅支持对容器的中央处理器、内存资源进行限制，对块存储卷QoS的支持需要依赖外部存储厂商提供的存储QoS支持。

但Kubernetes中除了使用外部存储系统外，还有很大一部分场景需要使用本地块存储，在容器云平台本地块存储的场景下，Kubernetes中并没有实现本地块存储QoS保障的功能。当Kubernetes中运行的多种云原生应用同时运行在同一节点上且共用同一本地存储池时，可能会发生某个低优先级的应用过多占用IO资源，造成高优先级的应用受低优先级的影响出现性能不及预期或性能不稳定的问题。

发明内容

本发明提供了一种服务质量控制系统及方法，以解决容器云平台中本地存储不支持服务质量控制的问题。

第一方面，本实施例提供了一种服务质量控制系统，包括：控制节点和工作负载节点；其中，

所述控制节点，用于对所创建的对外服务进程进行监听，当监听到所述对外服务进程中有第一目标对象更新时，根据所述第一目标对象更新相应的第二目标对象；

所述工作负载节点，用于访问所述对外服务进程并监听，当监听到所述对外服务进程中有第二目标对象更新时，根据所述第二目标对象更新所述第二目标对象关联容器的资源配置。

第二方面，本实施例提供了一种服务质量控制方法，包括：

对所创建的对外服务进程进行监听，当监听到所述对外服务进程中有第一目标对象更新时，根据所述第一目标对象更新相应的第二目标对象；

访问所述对外服务进程并监听，当监听到所述对外服务进程中有第二目标对象更新时，根据所述第二目标对象更新所述第二目标对象关联容器的资源配置。

本发明实施例提供了一种服务质量控制系统及方法，该系统包括：控制节点和工作负载节点；其中，所述控制节点，用于对所创建的对外服务进程进行监听，当监听到所述对外服务进程中有第一目标对象更新时，根据所述第一目标对象更新相应的第二目标对象；所述工作负载节点，用于访问所述对外服务进程并监听，当监听到所述对外服务进程中有第二目标对象更新时，根据所述第二目标对象更新所述第二目标对象关联容器的资源配置。该系统基于监听到资源配置策略或容器的更新，更新资源配置规则；然后基于资源配置规则的更新确定IO资源限制，利用Linux操作系统自身的cgroup的IO限制功能，实现了容器云平台本地块存储具有服务质量控制的目的。解决了容器云平台只能依赖外部存储提供服务质量控制的问题。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一提供的一种服务质量控制系统的结构示意图；

图2为本发明实施例二提供的另一种服务质量控制系统的结构示意图；

图3为本发明实施例二提供的又一种服务质量控制系统的结构示意图；

图4为基于Kubernetes云平台的服务质量控制系统的结构框图；

图5为基于Kubernetes云平台的服务质量控制系统的主要组件工作流程示意图；

图6为本申请实施例三提供的一种服务质量控制方法的流程示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，目前云原生应用主要以容器化的方式在Kubernetes上运行。Kubernetes是一款开源的，用于管理容器集群主机上的容器化的应用，提供了容器应用部署、规划、更新、维护的一种机制，目标是让部署容器化的应用简单并且高效。Kubernetes中的持久化存储依赖存储供给插件对容器进行供给存储卷，存储供给插件供给的存储资源按照来源区分可以分为外部存储与本地存储。外部存储是依赖集群外部的存储系统进行存储供给。本地存储是依赖集群内部节点上的本地磁盘存储资源进行供给。当应用进行读写操作时，会占用节点上的中央处理器、内存、读写(Input/Output，IO)等资源。由于不同的云原生应用对于块存储卷的IO服务质量保障需求不同。当前Kubernetes社区中对块存储卷QoS的支持，依赖外部存储厂商提供的存储QoS支持。

考虑到Kubernetes中除了使用外部存储系统外，还有很大一部分场景需要使用本地块存储，为应用供给存储卷。例如：在大数据场景下通常会使用本地存储来供给存储卷供容器使用。而Kubernetes目前仅支持对容器的中央处理器、内存资源进行限制。在容器云平台本地块存储的场景下，当Kubernetes中运行的多种云原生数据应用同时运行在同一节点上，且共用同一本地存储池时，可能会发生某个低优先级的应用过多占用IO资源，造成高优先级的应用受低优先级的影响出现性能不及预期或性能不稳定的问题。因此，需要一种支持基于Kubernetes平台实现本地块存储QoS保障的系统。

实施例一

图1为本发明实施例一提供的一种服务质量控制系统的结构示意图，本实施例适用于基于容器云平台本地块存储提供服务质量控制的情况，该系统可以由硬件和/或软件实现，并一般集成在云平台中。如图1所示，该装置包括：控制节点10和工作负载节点20。其中：

控制节点10，用于对所创建的对外服务进程11进行监听，当监听到对外服务进程11中有第一目标对象更新时，根据第一目标对象更新相应的第二目标对象。

其中，第一目标对象包括资源配置策略或容器，第二目标对象包括资源配置规则。

需要知道的是，本实施例提供一种服务质量优先级分级保障机制来保障不同优先级的工作负载对IO资源的占用。系统可以为用户提供交互界面，交互界面中可以包含服务质量类别、容器、资源配置策略等内容。其中，服务质量类别表征服务质量优先级保障的等级，系统管理员可以预先定义服务质量类别，进行不同优先级的服务质量级别划分。不同的服务质量类别对应不同的存储IO带宽、每秒进行读写操作的次数(Input/OutputOperations Per Second，IOPS)限制、IO权重比例等。每种服务质量类别可以以数据结构的形式表征。示例性的：IOMax：用于限制容器的IO最大值，其包括子限制参数如下：ReadBPS表示最大读带宽限制，WriteBPS表示最大写带宽限制，ReadIOPS表示最大读IOPS限制，WriteIOPS表示最大写IOPS限制；IOWeight：用于指定容器的IO权重占比。

其中，资源配置策略表征了集群内给什么样的容器指定什么样的服务质量类别。资源配置策略的数据结构至少需要关联容器的名字或者标签，同时关联选定的服务质量类别名称。用户可以根据容器对IO服务质量的需要在系统提供的界面上，选择与之对应的服务质量类别进行匹配，系统可以根据用户的匹配结果对工作负载的IO资源限制进行配置。当工作负载的IO资源限制配置完成后，实际工作时就会根据配置情况合理安排IO资源，保障高优先级的负载正常工作。

当用户在系统提供的交互界面上进行操作请求时，控制节点10会对用户的操作请求进行响应，操作请求可能是新建或删除容器，也可能是新建、删除或更新资源配置策略，此处不做具体限制。控制节点10会根据操作请求更新对应操作请求的对外服务进程11，当通过对外服务进程11监听到容器或者资源配置策略发生变化时，根据变化情况更新资源配置规则。

示例性的，对于Kubernetes，组件Etcd存储集群的数据信息，Kube-apiserver作为对外服务进程11的统一入口，任何对数据的操作都必须经过Kube-apiserver。控制节点10通过list-watch机制监听Kube-apiserver中资源(如容器pod等)的创建、更新和删除事件，并针对事件类型调用相应的事件处理函数。

可以知道的是，控制节点10监听到的事件可能是容器或者资源配置策略创建、删除等操作，不同的更新事件对应更新资源配置规则的情况也不同。示例性的，若监听到的更新事件为添加了资源配置策略，则控制节点会为该资源配置策略匹配到的已有所有容器分别创建一个关联的资源配置规则的自定义资源。若监听到的更新事件为删除容器，则会删除与该容器关联的资源配置规则。

需要说明的是，控制节点10对于对外服务进程11的监听是持续的，也可以理解为是提前设置且持续工作的。每当对外服务进程11中资源配置策略或者容器发生变化时，控制节点都可以监听到其变化，然后进行后续操作。

工作负载节点20，用于访问对外服务进程11并监听，当监听到对外服务进程11中有第二目标对象更新时，根据第二目标对象更新第二目标对象关联容器的资源配置。

其中，资源配置规则用于定义一个特定容器的资源配置规则。该资源配置规则的空间命名和名称与其作用的容器名称信息等均相同。示例性的，资源配置规则的数据结构可以表示为：StorageQosPolicy Name：用于指定该资源配置规则对应的资源配置策略名称，StorageQosClass Name：用于指定该资源配置规则对应的服务质量类别名称。

需要说明的是，工作负载节点20对于对外服务进程11的监听是持续的，也可以理解为是提前设置且持续工作的。每当对外服务进程11中资源配置规则发生变化时，控制节点都可以监听到其变化，然后进行后续操作。由于工作负载节点20一直在监听对外服务进程11，当控制节点10更新资源配置规则后，工作负载节点20可以监听到资源配置规则发生变化，可以根据资源配置规则更新关联的容器对应的资源配置。

可以清楚的是，Pod是Kubernetes部署或管理的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个容器组。Kubernetes中持久化存储类型的存储卷(PersistentVolume，PV)，挂载到Pod中供业务负载读写。由于本地存储无服务质量控制，所以这里引入基于Linux操作系统内核源自控制组群(control group，cgroup)v2的IO限制能力来实现Kubernetes中容器块存储卷IO的限制，当然，也可以利用其他数据路径(Data Path)技术来限制存储卷的IO。其中，cgroup v2是Linux内核中控制组的v2版本，提供资源限制的能力。

可以知道的是，控制节点10监听到的事件可能是资源配置规则创建、删除等操作，不同的更新事件对应更新关联容器的资源配置情况也不同。当工作负载节点20监听到资源配置规则发生变化时，工作负载节点20通过其上的引擎，直接与Linux内核的cgroup(v2)模块交互，将资源配置规则中的IO带宽、IOPS限制及IO权重限制的配置转换为cgroup(v2)中的IO限制配置，设置到cgroup(v2)中，利用cgroup v2的功能最终实现容器应用对一个或多个块存储卷的IO限制。此方式仅依赖Linux操作系统提供的cgroup v2功能。

本发明实施例提供了一种服务质量控制系统，该系统包括：控制节点和工作负载节点；其中，控制节点，用于对所创建的对外服务进程进行监听，当监听到对外服务进程中有第一目标对象更新时，根据第一目标对象更新相应的第二目标对象；工作负载节点，用于访问对外服务进程并监听，当监听到对外服务进程中有第二目标对象更新时，根据第二目标对象更新第二目标对象关联容器的资源配置。该系统基于监听到资源配置策略或容器的更新，更新资源配置规则；然后基于资源配置规则的更新确定IO资源限制，利用Linux操作系统自身的cgroup的IO限制功能，实现了容器云平台本地块存储具有服务质量控制的目的。解决了容器云平台只能依赖外部存储提供服务质量控制的问题。

实施例二

图2为本发明实施例二提供的另一种服务质量控制系统的结构示意图，本实施例以上述实施例一为基础进行优化，在本实施例中，控制节点10可以具体优化为，包括：控制面板12和核心控制器13；工作负载节点20可以具体优化为，包括：规则控制器21和设置引擎22。

其中，控制面板12，用于向用户提供可视化界面，接收用户在可视化界面中的资源更新请求；核心控制器13，用于基于资源更新请求，更新第一目标对象，根据第一目标对象更新第二目标对象。

其中，控制面板12可以为用户提供可视化界面，以供用户和系统之间进行交互。可视化界面中至少包含三部分内容，包含容器、服务质量类别和资源配置策略。容器的信息可以包含容器名称、容器标签等；服务质量类别可以包含服务质量级别及对应的IO带宽、IOPS限制及IO权重限制；资源配置策略包含容器与服务质量类别的配置。用户可以在可视化界面中进行设置服务质量类别与资源配置策略来配置对一个或多个容器的IO限制，从而形成资源配置策略。可以知道的是，用户在可视化界面中的操作可以是新建或删除容器，也可以是新建、删除或更新资源配置策略。用户在可视化界面中的操作会生成资源更新请求。

当控制面板12接收到资源更新请求时，核心控制器13会响应该资源更新请求，解析该资源更新请求，当监听到对外服务进程11中资源配置策略或者容器发生更新时，根据资源配置策略或者容器的更新情况，更新资源配置规则。

其中，资源配置策略用于定义集群内给什么样的容器指定什么样的服务质量类别。示例性的，资源配置策略的数据结构可以表示为：StorageQosClass Name：用于指定该资源配置策略的使用服务质量类别名称，Label选择器：用于匹配一个或多个Pod Label，Pod Name选择器：用于匹配相应名称的Pod，可以使用正则表达式等其他方式。

规则控制器21，用于当接收到对外服务进程11发送的第二目标对象更新通知时，基于第二目标对象的更新事件，确定对应的目标限制规则。

其中，目标限制规则用于定义针对容器的一个存储卷的Cgroup(v2)IO限制配置。配置引擎根据此配置来设置容器的cgroup(v2)IO限制。示例性的，目标限制规则的数据结构如下：PodUID：表示容器在Kubernetes中的用户身份证明(User Identification，UID)；LinuxDeviceNumber：表示Linux中的设备号，由主、副设备号构成，唯一确定一个Linux设备；CSIDriver：表示Pod PV的CSI驱动标识；Name：表示Pod PV的名称。IOMax：用于限制容器的IO最大值，其包括子限制参数如下：ReadBPS：表示最大读带宽限制；WriteBPS：表示最大写带宽限制；ReadIOPS：表示最大读IOPS限制；WriteIOPS：表示最大写IOPS限制。IOWeight：用于指定容器的IO权重占比。

当接收到对外服务进程发送的资源配置规则更新通知时，可以根据资源配置规则的更新事件，确定对应的目标限制规则。其中，资源配置规则的更新情况可能是新创建了资源配置规则，也可能是更新了资源配置规则中的内容。若是新创建的资源配置规则，则需要将资源配置规则中涉及容器的资源限制均转化成目标限制规则，更新到配置文件中。若是更新了资源配置规则中的内容，则需要将更新内容涉及容器的资源限制转化为目标限制规则。具体的，可以先根据资源配置规则中记录的类别名及关联容器；然后确定与类别名对应的IO限制信息以及确定关联容器挂载的存储卷；最后，将各存储卷与所述IO限制信息更新至目标限制规则中。

设置引擎22，用于将目标限制规则转化为目标控制参数，并将目标控制参数写入配置文件中，以实现容器对各存储卷的服务质量控制。

具体的，设置引擎内置在节点代理中运行在集群的每个工作负载节点上。当接收到目标限制规则时，需要将目标限制规则转化为对应可识别的目标控制参数，目标控制参数是容器对各存储卷的IO资源限制。根据目标限制规则中容器的关键字，如，容器的标识号，可以确定该容器对应的配置文件；将目标限制规则转换为配置文件可以记录的目标控制参数；并将对应控制参数写入到对应配置文件中，根据配置文件中记载的IO中资源限制，可以合理分配各负载的IO资源，实现容器对各存储卷的服务质量控制。

图3为本发明实施例二提供的又一种服务质量控制系统的结构示意图，作为上述实施例的可选实施例，本实施例在上述实施例的基础上，具体化了核心控制器13，可以包括：管理器131，用于对控制面板12反馈的资源更新请求进行解析，基于解析结果在对外服务进程11中更新第一目标对象；策略控制器132，用于当接收到外服务进程11发送的第一目标对象更新通知时，基于第一目标对象的更新事件，在外服务进程11上更新第二目标对象。

其中，管理器131作为对外服务进程对外提供REST应用程序接口(ApplicationProgramming Interface，API)响应用户在控制面板12上的资源更新请求，以触发策略控制器的工作逻辑。具体的，资源更新请求可能是新增/删除/更新资源配置策略或新增/删除容器请求，管理器131会对接收到的请求进行解析，根据解析出的结果更新第一目标对象。当第一目标对象更新时，会通过inform机制将第一目标对象发生更新通知策略控制器132。策略控制器132接收到第一目标对象更新通知时，根据第一目标对象的更新事件，更新第二目标对象。

可以理解的是，第一目标对象的更新事件可以包括新增/删除/更新资源配置策略或新增/删除容器。第一目标对象的更新事件具体内容由资源更新请求确定。同样，第二目标对象的更新内容由第一目标对象更新情况确定。示例性的，若用户在控制面板11上进行了删除某容器的操作，则控制面板11会生成删除某容器的请求并反馈，管理器131响应该请求，并基于该请求删除该容器的自定义资源；当策略控制器132监听到删除该容器的自定义资源时，会删除该容器关联的资源配置规则。

进一步地，策略控制器132，具体用于：

a1)若更新事件为新增资源配置策略，则针对新增资源配置策略关联各容器，分别创建与各容器相关联的资源配置规则。

具体的，若有新增资源配置策略，根据新增资源配置策略可以获取与该新增策略关联的所有已创建容器，分别为每一个关联容器创建一个关联资源配置规则。

优选的，在进行容器匹配时，可以优先对容器名称直接匹配，过滤匹配与资源配置策略相同命名空间下的特定容器名称；再匹配标签字段，通过标签过滤缓存的容器资源。

b1)若更新事件为新增容器，则判断容器是否与资源配置策略匹配，若匹配，则创建与容器关联的资源配置规则。

具体的，每当一个新的容器被创建时，就会判断该容器是否与选择条件匹配，如果匹配则为该容器创建一个关联资源配置规则。

c1)若更新事件为删除资源配置策略或容器，则删除资源配置策略相关联的资源配置规则或容器相关联的资源配置规则。

具体的，若删除资源配置策略或者容器时，则会删除关联的资源配置规则。

d1)若更新事件为服务资源配置策略内容变更，则根据变更内容修改与资源配置策略相关联的资源配置规则中对应内容。

具体的，当资源配置策略内容更新时，例如：修改了资源配置策略中的资源配置类别名称(StorageQoSClassName)，则也会更新所有关联的资源配置规则中的资源配置类别名称(StorageQoSClassName)。

作为上述实施例的可选实施例，本实施例在上述实施例的基础上，规则控制器21，具体用于：当接收到外服务进程11发送的第二目标对象更新通知时，若第二目标对象更新情况为创建资源配置规则或更新资源配置规则内容，则基于资源配置规则中记录的配置信息，确定目标限制规则。

本实施例中，当接收到对外服务进程11发送的资源配置规则更新通知时，资源配置规则更新可能是删除与容器或资源配置策略相关的资源配置规则，又或者是新建资源配置规则、更改资源配置规则中的内容。其中对于删除资源配置规则，则可以直接进行资源配置删除。而对新建或者更新资源配置规则，则涉及到需要更新容器的IO限制信息，因此需要基于资源配置规则中记录的配置信息，确定更新后的IO限制信息与关联容器挂载存储卷的对应关系，并将对应内容添加到限制规则中，形成目标限制规则。

进一步地，规则控制器21用于基于第二目标对象中记录的配置信息确定目标限制规则的步骤包括：

a2)确定资源配置规则中记录的类别名及关联容器。

具体的，资源配置规则中记录了类别名，且该资源配置规则的命名空间与名称与其作用的容器名称等信息均相同，据此可以确定类别名和关联容器。

b2)基于类别名，结合预设的类别信息表，确定与类别名对应的IO限制信息。

其中，类别信息表中记录了类别名及与类别名对应的IO限制信息。具体的，根据上述步骤确定的类别名，可以确定与类别名对应的IO限制信息。确定出的IO限制信息就是该资源配置规则关联容器需要设置的IO限制信息。

c2)基于关联容器的属性信息，确定关联容器挂载的存储卷。

具体的，需要将确定出的IO限制信息，均设置到关联容器所挂载的存储卷，因此需要确定关联容器挂载的存储卷。其中关联容器的属性信息可以是命名空间和名称。可以根据容器的命名空间和名称查找所有此容器挂载的存储卷。

d2)遍历各存储卷，将各存储卷与IO限制信息更新至目标限制规则中。

具体的，遍历此容器挂载的所有存储卷，将各存储卷信息与IO限制信息填充到目标限制规则中。

优选地，设置引擎22具体用于：

a3)根据目标限制规则中容器的标识号，遍历容器配置文件目录，确定容器的目标配置文件。

可以理解的是，设置引擎22需要根据确定出的目标限制规则，设置容器对挂载的存储卷的IO限制，即将IO限制信息更新到复制卷对应的存储文件中。因此，需要先确定出容器的存储文件。示例性的，在WarpStor Agent所在节点的/sys/fs/cgroup(默认的cgroupfs挂载点)目录下以资源配置规则的数据结构中PodUID字段作为关键字，遍历所有podcgroup的目录名来找到此pod在host上的cgroup路径。其中，IO带宽文件可以命名为io.max文件、IO权重文件可以命名为io.weight文件。

b3)将目标限制规则转换为目标控制参数。

示例性的，将目标限制规则中的IOMax、IOWeight字段转换成cgroup(v2)的IO限制控制参数。

c3)将目标控制参数写入到目标配置文件中。

示例性的，写入到此pod cgroup下的io.max、io.weight文件中，来实现IO限制规则的设置。

为了更清楚的表示本发明实施例，以Kubernetes云平台为基础，构建服务质量控制系统，图4为基于Kubernetes云平台的服务质量控制系统，其中，该系统包括Master 10’(主控节点)和Node 20’(工作负载节点)。Master 10’包括：WarpStor UI 12’(控制面板)和WarpStor Controller 13’(核心控制器)；WarpStor Controller 13’包括：WarpStorManager 131’(管理器)和StorageQosPolicyController 132’(策略控制器)。Node 20’包括WarpStor Agent 21’(节点代理)；PodStorageQosRule Controller 211’(规则控制器)和StorageQosRuleEngine 212’(设置引擎)内置于WarpStor Agent21’中运行在Node 20’上。由图4可以看出，管理员可以预先创建资源配置类别，所有容器、资源配置策略、资源配置规则的变更都通过Kube-apiserver’11监控。基于Kubernetes云平台的服务质量控制系统可以实现本地块存储的服务质量控制作用。

图5为基于Kubernetes云平台的服务质量控制系统的主要组件工作流程示意图，如图5所示，StorageQosPolicyController作为资源配置策略的资源控制器，当用户进行资源配置策略或容器的操作时，通过List/Watch集群中Kube-apiserver来监听资源配置策略或容器的变化如创建、更新、删除，动态地实时更新(创建、更新、删除)资源配置策略对应PodStorageQosRule；PodStorageQosRule Controller作为资源配置规则的资源控制器，通过List/Watch集群中Kube-apiserver来监听资源配置规则的变化如创建、更新、删除，并动态地实时调用StorageQosRule Engine来更新(创建、更新、删除)资源配置规则所属容器的cgroup(v2)中的IO限制；StorageQosRuleEngine作为资源配置规则在节点上的设置引擎，直接与Linux内核的cgroup(v2)模块交互，将资源配置规则中的IOMax(IO带宽、IOPS)限制，IOWeight限制的配置转换为cgroup(v2)中的IO限制配置，设置到cgroup(v2)中，利用cgroup v2的功能最终实现容器应用对一个或多个块存储设备的IO限制。此方式仅依赖Linux操作系统提供的cgroup v2功能。

本发明实施例主要针对容器云平台本地块存储场景，基于Linux内核Cgroup v2提供的IO限制能力来限制Pod对块存储卷的IO。在实现容器IO限制的基础上，利用Kubernetes自定义资源机制来管理、保存存储QoS配置，提供给用户根据需求划分存储QoS优先级的能力，存储QoS优先级以自定义资源方式提供给用户设置、访问。

实施例三

图6为本申请实施例三提供的一种服务质量控制方法的流程示意图，该方法适用于基于容器云平台本地块存储提供服务质量控制的情况。该方法可以由上述实施例提供的服务质量控制系统执行，该系统可以由硬件和/或软件实现，并一般集成在云平台中。如图6所示，本实施例三提供的一种服务质量控制方法，具体包括如下步骤：

S301、对所创建的对外服务进程进行监听，当监听到对外服务进程中有第一目标对象更新时，根据第一目标对象更新相应的第二目标对象。

其中，第一目标对象包括资源配置策略或容器，第二目标对象包括资源配置规则。当用户在系统提供的交互界面上进行操作请求时，控制节点10会对用户的操作请求进行响应，操作请求可能是新建或删除容器，也可能是新建、删除或更新资源配置策略，此处不做具体限制。控制节点10会根据操作请求更新对应操作请求的对外服务进程，当通过对外服务进程监听到容器或者资源配置策略发生变化时，根据变化情况更新资源配置规则。

S302、访问对外服务进程并监听，当监听到对外服务进程中有第二目标对象更新时，根据第二目标对象更新第二目标对象关联容器的资源配置。

对于对外服务进程的监听是持续的，也可以理解为是提前设置且持续工作的。每当对外服务进程中资源配置规则发生变化时，都可以监听到其变化，然后进行后续操作。由于一直在监听对外服务进程，当更新资源配置规则后，可以监听到资源配置规则发生变化，可以根据资源配置规则更新关联的容器对应的资源配置。

本发明实施例所提供的服务质量控制方法可由本发明任意实施例所提供的服务质量控制系统执行，具备执行方法相应的功能模块和有益效果。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本发明的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (10)

1.一种服务质量控制系统，其特征在于，包括：控制节点和工作负载节点；其中，

所述控制节点，用于对所创建的对外服务进程进行监听，当监听到所述对外服务进程中有第一目标对象更新时，根据所述第一目标对象更新相应的第二目标对象；

所述工作负载节点，用于访问所述对外服务进程并监听，当监听到所述对外服务进程中有第二目标对象更新时，根据所述第二目标对象更新所述第二目标对象关联容器的资源配置。

2.根据权利要求1所述的系统，其特征在于，所述第一目标对象包括资源配置策略或容器，所述第二目标对象包括资源配置规则。

3.根据权利要求1所述的系统，其特征在于，所述控制节点，包括：

控制面板，用于向用户提供可视化界面，接收用户在所述可视化界面中的资源更新请求；

核心控制器，用于基于所述资源更新请求，更新所述第一目标对象，根据所述第一目标对象更新所述第二目标对象。

4.根据权利要求3所述的系统，其特征在于，所述核心控制器，包括：

管理器，用于对所述控制面板反馈的资源更新请求进行解析，基于解析结果在所述对外服务进程中更新第一目标对象；

策略控制器，用于当接收到所述外服务进程发送的第一目标对象更新通知时，基于所述第一目标对象的更新事件，在所述外服务进程上更新第二目标对象。

5.根据权利要求4所述的系统，其特征在于，所述策略控制器，具体用于：

若所述更新事件为新增资源配置策略，则针对新增资源配置策略关联各容器，分别创建与各所述容器相关联的资源配置规则；

若所述更新事件为新增容器，则判断所述容器是否与资源配置策略匹配，若匹配，则创建与所述容器关联的资源配置规则；

若所述更新事件为删除资源配置策略或容器，则删除所述资源配置策略相关联的资源配置规则或所述容器相关联的资源配置规则；

若所述更新事件为资源配置策略内容变更，则根据变更内容修改与所述资源配置策略相关联的资源配置规则中对应内容。

6.根据权利要求1所述的系统，其特征在于，所述工作负载节点，包括：

规则控制器，用于当接收到所述对外服务进程发送的第二目标对象更新通知时，基于所述第二目标对象的更新事件，确定对应的目标限制规则；

设置引擎，用于将所述目标限制规则转化为目标控制参数，并将所述目标控制参数写入配置文件中，以实现容器对各存储卷的服务质量控制。

7.根据权利要求6所述的系统，其特征在于，所述规则控制器，具体用于：

当接收到所述外服务进程发送的第二目标对象更新通知时，若所述第二目标对象更新情况为创建资源配置规则或更新资源配置规则内容，则基于所述资源配置规则中记录的配置信息，确定目标限制规则。

8.根据权利要求7所述的系统，其特征在于，所述规则控制器用于基于所述第二目标对象中记录的配置信息确定目标限制规则的步骤包括：

确定所述资源配置规则中记录的类别名及关联容器；

基于所述类别名，结合预设的类别信息表，确定与所述类别名对应的IO限制信息；

基于所述关联容器的属性信息，确定所述关联容器挂载的存储卷；

遍历各所述存储卷，将各所述存储卷与所述IO限制信息更新至目标限制规则中。

9.根据权利要求6所述的系统，其特征在于，所述设置引擎具体用于：

根据所述目标限制规则中容器的标识号，遍历容器配置文件目录，确定所述容器的目标配置文件；

将所述目标限制规则转换为目标控制参数；

将所述目标控制参数写入到所述目标配置文件中。

10.一种服务质量控制方法，其特征在于，包括：

对所创建的对外服务进程进行监听，当监听到所述对外服务进程中有第一目标对象更新时，根据所述第一目标对象更新相应的第二目标对象；

访问所述对外服务进程并监听，当监听到所述对外服务进程中有第二目标对象更新时，根据所述第二目标对象更新所述第二目标对象关联容器的资源配置。

Images