CN115391058A - 一种基于sdn的资源事件处理方法、资源创建方法及系统 - Google Patents

Abstract

本发明提供了一种基于SDN的资源事件处理方法、资源创建方法及系统，该基于SDN的资源事件处理方法包括：获取资源所分别对应的队列及队列协程，将若干事件按照资源类型归类并分发至资源对应的队列中；队列协程同步从对应队列中获取事件，并创建事件对应的事件协程以执行事件对应的事件处理操作；其中，事件由资源变化予以定义。通过本发明，实现了提升不同种类资源的事件处理性能的目的。

Description

一种基于SDN的资源事件处理方法、资源创建方法及系统

技术领域

本发明涉及容器网络技术领域，尤其涉及一种基于SDN的资源事件处理方法、资源创建方法及系统。

背景技术

CNI(Container Network Interface，容器网络接口)定义了一套标准，提供了规范文档以及一些标准实现将容器网络配置方案与容器平台方案解耦。当前的CNI种类繁多，实现方法各不相同，具体的实现功能也各不相同。有些仅实现了基础的CNI功能(例如，Flannel)，有些会增加额外的自定义资源实现某些高级功能(例如，Calico、Clilum、SDNCNI等)。

当前软件定义网络(Software Defined Network，SDN)下的容器网络接口(即，前述SDN CNI)，不仅实现了基本的CNI的功能，例如，ADD(将容器将入网络)、DEL(将容器移出网络)以及IPAM(IP地址管理)等；同时还依赖SDN控制器实现了某些高级的功能，例如，7层负载均衡、Namespace网络隔离、Pod多网卡以及端口镜像的等。另外，还实现了通过List/Watch机制动态监听Kubernetes平台的资源变化，然后获取资源变化事件，将资源变化事件放入一个队列中，最后通过另一个模块从队列中获取事件并调用CNI接口对事件执行事件处理操作。

然而，现有技术中的SDN CNI在实现前述获取资源变化事件并执行事件处理操作的过程中，资源变化事件被放入一个队列中(参图3所示出，Namespace资源、Pod资源、Endpoint资源、Service资源、Ingress资源、Network Policy资源以及自定义资源所分别对应的事件均放入主队列中)；同时，只有一个协程从队列中获取事件以执行事件处理操作；另外，多种资源事件或者相同资源的多个事件必须按照队列中的顺序予以执行。因此，前述过程存在事件处理性能低的缺陷。

另外，由于Kubernetes平台的资源之间存在某些依赖关系(例如，Endpoint资源的创建必须等待Service资源以及Pod资源创建完成后，才能实现Endpoint资源的创建)，因此监听的事件也是存在一定的顺序的，从而导致事件的处理也必须是按照一定顺序执行。而在大规模场景下，若发生容器资源并发创建的情况，则会导致单个的资源处理需要较长的时间；或者，在集群不稳定的时候，队列中的事件容易出现积压的情况，从而无法保证集群的正常运行。

此外，大规模场景下，同一个资源的创建可能存在多个事件(例如，创建Pod资源存在4个事件，即，创建Pod、调度完成指定node-name、IP地址分配完成以及状态切换成running)，而当多个Pod资源同时创建时，每个Pod事件的顺序是交叉的，但是事件的处理需按照一定顺序，从而存在单个Pod的创建时间较长的缺陷。

有鉴于此，有必要对现有技术中的资源事件处理方法予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示一种基于SDN的资源事件处理方法、资源创建方法及资源创建系统，用以解决现有技术中由于存在不同资源对应的多个事件必须按照顺序执行所存在的无法实现并发的缺陷以及单个资源的创建存在时间较长的缺陷所导致的基于SDN架构中事件处理性能低的问题。

为实现上述目的，本发明提供了一种基于SDN的资源事件处理方法，包括：

获取资源所分别对应的队列及队列协程，将若干事件按照资源类型归类并分发至资源对应的队列中；

队列协程同步从对应队列中获取事件，并创建事件对应的事件协程以执行事件对应的事件处理操作；

其中，事件由资源变化予以定义。

作为本发明的进一步改进，所述事件由资源类型以及事件类型予以共同定义，以基于所述资源类型以及事件类型确定所述事件对应的事件处理操作是否被执行。

作为本发明的进一步改进，所述资源类型包括：Kubernetes资源和/或自定义资源；

所述事件类型包括：资源创建事件、资源更新事件以及资源删除事件中的任意一种；其中，事件的顺序关系为资源创建事件、资源更新事件以及资源删除事件，所述资源创建事件与所述资源删除事件仅执行一次。

作为本发明的进一步改进，所述Kubernetes资源包括：Namespace资源、Pod资源、Endpoint资源、Service资源、Ingress资源以及Network Policy资源中的一种或者任意几种组合；其中，资源的依赖关系为Namespace资源为优先级最高的资源，Endpoint资源的创建依赖于Pod资源与Service资源的创建，Ingress资源的创建依赖于Service资源的创建；

作为本发明的进一步改进，资源由数据结构予以定义；

所述数据结构包括：资源所依赖的父资源列表、资源所包含的事件类型、资源创建事件对应事件协程、资源更新事件对应事件协程、资源删除事件对应事件协程、资源被依赖的源资源列表以及资源发生变化时对应的时间戳中的一种或者任意几种组合；

所述资源、队列以及队列协程具唯一的归类关系，所述队列协程顺序地获取队列中的事件，并创建事件协程以执行事件对应的事件处理操作。

作为本发明的进一步改进，所述执行事件对应的事件处理操作，包括：

判断事件对应的资源类型所指定的资源是否存在数据结构；

若是，基于事件清理逻辑确定是否忽略所述事件；

若否，创建资源对应的数据结构，并基于事件清理逻辑确定是否忽略所述事件。

作为本发明的进一步改进，所述事件清理逻辑包括对冗余事件的清理逻辑以及对无效事件的清理逻辑。

作为本发明的进一步改进，所述对冗余事件的请求逻辑具体为：

判断当前事件对应的时间戳是否为当前事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳；若是，执行当前事件对应的事件处理操作；若否，忽略当前事件；

或者，

基于当前事件的资源类型所指定的资源对应状态信息判断当前事件是否为冗余事件；若是，忽略当前事件；若否，执行当前事件对应的事件处理操作。

作为本发明的进一步改进，所述对无效事件的清理逻辑由事件对应的资源类型所指定的资源的依赖关系以及事件类型对应的顺序关系予以确定。

作为本发明的进一步改进，所述对无效事件的清理逻辑具体为：

若当前事件为资源删除事件，则判断所述资源删除事件所指定的资源被依赖的源资源列表所定义的资源以及所依赖的父资源列表所定义的资源是否被删除，并在所述被依赖的源资源列表所定义的资源以及所依赖的父资源列表所定义的资源均被删除时，将所述资源删除事件定义为无效事件并忽略所述无效事件；否则，执行所述资源删除事件对应的事件处理操作。

作为本发明的进一步改进，所述清理逻辑还包括：

若当前事件为资源创建事件或者资源更新事件，则判断资源创建事件或者资源更新事件所指定的资源是否存在所依赖的父资源列表，并在存在所依赖的父资源列表时，执行资源创建事件或者资源更新事件所分别对应的事件处理操作，否则将所述资源创建事件或者资源更新事件重新放入当前事件指定的资源对应的队列中。

作为本发明的进一步改进，在当前事件执行对应的事件处理操作时，判断是否存在其他事件协程执行与当前事件相同的事件处理操作，并仅在存在其他事件协程执行相同的事件处理操作时，拒绝并删除当前事件。

基于相同发明思想，本申请还揭示了一种基于SDN的资源创建方法，包括：

响应于客户端所发起的资源创建请求，触发资源变化的监听事件，并获取通过如前述任一项发明创造所揭示的基于SDN的资源事件处理方法所产生的数据；

创建容器并基于所述执行事件处理操作所产生的数据创建并配置容器网卡。

作为本发明的进一步改进，将所述执行事件处理操作所产生的数据下发至虚拟路由组件，并调用CNI组件以从所述虚拟路由组件中获取数据，以创建并配置容器网卡。

最后，基于相同发明思想，本申请还揭示了一种基于SDN的资源创建系统，包括：

控制节点、SDN CNI以及SDN控制器；

所述控制节点响应于客户端所发起的资源创建请求，触发资源变化的监听事件，并在监听到发生资源变化时，获取由部署于SDN CNI的manager组件通过如前述任一项发明创造所揭示的基于SDN的资源事件处理方法执行事件处理操作所产生的数据并下发至部署于SDN控制器的虚拟路由组件；

所述控制节点创建容器并调用部署于SDN CNI的CNI组件以从所述虚拟路由组件中获取执行事件处理操作所产生的数据，以基于所述数据创建并配置容器网卡。

作为本发明的进一步改进，所述资源变化的监听事件由控制节点所部署的APIServer予以实现。

与现有技术相比，本发明的有益效果是：

在本申请中，通过为不同的资源单独创建一个队列以及用于处理队列中事件的队列协程，以基于队列协程同步从对应的队列中获取事件进行处理(即，创建事件对应的事件协程以执行事件对应的事件处理操作)，解决了现有技术中将所有事件均放入一个主队列中，以通过主队列协程从主队列中获取事件执行事件对应的事件处理操作所存在事件处理性能低的问题，通过资源所分别对应的队列协程同步执行，即，多队列协程同步执行，从而实现了提升不同种类资源的事件处理性能的目的。

附图说明

图1为本发明所示出的一种基于SDN的资源事件处理方法的步骤流程图；

图2为运行图1所示出的一种基于SDN的资源事件处理方法的一种计算机系统在一种实施例中的拓扑图，且该计算机系统包含本发明一种基于SDN的资源创建系统；

图3为不同资源对应的事件均放入主队列的拓扑图；

图4为不同资源对应队列的拓扑图；

图5为事件基于时间戳排序的拓扑图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

需要说明的是，Kubernetes是一种容器集群管理系统，也被称之为K8S。Kubernetes提供了应用部署、规划、更新以及维护的一种机制。Kubernetes主要由控制节点(即，master节点)以及工作负载节点(即，node节点)构成，其中，控制节点11属于平台的控制平面，负责平台的决策，工作负载节点数据平台的数据平面，负责为容器提供运行环境。前述工作负载节点在基于Kubernetes架构所组建的云平台中视为计算节点的上位概念。

在本发明的应用场景下，资源种类包括：Kubernetes资源和/或自定义资源；其中，Kubernetes资源包括Namespace资源、Pod资源、Endpoint资源、Service资源、Ingress资源以及Network Policy资源中的一种或者任意几种组合；自定义资源例如可以是Network资源。另外，资源之间的依赖关系为Namespace资源为优先级最高的资源，Endpoint资源的创建依赖于Pod资源与Service资源的创建，Ingress资源的创建依赖于Service资源的创建。Kubernetes的事件类型分为：资源创建事件(即，Create)、资源更新事件(即，Modify)以及资源删除事件(即，Delete)；其中，事件的顺序关系为资源创建事件、资源更新事件以及资源删除事件；另外，创建事件与删除事件仅执行一次，而更新事件可能会执行多次。Kubernetes支持用户或者管理员在嵌布形成GUI(即，图形用户界面)的客户端通过指令或者代码的输入，以自定义或者从资源对象库(CRD库)中以注册方式或者调用方式自定义出资源，例如，Network资源；由此，提高了对资源事件的处理效率，尤其地，可在不修改Kubernetes源代码的基础上便捷地扩展Kubernetes的功能。

请参图1至图5所示，本发明示出了一种基于SDN的资源事件处理方法(以下或简称“资源事件处理方法”)的一种具体实施方式。

本发明所揭示的一种基于SDN的资源事件处理方法的应用场景为基于SDN CNI获取Kubernetes的资源变化所形成的事件并执行事件对应的事件处理操作。该资源事件处理方法可以运行在部署有Kubernetes10、SDN CNI20以及SDN控制器30的计算机系统100中，还可以运行在部署有一个或者多个计算机系统100的云平台中，该云平台可以被理解为由超融合一体机、计算机、服务器、数据中心或者便捷式终端通过虚拟化技术所形成的一种服务或者系统。申请人在实施例中主要以计算机系统100为范例示范性说明。

示例性地，本发明所揭示的一种基于SDN的资源事件处理方法，首先，获取资源所分别对应的队列及队列协程，将若干事件按照资源类型归类并分发至资源对应的队列中；其次，队列协程同步从对应队列中获取事件，并创建事件对应的事件协程以执行事件对应的事件处理操作；其中，事件由资源变化予以定义。

需要说明的是，本发明为不同的资源单独创建一个队列以及用于处理队列中事件的队列协程，区别于现有技术中仅存在一个主队列以及用于处理主队列中事件的主队列协程。具体为：基于现有技术中将资源变化事件(即，事件)均放入一个队列(即，主队列)中，通过主队列对应的主队列协程从主队列中获取事件，并按照资源类型对事件进行归类，然后分发至资源对应的队列中。资源各自单独的队列协程分别从队列中获取事件并创建事件对应的事件协程以执行事件对应的事件处理操作。通过前述为不同的资源单独创建一个队列以及用于处理队列中事件的队列协程，以基于队列协程同步从对应的队列中获取事件进行处理(即，前述创建事件对应的事件协程以执行事件对应的事件处理操作)，解决了现有技术中将所有事件均放入一个主队列中，以通过主队列协程从主队列中获取事件执行事件对应的事件处理操作所存在事件处理性能低的问题，通过资源所分别对应的队列协程同步执行，即，多队列协程同步执行，从而实现了提升不同种类资源的事件处理性能的目的。

另外，在执行事件对应的事件处理操作之前，首先确定事件对应的资源类型所指定的资源是否存在数据结构，在存在数据结构时，基于事件清洗逻辑确定是否忽略该事件。具体地，事件清洗逻辑包括：对冗余事件的清洗逻辑以及对无效事件的请求逻辑。其中，对冗余事件的清洗逻辑具体为：判断当前事件对应的时间戳是否为当前事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳，并在当前事件对应的时间戳为最新时间戳时，执行当前事件对应的事件处理操作；否则，判定当前事件为冗余事件并忽略当前事件；或者基于资源的状态信息判断当前事件是否为冗余事件，并在判定当前事件为冗余事件时忽略当前事件；否则，执行当前事件对应的事件处理操作。由于事件对应的时间戳是指接收到该事件的时间点，可以基于该时间点表明事件之间的依赖关系或者执行顺序，因此，当资源及内存中存在比当前事件对应的时间戳更新的时间戳(即，当前事件对应的时间戳不为资源中的最新的时间戳)，则判定当前事件为冗余事件，为了避免执行旧的数据导致资源异常，同时也为了减少无效事件对资源的消耗，提升事件处理性能，则将冗余事件忽略(也可以理解为将冗余事件删除)；或者，基于当前事件的资源类型所指定的资源对应状态判断当前事件是否为冗余事件，具体为：例如，Pod资源创建事件包括四个事件，即，创建Pod、调度完成指定node-name、IP地址分配完成以及状态切换成running，而对于CNI组件来说，由于没有调度没有节点信息，无法创建网络资源，因此可以不需要执行创建Pod的事件，即，可以将创建Pod的事件直接忽略；同时，最后一个将状态切换成running也不需要处理，因为对于CNI组件来说不会产生任何数据上的变化，因此也可直接忽略该事件(即，前述状态切换成running的事件)。通过前述对具体事件基于对冗余事件的清洗逻辑以确定是否忽略该事件的阐述，基于时间戳判断当前事件是否为旧的事件(即，当前事件的时间戳不为当前事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳)，将旧的事件判定为冗余事件并忽略该冗余事件，避免执行旧的数据导致资源所包含的数据出现异常；同时，还通过资源对应状态信息判断当前事件是否为冗余事件并忽略该冗余事件，从而实现了减少冗余事件对资源的消耗，同时还提高了事件处理的效率，以最终达到了提高不同种类资源的处理性能的效果。

对无效事件的清洗逻辑由事件对应的资源类型所指定的资源的依赖关系以及事件类型的顺序关系予以确定。具体为：若当前事件为资源删除事件，则判断资源删除事件所指定的资源被依赖的源资源列表所定义的资源以及所依赖的父资源列表所定义的资源是否被删除，并在该源资源列表所定义的资源以及父资源列表所定义的资源均被删除时，将该删除事件定义为无效事件并忽略该无效事件；否则，执行当前事件对应的事件处理操作。例如，由于在SDN CNI中会给Service资源创建一个LB对象，而Endpoint资源是LB对象的一个member，因此只有在Service资源创建完成时才会创建LB对象，从而才能够给LB对象添加member(即，前述Endpoint资源)。基于上述Endpoint资源与Service资源的依赖关系，若当前事件为Service资源删除事件，则不需要对Service资源被依赖的源资源列表进行判断，直接执行Service资源删除事件对应的事件处理操作；若当前事件为Endpoint资源删除事件，则判断Service资源是否存在，若Service资源不存在或者正在执行Service资源删除事件对应的事件处理操作，则忽略该Endpoint资源删除事件，否则(即，Service资源存在同时也没有执行Service资源删除事件对应的事件处理操作)执行Endpoint资源删除事件对应的事件处理操作。若当前事件为资源创建事件或者资源更新事件，则判断资源创建事件或者资源更新事件所指定的资源是否存在所依赖的父资源列表，并在存在所依赖的父资源列表时，执行资源创建事件或者资源更新事件所分别对应的事件处理操作，否则(即，不存在所依赖的父资源列表)，则将该资源创建事件或者资源更新事件重新放入当前事件指定的资源对应的队列中，以等待下次循环处理。资源创建事件或者资源更新事件需要基于资源之间的依赖关系，判断资源所依赖的父资源列表所定义的资源是否存在，仅在存在时，执行资源创建事件或者资源更新事件对应的事件处理操作。例如，前述Endpoint资源的创建依赖于Pod资源与Server资源的创建，则Endpoint资源所依赖的父资源所定义的资源为Pod资源与Server资源，因此，若当前事件为Endpoint资源创建事件，则需要判断是否存在Pod资源与Server资源，并在存在Pod资源与Server资源时，执行Endpoint资源创建事件对应的事件处理操作，否则(即，不存在Pod资源与Server资源时)，则将Endpoint资源创建事件重新放入Endpoint资源对应的队列中，以等待下次循环处理。通过前述基于资源的依赖关系及资源所包含的数据结构执行事件对应的事件处理操作，从而实现了在事件处理过程中保护资源之间的依赖关系的同时，还省略了对无效事件的事件处理操作，以减少无效事件对资源的消耗，提高了事件处理的效率，最终达到了提高不同资源种类的处理性能的效果；同时，当接收到资源删除事件时，表明该资源已经需要被清理掉了，则判定关于该资源的资源创建事件和/或资源更新事件均为无效事件，则对资源创建事件和/或资源更新事件及其事件协程均忽略(即，删除)，以进一步地省略了对无效事件的事件处理操作，以减少无效事件对资源的消耗，达到了提高不同资源种类的处理性能的效果。

此外，在当前事件执行对应的事件处理操作时，判断是否存在其他事件协程执行与当前事件相同的事件处理操作，并仅在存在其他事件协程执行相同的事件处理操作时，拒绝并删除当前事件。不需要多个事件协程以运行相同的事件，因此当存在其他事件协程执行与当前事件相同的事件处理操作时，则将当前事件删除，以减少相同事件对事件协程及资源的消耗，提高了资源对应队列中事件的处理效率，从而进一步地达到了提高不同资源种类的处理性能的效果。

参图1所示，在本实施方式中，一种基于SDN的资源事件处理方法至少包括以下步骤S1至步骤S2。

步骤S1、获取资源所分别对应的队列及队列协程，将若干事件按照资源类型归类并分发至资源对应的队列中。

示例性地，参图2所示，一种计算机系统100内部署Kubernetes10、SDN CNI20以及SDN控制器30；其中，Kubernetes10部署控制节点11以及工作负载节点12，控制节点11部署API Server111，工作负载节点12部署Kubelet121，SDN CNI20部署manager组件21以及CNI组件22，SDN控制器30部署API服务31以及虚拟路由组件32。

需要说明的是，部署于SDN CNI20的manager组件21监听Kubernetes10的APIServer111，以获取Kubernetes10的资源变化，并在发生资源变化时，执行本发明所揭示的一种基于SDN的资源事件处理方法。在执行资源事件处理方法之后，manager组件21将前述执行资源事件处理方法所产生的数据通过部署于SDN控制器30的API服务31下发至部署于SDN控制器30的虚拟路由组件32。在Kubernetes 10发生资源变化时，工作负载节点12所部署的Kubelet121调用部署于SDN CNI20的CNI组件22，以通过CNI组件22获取虚拟路由组件32中的数据(即，前述通过部署于SDN控制器30的API服务31下发至部署于SDN控制器30的虚拟路由组件32的数据)，并基于该数据创建并配置容器网卡。

另外，前述部署于SDN CNI20的manager组件21监听Kubernetes10的APIServer111，以获取Kubernetes10的资源变化，还可以是Kubernetes10在发生资源变化时，主动调用SDN CNI20对资源变化对应的事件进行处理。

具体地，首先，为不同资源单独创建一个队列以及用于处理队列中所包含事件的协程，资源、队列以及队列协程具唯一的归类关系，队列协程顺序地获取队列中的事件，并创建事件协程以执行事件对应的事件处理操作。参图4所示，资源监视器(即，ResourceMonitor)通过List/Watch机制监听Kubernetes10的资源变化，此时，根据资源种类还会划分相应的监视器对象(即，Monitor对象)，当发生资源变化时，资源对应的监视器对象会获取资源变化对应的事件，并将该事件放入资源对应的队列中。例如，Namespace资源、队列1、队列协程1具唯一的归类关系，Pod资源、队列2、队列协程2具唯一的归类关系，Endpoint资源、队列3、队列协程3具唯一的归类关系等等。资源监视器监听Kubernetes的资源变化，当发生资源变化时，资源对应的监视器对象(即，Namespace资源的监视器对象、或者Pod资源的监视器对象、或者Endpoint资源的监视器对象等等)会获取资源变化对应的事件，并将该事件放入对应的队列中。若资源变化对应的事件的资源类型为Namespace资源，则Namespace资源的监视器对象获取该资源变化对应的事件，并放入Namespace资源对应的队列1中，以通过队列协程1获取队列1中的事件，并创建事件对应的事件协程以执行事件对应的事件处理操作；若资源变化对应的事件的资源类型为Pod资源，则Pod资源的监视器对象获取该资源变化对应的事件，并放入Pod资源对应的队列2中，以通过队列协程2获取队列2中的事件，并创建事件对应的事件协程以执行事件对应的事件处理操作等等。

当然，除了前述通过监视器对象获取资源变化对应的事件并将该事件放入资源对应的队列中，还可以是参图3所示，当监听到Kubernetes发生资源变化时，将发生变化的事件均放入一个队列(即，主队列)中，然后主队列对应的主队列协程从主队列中获取事件，将若干事件按照资源类型归类并分发至资源对应的队列中，例如，事件1对应的资源类型为Namespace资源，则将事件1分发至队列1中，以方便后续由队列协程1从队列1中获取事件，并创建事件对应的事件协程以执行事件对应的事件处理操作。

需要说明的是，List/Watch机制是Kubernetes系统中统一的异步消息传递方式，对系统的性能、数据一致性起到关键性的作用。客户端可以通过List/Watch机制监听APIServer中的资源的创建、更新或者删除事件，并针对事件类型调用相应的事件处理函数执行之间处理操作。在资源发生变化时形成资源事件，也可将资源事件简称为事件。manager组件21是运行本发明所示出的一种基于SDN的资源事件处理方法的载体，即，可以理解为本发明所示出的一种基于SDN的资源事件处理方法所包含的逻辑是运行于manager组件21中，manager组件21通过监听Kubernetes10的API Server111以实时监控每个资源的对应状态，从而运行本发明所示出的一种基于SDN的资源事件处理方法。

另外，前述资源(即，Namespace资源、Pod资源、Endpoint资源、Service资源、Ingress资源、Network Policy资源以及自定义资源等)由数据结构予以定义，数据结构包括：资源所依赖的父资源列表、资源所包含的事件类型、资源创建事件对应事件协程、资源更新事件对应事件协程、资源删除事件对应事件协程、资源被依赖的源资源列表以及资源发生变化时对应的时间戳中的一种或者任意几种组合。前述事件由资源类型以及事件类型予以共同定义，以方便后续基于资源类型以及事件类型确定事件对应的事件处理操作是否被执行。

此外，通过前述为不同资源单独创建一个队列，队列之间为相互独立、互不干扰的关系(即，图4中所示出的队列1、队列2、队列3、队列4、队列5、队列6、队列7之间为相互独立、互不干扰的关系)；同样，队列协程之间也为相互独立、互不干扰的关系(即，图4中所示出的队列协程1、队列协程2、队列协程3、队列协程4、队列协程5、队列协程6、队列协程7之间为相互独立、互不干扰的关系)。各自对应的队列协程从队列中获取事件(即，队列协程1从队列1中获取事件、队列协程2从队列2中获取事件、队列协程3从队列3中获取事件等等)以对队列协程中的事件进行处理(即，下述创建事件对应的事件协程以执行事件对应的事件处理操作)，解决了现有技术中将所有的事件均放入一个主队列中，以通过主队列协程从主队列中获取事件执行事件对应的事件处理操作所存在事件处理性能低的问题，通过下述资源所分别对应的队列协程同步执行(即，队列协程1至队列协程7分别且唯一对应地以同步方式从队列1至队列7中获取事件)，从而实现了提升对不同种类资源的事件处理性能的目的。

步骤S2、队列协程同步从对应队列中获取事件，并创建事件对应的事件协程以执行事件对应的事件处理操作。

具体地，队列协程同步从对应的队列中获取事件，即，在同一时间，队列协程1从队列1中获取事件，队列协程2从队列2中获取事件，队列协程3从队列3中获取事件等等，所有的动作(即，队列协程从对应的队列中获取事件)同步执行。在队列协程从队列中获取到事件后，首先判断事件对应的资源类型所指定的资源是否存在数据结构；若所指定的资源存在数据结构，则执行后续步骤，即，基于事件清洗逻辑确定是否忽略该事件；若所指定的资源不存在数据结构，则为所指定的资源创建资源对应的数据结构，然后再执行后续步骤(即，前述基于事件清洗逻辑确定是否忽略该事件)。

需要说明的是，前述说明资源由数据结构予以定义，在此不再赘述，因此可以将判断事件对应的资源类型所指定的资源是否存在数据结构理解为，判断事件对应的资源类型所指定的资源是否存在；若资源存在，则执行后续步骤(即，基于事件清洗逻辑确定是否忽略该事件)；若资源不存在，则创建资源(即，创建资源对应的数据结构)，以执行后续步骤。

在确定事件对应的资源类型所指定的资源的数据结构(即，在获取事件时本身就具有数据结构，或者在获取事件后创建的数据结构)后，为事件创建单独的事件协程，以执行事件对应的事件处理操作。在执行事件对应的事件处理操作之后，该事件协程自动删除，从而减少已经执行事件处理操作的协程对资源的消耗。

在为事件创建单独的事件协程后，基于事件清洗逻辑确定是否忽略该事件，从而确定是否执行事件对应的事件处理操作。事件清洗逻辑可以理解为用于对事件进行过滤的一种逻辑，通过事件清洗逻辑忽略掉不需要处理的事件，以提高事件处理的效率，从而实现提高不同种类资源的处理性能的效果。事件清洗逻辑包括：对冗余事件的清洗逻辑、对无效事件的清洗逻辑以及对其他情况事件的清洗逻辑。

对冗余事件的清洗逻辑具体为：判断当前事件对应的时间戳是否为当前事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳；若是，执行当前事件对应的事件处理操作；若否，基于当前事件的资源类型所指定的资源对应状态信息判断当前事件是否为冗余事件；若是，忽略当前事件；若否，执行当前事件对应的事件处理操作。

具体地，参图5所示，事件1、事件2、事件3、事件4以及事件5在队列中按照时间戳的先后顺序进行排序，事件1为最先被放入队列，因此事件1对应的时间戳为最早的时间戳，事件2、事件3以及事件4则依次排序，而事件5是最后被放入队列，因此事件5对应的时间戳为最新的时间戳。若当前事件为事件3，则判断当前事件对应的时间戳是否为当前事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳，也可以理解为判断当前事件是否为资源对应的队列中最新的时间戳对应的事件，而事件5对应的时间戳为最新的时间戳，因此判定事件3对应的时间戳不为资源对应的队列中最新的时间戳对应的事件，并将事件3定义为冗余事件，同时忽略该事件3并将事件3对应的事件协程删除。若当前事件为事件5，而事件5对应的时间戳为队列中最新的时间戳，则执行事件5对应的事件处理操作。或者，基于当前事件的资源类型所指定的资源对应状态判断当前事件是否为冗余事件。例如，Pod资源创建事件包括四个事件，即，创建Pod、调度完成指定node-name、IP地址分配完成以及状态切换成running，而对于CNI组件22来说，由于没有调度且没有节点信息(即，没有保存某一具体节点执行Pod调度所对应的信息，例如，该节点的虚拟IP地址等)，无法创建网络资源，因此可以不需要执行创建Pod且可以直接忽略；同时，也不需要执行最后一个将状态切换成running的事件处理操作，由于对于CNI组件22来说将状态切换成running的事件不会产生任何数据上的变化，因此可直接忽略该事件(即，前述状态切换成running)。此时，将第一个事件(即，创建Pod)和第四个事件(即，IP地址分配完成以及状态切换成running)定义为冗余事件。通过前述具体对冗余事件的清洗逻辑以确定是否忽略该事件的阐述，基于时间戳判断当前是否为旧的事件(即，当前事件的时间戳不为当前事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳)，将旧的事件判定为冗余事件并忽略该冗余事件，避免执行旧的数据导致资源所包含的数据出现异常；同时，还通过资源对应状态信息判断当前事件是否为冗余事件并忽略该冗余事件，从而实现了减少冗余事件对资源的消耗，以提高了事件处理的效率，最终达到了提高不同种类资源的处理性能的效果。在本申请中，旧的事件是一种基于时间戳的相对概念，例如，图5中的事件1为事件2～事件5对应的旧的事件，又例如，图5中的事件4为事件5对应的旧的事件。

需要说明的是，前述对事件对应的时间戳的判断仅仅是与事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳进行比较，即，与事件的资源类型所指定的资源对应的队列中的事件进行比较，并不是与其他资源的事件混合比较。例如，当前事件为Namespace资源创建事件，则仅将Namespace资源创建事件对应的时间戳与Namespace资源(即，Namespace资源创建事件的资源类型所指定的资源)对应队列中的事件所分别对应的时间戳进行比较。

对无效事件的清洗逻辑由事件对应的资源类型所指定的资源的依赖关系以及事件类型对应的顺序关系予以确定。具体为：若当前事件为资源删除事件，则判断该资源删除事件所指定的资源被依赖的源资源列表所定义的资源以及所依赖的父资源列表所定义的资源是否删除，并在源资源列表所定义的资源父资源列表所定义的资源均删除时，将该资源删除事件定义为无效事件并忽略该资源删除事件；否则(即，源资源列表所定义的资源未删除)，则执行资源删除事件对应的事件处理操作。例如，当前事件为A资源删除事件，A资源删除事件所指定的资源即为A资源，A资源被依赖的源资源列表所定义的资源为B资源以及C资源，A资源所依赖的父资源列表所定义的资源为D资源以及E资源。因此，需要判断B资源、C资源、D资源以及E资源是否均删除，仅在B资源、C资源、D资源以及E资源均被删除的时候，将A资源删除事件定义为无效事件并忽略该无效事件，同时删除A资源删除事件对应的事件协程；否则(即，B资源、C资源、D资源以及E资源中至少有一个未被删除)，执行A资源删除事件对应的事件处理操作。通过判断资源删除事件所指定的资源被依赖的源资源列表所定义的资源以及所依赖的父资源列表所定义的资源是否被删除予以确定是否执行资源删除事件对应的事件处理操作，以防止出现在执行资源删除事件(即，前述A资源删除事件)对应的事件处理操作时，由于被依赖的源资源列表所定义的资源(即，前述B资源以及C资源)以及所依赖的父资源列表所定义的资源(即，前述D资源以及E资源)未被删除所导致的资源的数据出现错乱的情况，从而保证了数据的准确性以及稳定性。

例如，Service资源与Endpoint资源。由于在SDN CNI中会给Service资源创建一个LB对象(即，LoadBalancer，负载均衡对象)，而Endpoint资源是LB对象的一个member(即，后端)，因此只有在Service资源创建完成时才会创建LB对象，从而才能够给LB对象添加member(即，前述Endpoint资源)。基于上述Endpoint资源与Service资源的依赖关系，若当前事件为Service资源删除事件，则不需要对Service资源被依赖的源资源列表进行判断，直接执行Service资源删除事件对应的事件处理操作；若当前事件为Endpoint资源删除事件，则判断Service资源是否存在，若Service资源不存在或者正在执行Service资源删除事件对应的事件处理操作，则忽略该Endpoint资源删除事件，否则(即，Service资源存在同时也没有执行Service资源删除事件对应的事件处理操作)执行Endpoint资源删除事件对应的事件处理操作。

另外，通过对无效事件的判定以及对无效事件的忽略，以避免执行无效事件对应的事件处理操作所导致的对资源的消耗，同时还省略对无效事件的处理步骤，以提高了事件处理的效率，以最终实现提高不同资源种类的处理性能的目的。

对其他情况事件的清洗逻辑具体为：若当前事件为资源创建事件或者资源更新事件，则判断资源创建事件或者资源更新事件所指定的资源是否存在所依赖的父资源列表所定义的资源，并在存在所依赖的父资源列表所定义的资源时，执行资源创建事件或者资源更新事件所分别对应的事件处理操作，否在将该资源创建事件或者资源更新事件重新放入当前事件指定的资源对应的队列中。例如，当前事件为A资源创建事件(或者A资源更新事件)，而A资源创建事件(A资源更新事件)所指定的资源即为A资源，A资源所依赖的父资源列表所定义的资源为B资源和C资源，则判断A资源所依赖父资源列表所定义的资源是否存在，即，判断B资源和C资源是否存在；若B资源和C资源存在，则执行A资源创建事件(或者A资源更新事件)对应的事件处理操作；若A资源创建事件(或者A资源更新事件)不存在，则将A资源创建事件(或者A资源更新事件)重新放入A资源对应的队列中，以等待下次循环处理。

需要说明的是，前述对三种事件清洗逻辑(即，对冗余事件的清洗逻辑、对无效事件的清洗逻辑以及对其他情况事件的清洗逻辑)的具体阐述，可以是对同一个事件进行三次清洗逻辑的判定，只要存在一次符合清洗逻辑所阐述的情况是时，则忽略该事件；也可以是择一或者择二地选择清洗逻辑以对某一事件进行判定；优选为，按照一定顺序对同一个事件进行三种清洗逻辑的判定，即，首先判断一个事件是否为冗余事件，并在该事件不为冗余事件时，再次判断该事件是否为无效事件，最后在该事件也不为无效事件时，再次按照其他情况事件的清洗逻辑对其(即，该事件)进行判定，最终在该事件三种情况均不符合时(即，不属于冗余事件、不属于无效事件、不属于其他情况)，执行事件对应的事件处理操作，当然，前述三次判断顺序可随意调换。通过三种清洗逻辑对事件的判定，进一步地减少了不需要执行的事件对资源的消耗，以提高事件处理的效率，从而实现提高不同种类资源的处理性能的效果。

另外，通过前述三种事件清洗逻辑，基于资源之间的依赖关系以及资源所包含的数据结构确定是否忽略该事件，从而实现了在事件处理过程中保护资源之间的依赖关系的同时，省略了对不需要处理的事件的处理，不仅减少了对资源的消耗，还提高了事件处理的效率，从而实现提高不同种类资源的处理性能的效果。

此外，当接收到资源删除事件时，则表明该资源已经需要被清理掉了，则判定关于该资源的资源创建事件和/或资源更新事件均为无效事件，则将资源创建事件和/或资源更新事件及其事件协程均进行删除，以进一步地省略了对无效事件的事件处理操作，以减少无效事件对资源的消耗，达到了提高不同资源种类的处理性能的效果。

还有，在当前事件执行对应的事件处理操作，判断是否存在其他事件协程执行与当前事件相同的事件处理操作，并仅在存在其他事件协程执行相同的事件处理操作时，拒绝并删除当前事件。不需要多个事件协程以运行相同的事件，因此当存在其他事件协程执行与当前事件相同的事件处理操作时，则将当前事件删除，以减少相同事件对资源的消耗，提高了资源对应队列中事件的处理效率，从而进一步地达到了提高不同资源种类的处理性能的效果。

还需要说明的是，本发明所示出的不同协程(即，主队列对应的主队列协程、队列对应的队列协程以及事件对应的事件协程等)，其中，主队列是指，不同资源的事件均放入同一个队列所对应的队列即为主队列，主队列协程是指，从主队列中获取事件以对事件进行分发的协程；队列是指，不同资源所分别对应的单独的队列，队列协程是指用于从主队列中获取事件以进行处理的协程；事件协程是指，对某一个事件(例如，Service资源删除事件)单独创建的协程，用以具体处理某一事件(例如，用以执行Service资源删除事件对应的事件处理操作)，在该事件协程具体负责处理的事件处理完之后，该事件协程自动删除，从而减少已经执行事件处理操作的协程对资源的消耗。

现有技术中造成主队列协程从主队列中获取事件执行事件对应的事件处理操作所存在事件处理性能低的问题包括以下几点：

第一点，在Kubernetes中资源一般都属于Namespace(而没有Namespace属性的资源属于公共资源，并非用户资源，本实施例不对该资源进行阐述)，Namespace本身也是一种资源，即，Namespace资源，因此在创建任何资源时，需要首先创建Namespace，也就是说资源之间存在相互的依赖关系，同样其他资源也存在相互的依赖关系(例如，Endpoint资源与Service资源等)。Kubernetes的接口本身会处理资源之间的依赖关系，也可以理解为，Kubernetes的接口会校验以保证Namespace资源存在的情况下，建立其他资源，因此，产生的资源变化对应事件也就自然而然产生了先后顺序，一般场景下(即，小规模场景下)，只需要CNI按照顺序一个一个处理事件，即可以保证资源的正常执行；而在一些大规模场景下，现有技术中的资源事件处理方法，并不能满足大规模场景的需求，而顺序执行存在事件处理性能低的缺陷；同时，部分事件处于无效事件或者冗余事件，而执行这些事件不仅增加了资源的消耗还降低了事件处理的效率，从而导致事件处理性能低。因此现有技术中的资源事件处理方法并不能满足大规模场景的需求。

第二点，在很多CNI(例如，SDN CNI)中，并不需要关注Endpoint资源、Service资源以及Ingress资源等资源的实现(由于Kubernetes中存在kube-proxy组件以实现Endpoint资源以及Service资源的功能，存在nginx-controller组件以实现Ingress资源的功能)，但是在SDN中会统一替换为SDN实现Endpoint资源、Service资源以及Ingress资源等资源的功能，从而实现资源功能上的统一的目的，因此CNI只需要处理Pod资源即可，从而要求不高的场景下，即使是顺序处理资源所有的事件，也能满足正常的使用需求；而在要求较高的场景下，前述顺序处理资源所有的事件则不能满足用户的需求，单个资源处理较长事件，就会产生积压的情况，从而导致Kubernetes无法正常运行。

综上所述，本发明所揭示的一种基于SDN的资源事件处理方法，解决了现有技术中将所有事件放入主队列中，然后依次执行事件对应的事件处理操作所导致事件处理性能低的问题，同时还解决了单个资源处理事件的时间较长所导致的事件积压的问题，通过队列协程同步从各自对应的队列中获取事件，以实现了资源之间事件处理的独立(即，单个资源处理事件的事件较长不会对其他资源产生影响)，同时提高了事件处理的效率，还基于三种清理逻辑对不需要事件进行清理(即，忽略)，在保护资源之间的依赖关系的同时，减少了对不需要事件的处理，更进一步提高了资源处理的效率，以最终实现了提高事件处理性能的目的。

基于相同发明思想，本实施例还揭示了一种基于SDN的资源创建方法，包括：响应于客户端所发起的资源创建请求，触发资源变化的监听事件，并获取通过前述基于SDN的资源事件处理方法所产生的数据；创建容器并基于执行事件处理操作所产生的数据创建并配置容器网卡。

结合图2所示，一种计算机系统100内部署Kubernetes10、SDN CNI20以及SDN控制器30；其中，Kubernetes 10部署控制节点11以及工作负载节点12，控制节点11部署APIServer111，工作负载节点12部署Kubelet121，SDN CNI20部署manager组件21以及CNI组件22，SDN控制器30部署API服务31以及虚拟路由组件32。

需要说明的是，部署于SDN CNI20的manager组件21监听Kubernetes10的APIServer111，以获取Kubernetes10的资源变化，并在发生资源变化时，执行本发明所揭示的一种基于SDN的资源事件处理方法。在执行资源事件处理方法之后，manager组件21将前述执行资源事件处理方法所产生的数据通过部署于SDN控制器30的API服务31下发至部署于SDN控制器30的虚拟路由组件32。在Kubernetes 10发生资源变化时，工作负载节点12所部署的Kubelet121调用部署于SDN CNI20的CNI组件22，以通过CNI组件22获取虚拟路由组件32中的数据(即，前述通过部署于SDN控制器30的API服务31下发至部署于SDN控制器30的虚拟路由组件32的数据)，并基于该数据创建并配置容器网卡。

另外，前述部署于SDN CNI20的manager组件21监听Kubernetes10的APIServer111，以获取Kubernetes10的资源变化，还可以是Kubernetes10在发生资源变化时，由Kubernetes10主动调用SDN CNI20对资源变化对应的事件进行前述基于SDN的资源事件处理方法的步骤，从而进一步提高了Kubernetes10对多个工作负载节点12所发生的资源变动所导致数据发生变动场景中纳管多个工作负载节点12的实时性及准确性，并有利于减少SND CNI20的计算开销及网络开销。

此外，通过本发明所揭示的一种基于SDN的资源创建方法，在保证事件处理性能高的基础上，还提高了资源创建效率，从而最终提高了资源创建的性能。本实施例所揭示的基于SDN的资源创建方法基于前述所揭示的基于SDN的资源事件处理方法，两者相同部分的技术方案，相关细节参前所述，在此不再赘述。

基于相同发明思想，本实施例还揭示了一种基于SDN的资源创建系统，包括：控制节点11、SDN CNI20以及SDN控制器30；控制节点11响应于客户端所发起的资源创建请求，触发资源的监听事件，并在监听到发生资源变化时，获取由部署于SDN CNI20中的manager组件21通过前述基于SDN的资源事件处理方法所产生的数据并下发至部署于SDN控制器30的虚拟路由组件32；控制节点11创建容器并调用部署于SDN CNI20中的CNI组件22以从虚拟路由组件32中获取执行事件处理操作所产生的数据，以基于数据创建并配置容器网卡。其中，资源变化的监听事件由控制节点11所部署的API Server111予以实现。

结合图2所示，一种计算机系统100内部署Kubernetes10、SDN CNI20以及SDN控制器30；其中，Kubernetes 10部署控制节点11以及工作负载节点12，控制节点11部署APIServer111，工作负载节点12部署Kubelet121，SDN CNI20部署manager组件21以及CNI组件22，SDN控制器30部署API服务31以及虚拟路由组件32。

需要说明的是，部署于SDN CNI20的manager组件21监听Kubernetes10的APIServer111，以获取Kubernetes10的资源变化，并在发生资源变化时，执行本发明所揭示的基于SDN的资源事件处理方法。在执行资源事件处理方法之后，manager组件21将前述执行资源事件处理方法所产生的数据通过部署于SDN控制器30的API服务31下发至部署于SDN控制器30的虚拟路由组件32。在Kubernetes 10发生资源变化时，工作负载节点12所部署的Kubelet121调用部署于SDN CNI20的CNI组件22，以通过CNI组件22获取虚拟路由组件32中的数据(即，前述通过部署于SDN控制器30的API服务31下发至部署于SDN控制器30的虚拟路由组件32的数据)，并基于该数据创建并配置容器网卡。

另外，前述部署于SDN CNI20的manager组件21监听Kubernetes10的APIServer111，以获取Kubernetes10的资源变化，还可以是Kubernetes10在发生资源变化时，主动调用SDN CNI20对资源变化对应的事件进行处理。

此外，本实施例所揭示的一种基于SDN的资源创建系统与前述基于SDN的资源创建方法属于同一构思，其具体实现过程详见前述，在此不再阐述。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (16)

1.一种基于SDN的资源事件处理方法，其特征在于，包括：

获取资源所分别对应的队列及队列协程，将若干事件按照资源类型归类并分发至资源对应的队列中；

队列协程同步从对应队列中获取事件，并创建事件对应的事件协程以执行事件对应的事件处理操作；

其中，事件由资源变化予以定义。

2.根据权利要求1所述的基于SDN的资源事件处理方法，其特征在于，所述事件由资源类型以及事件类型予以共同定义，以基于所述资源类型以及事件类型确定所述事件对应的事件处理操作是否被执行。

3.根据权利要求2所述基于SDN的资源事件处理方法，其特征在于，所述资源类型包括：Kubernetes资源和/或自定义资源；

所述事件类型包括：资源创建事件、资源更新事件以及资源删除事件中的任意一种；其中，事件的顺序关系为资源创建事件、资源更新事件以及资源删除事件，所述资源创建事件与所述资源删除事件仅执行一次。

4.根据权利要求3所述的基于SDN的资源事件处理方法，其特征在于，所述Kubernetes资源包括：Namespace资源、Pod资源、Endpoint资源、Service资源、Ingress资源以及Network Policy资源中的一种或者任意几种组合；其中，资源的依赖关系为Namespace资源为优先级最高的资源，Endpoint资源的创建依赖于Pod资源与Service资源的创建，Ingress资源的创建依赖于Service资源的创建。

5.根据权利要求4所述的基于SDN的资源事件处理方法，其特征在于，资源由数据结构予以定义；

所述数据结构包括：资源所依赖的父资源列表、资源所包含的事件类型、资源创建事件对应事件协程、资源更新事件对应事件协程、资源删除事件对应事件协程、资源被依赖的源资源列表以及资源发生变化时对应的时间戳中的一种或者任意几种组合；

所述资源、队列以及队列协程具唯一的归类关系，所述队列协程顺序地获取队列中的事件，并创建事件协程以执行事件对应的事件处理操作。

6.根据权利要求5所述的基于SDN的资源事件处理方法，其特征在于，所述执行事件对应的事件处理操作，包括：

判断事件对应的资源类型所指定的资源是否存在数据结构；

若是，基于事件清理逻辑确定是否忽略所述事件；

若否，创建资源对应的数据结构，并基于事件清理逻辑确定是否忽略所述事件。

7.根据权利要求6所述的基于SDN的资源事件处理方法，其特征在于，所述事件清理逻辑包括对冗余事件的清理逻辑以及对无效事件的清理逻辑。

8.根据权利要求7所述的基于SDN的资源事件处理方法，其特征在于，所述对冗余事件的请求逻辑具体为：

判断当前事件对应的时间戳是否为当前事件的资源类型所指定的资源发生变化时对应的时间戳中最新的时间戳；若是，执行当前事件对应的事件处理操作；若否，忽略当前事件；

或者，

基于当前事件的资源类型所指定的资源对应状态信息判断当前事件是否为冗余事件；若是，忽略当前事件；若否，执行当前事件对应的事件处理操作。

9.根据权利要求7所述的基于SDN的资源事件处理方法，其特征在于，所述对无效事件的清理逻辑由事件对应的资源类型所指定的资源的依赖关系以及事件类型对应的顺序关系予以确定。

10.根据权利要求9所述的基于SDN的资源事件处理方法，其特征在于，所述对无效事件的清理逻辑具体为：

若当前事件为资源删除事件，则判断所述资源删除事件所指定的资源被依赖的源资源列表所定义的资源以及所依赖的父资源列表所定义的资源是否被删除，并在所述被依赖的源资源列表所定义的资源以及所依赖的父资源列表所定义的资源均被删除时，将所述资源删除事件定义为无效事件并忽略所述无效事件；否则，执行所述资源删除事件对应的事件处理操作。

11.根据权利要求7所述的基于SDN的资源事件处理方法，其特征在于，所述清理逻辑还包括：

若当前事件为资源创建事件或者资源更新事件，则判断资源创建事件或者资源更新事件所指定的资源是否存在所依赖的父资源列表，并在存在所依赖的父资源列表时，执行资源创建事件或者资源更新事件所分别对应的事件处理操作，否则将所述资源创建事件或者资源更新事件重新放入当前事件指定的资源对应的队列中。

12.根据权利要求1至11中任一项所述的基于SDN的资源事件处理方法，其特征在于，在当前事件执行对应的事件处理操作时，判断是否存在其他事件协程执行与当前事件相同的事件处理操作，并仅在存在其他事件协程执行相同的事件处理操作时，拒绝并删除当前事件。

13.一种基于SDN的资源创建方法，其特征在于，包括：

响应于客户端所发起的资源创建请求，触发资源变化的监听事件，并获取通过如权利要求1至12中任一项所述的基于SDN的资源事件处理方法所产生的数据；

创建容器并基于所述执行事件处理操作所产生的数据创建并配置容器网卡。

14.根据权利要求13所述的基于SDN的资源创建方法，其特征在于，

将所述执行事件处理操作所产生的数据下发至虚拟路由组件，并调用CNI组件以从所述虚拟路由组件中获取数据，以创建并配置容器网卡。

15.一种基于SDN的资源创建系统，其特征在于，包括：

控制节点、SDN CNI以及SDN控制器；

所述控制节点响应于客户端所发起的资源创建请求，触发资源变化的监听事件，并在监听到发生资源变化时，获取由部署于SDN CNI的manager组件通过如权利要求1至12中任一项所述的基于SDN的资源事件处理方法执行事件处理操作所产生的数据并下发至部署于SDN控制器的虚拟路由组件；

所述控制节点创建容器并调用部署于SDN CNI的CNI组件以从所述虚拟路由组件中获取执行事件处理操作所产生的数据，以基于所述数据创建并配置容器网卡。

16.根据权利要求15所述的基于SDN的资源创建系统，其特征在于，所述资源变化的监听事件由控制节点所部署的API Server予以实现。

Images