计算系统、容器网络配置方法及存储介质与流程

1.本技术涉及云计算技术领域，尤其涉及一种计算系统、容器网络配置方法及存储介质。


背景技术：

2.服务器虚拟化技术是云计算中基于基础设施层的关键技术。该技术通过对物理服务器进行虚拟化，实现在单台物理机上部署多台虚拟机(virtual machine，vm)。为提高服务器的资源利用率，降低使用成本，计算集群将多台虚拟机或物理机组成为一个有机的整体，进行统一管理，通过虚拟化技术将物理资源抽象为存储、计算、网络等各种资源组成的资源池，通过按需申请资源的方式提供给用户。
3.在实际应用中，为了实现对计算集群的资源管理，需要在中心云部署kubernetes(简称k8s)控制面程序，并先将计算节点统一接管到k8s控制面中，再在接入k8s的资源上部署应用容器向用户提供云计算服务。
4.应用容器对网络的需求各异。目前k8s使用容器网络接口(container network interface，cni)作为容器网络配置接口进行容器网络配置。k8s中各工作节点中的kubelet组件启动容器时，会调用cni的add接口，为容器添加网络。kubelet组件将pod销毁前，会调用cni的del接口，将容器从网络中删除。add和del接口只在pod启动和销毁时才被调用，因此，目前容器网络配置方式与容器生命周期紧密耦合，容器网络配置灵活性较差。例如，无法在容器运行时动态改变容器的网络属性等等。


技术实现要素：

5.本技术的多个方面提供一种计算系统、容器网络配置方法及存储介质，用以实现容器的网络配置过程与容器生命周期解耦，有助于提高容器网络配置的灵活性。
6.本技术实施例提供一种计算系统，包括：管控节点、计算集群和网络服务集群；所述计算集群包括多个工作节点；所述网络服务集群用于部署网络服务；
7.所述工作节点包括：网络服务对应的容器网络接口cni组件；
8.所述cni组件，用于将所述工作节点中部署的容器实例接入到所述网络服务；
9.所述容器实例通过所述网络服务访问其它网络。
10.本技术实施例还提供一种容器网络配置方法，包括：
11.确定目标工作节点部署的容器实例；
12.利用目标工作节点中的与网络服务集群对应的cni组件将所述容器实例接入到网络服务集群的网络服务，以供所述容器实例通过所述网络服务访问其它网络。
13.本技术实施例还提供一种存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述容器网络配置方法中的步骤。
14.在本技术实施例中，利用网络服务集群中的网络服务可为容器打通不同网络的能
力，在计算集群的工作节点中增设网络服务集群对应的容器网络接口(cni)组件，该cni组件可将工作节点中部署的容器实例接入到网络服务中，这样，容器实例可通过网络服务访问其它网络。cni组件可将工作节点中部署的容器实例接入到网络服务的过程，可发生在容器实例的生命周期的任意阶段，实现了容器网络配置与容器的生命周期的解耦，有助于提高容器网络配置的灵活性。
附图说明
15.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
16.图1为一些开源方案提供的容器网络配置方式进行容器网络配置的过程示意图；
17.图2为本技术实施例提供的计算系统的结构示意图；
18.图3为本技术实施例提供的容器网络配置流程示意图；
19.图4为本技术实施例提供为容器分配虚拟网卡的流程示意图；
20.图5为本技术实施例提供的计算系统的架构思维导图；
21.图6为本技术实施例提供的网络服务创建过程示意图；
22.图7为本技术实施例提供的网络配置方法的流程示意图。
具体实施方式
23.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
24.在一些开源的cni插件(如multus-cni插件)，可调用多个其它的cni插件，实现容器实例(如pod)同时属于多个网络(network)。图1为一些开源方案提供的容器网络配置方式。如图1所示，容器网络配置方式主要包括以下步骤：
25.步骤1：节点代理组件(如k8s系统中的kubelet)运行容器。
26.步骤2：容器运行时(container runtime)组件调用网络插件(network plugin)进行容器网络配置(setup pod)。
27.步骤3：cni插件对cni add操作进行授权(delegate add)。
28.步骤4：主cni插件(master plugin)执行cni add操作，为容器配置网络1。
29.步骤5：multus插件对cni add操作进行授权(delegate add)。
30.步骤6：从插件(minion plugin)执行cni add操作，为容器配置虚拟网络2。
31.图1所示的容器网络配置方案可实现容器同时属性多个网络。但是，该容器网络配置过程依然与容器的启动过程强耦合，即容器的网络属性是在容器启动过程中的容器配置(setup)阶段决定的，无法在容器运行时及时修改容器的网络属性。这种方式应用需要对多个网络之间做精细化的路由控制，需要应用开发人员在容器(如pod)内通过代码或脚本方式实现，增大了开发复杂性。此外，cni实现需要考虑cni add操作的幂等性，如果想让pod拥有多个network，需要调用不同的cni实现。不同的cni背后可能是完全不同的网络实现，如果用户需要访问的是同一种网络实现下的不同网络，则上述容器网络配置方式无法实现。
若要实现对同一种网络实现下的不同网络，需要修改具体的cni实现，这无疑增加了开发复杂性。
32.针对上述常规方案存在的技术问题，尤其针对容器网络配置与容器启动强耦合，导致容器网络配置方式灵活性低的技术问题，在本技术一些实施例中，利用网络服务集群中的网络服务可为容器打通不同网络的能力，在计算集群的工作节点中增设网络服务集群对应的容器网络接口(cni)组件，该cni组件可将工作节点中部署的容器实例接入到网络服务中，这样，容器实例可通过网络服务访问其它网络。cni组件可将工作节点中部署的容器实例接入到网络服务的过程，可发生在容器实例的生命周期的任意阶段，实现了容器网络配置与容器的生命周期的解耦，有助于提高容器网络配置的灵活性。
33.以下结合附图，详细说明本技术各实施例提供的技术方案。
34.应注意到：相同的标号在下面的附图以及实施例中表示同一物体，因此，一旦某一物体在一个附图或实施例中被定义，则在随后的附图和实施例中不需要对其进行进一步讨论。
35.图2为本技术实施例提供的计算系统的结构示意图。如图2所示，本技术实施例提供的计算系统主要包括：管控(master)节点10、计算集群20及网络服务集群30。如图2所示，计算集群20是指由多个工作节点(workers)201组成的计算集群。网络服务集群30也可由多个工作节点(workers)301组成。
36.在本实施例中，管控节点10是指可以进行工作节点管理，可响应用户端30的服务请求，通过调度工作节点201为用户提供计算服务的计算机设备，一般具备承担服务并保障服务的能力。管控节点10可以为单一服务器设备，也可以云化的服务器阵列，或者为云化的服务器阵列中运行的虚拟机(virtual machine，vm)、容器或容器组等。另外，服务端设备也可以指具备相应服务能力的其他计算设备，例如电脑等终端设备(运行服务程序)等。在本实施例中，管控节点10可部署于云端，例如边缘云系统的中心云中。
37.工作节点是指提供计算资源的计算机设备。工作节点可为物理机，也可为物理机中虚拟化出的虚拟机。在本实施例中，工作节点除了提供计算资源之外，还可提供其他硬件资源和软件资源。其中，硬件资源可包括：处理器等计算资源，内存、磁盘等存储资源。其中，处理器可以为cpu、gpu、fpga等等。软件资源可包括：带宽、网段、网卡配置等网络资源以及操作系统等。
38.在本实施例中，工作节点可部署于中心云中，也可实现为边缘云网络中的边缘云节点。一个边缘节点可为一个机房、一个数据中心(data center，dc)或者互联网数据中心(internet data center，idc)等。对于边缘云网络来说，一个工作节点可包括一个或多个边缘节点。多个是指2个或2个以上。每个边缘节点可包括一系列的边缘基础设施，这些边缘基础设施包括但不限于：分布式数据中心(dc)、无线机房或集群，运营商的通信网络、核心网设备、基站、边缘网关、家庭网关、计算设备或存储设备等边缘设备及对应的网络环境等等。在此说明，不同边缘节点的位置、能力以及包含的基础设施可以相同，也可以不相同。
39.在本实施例中，网络服务集群30的工作节点301主要用于部署网络服务(network service)，如图2中的网络服务1-3。在本技术各实施例中，网络服务集群30用于实现网关编排服务，可提供处理不同网络之间通信的基础设施层。网络服务集群30可以为接入网络服务集群30的容器提供访问其他网络的能力。网络服务是对于访问网络的网关抽象。网络服
务可以有多种网关实现，比如vpc网关实现，可以打通到另一个vpc内。在一些实施例中，网络服务集群30可实现为网络服务网格(network service mesh，nsm)集群。其中，网络服务网格(nsm)为一种提供网络服务的服务网格，可为处理不同网络之间通信的基础设施层。
40.在本技术实施例中，网络服务集群30和计算集群20对应的管控节点10可为同一master节点，也可为不同的master节点。图1仅以网络服务集群30和计算集群20对应的管控节点10为同一master节点进行图示，但不构成限定。
41.在本技术实施例中，管控节点10和工作节点201、301之间可以是无线或有线连接。可选地，管控节点10和工作节点201、301等可以通过移动网络通信连接，相应地，移动网络的网络制式可以为2g(gsm)、2.5g(gprs)、3g(wcdma、td-scdma、cdma2000、utms)、4g(lte)、4g+(lte+)、5g、wimax等中的任意一种。可选地，管控节点10和工作节点201、301也可以通过蓝牙、wifi、红外线等方式通信连接。计算集群20中不同的工作节点201之间还可通过内网通信连接等等。当然，网络服务集群30中不同的工作节点301之间还可通过内网通信连接等等。
42.在本技术实施例中，管控节点10可响应容器创建请求，在工作节点201中调度与容器创建请求适配的目标工作节点，并将待创建容器与该工作节点绑定。目标工作节点中的节点代理组件20a(如k8s中的kubelet组件)在监听到有容器绑定过来，可通过docker创建并启动容器(如pod等)，实现容器在目标工作节点中的部署。
43.为了实现容器网络配置与容器生命周期解耦，在本技术实施例中，利用网络服务能为容器打通不同网络的能力，在计算集群20中的工作节点201中设置网络服务集群对应的cni(简称nsm-cni)组件20b。nsm-cni组件20b可实现为cni插件。该cni插件为网络服务集群对应的cni插件，可简称为nsm-cni组件。nsm-cni组件20b为可执行程序。在本技术实施例中，cni接口是指对可执行程序的调用。可执行程序称之为cni插件。在本技术实施例中，nsm-cni组件20b可以deployment形式部署于工作节点201中。如图4所示，n nsm-cni组件20b可以cni链(cni chain)的方式部署于工作节点201。cni chain方式允许将nsm-cni组件20b与其他cni插件结合使用。其中，nsm-cni组件20b的cni配置示例如下：
44.数据结构1：nsm-cni组件20b的cni配置
45.[0046][0047]
在本技术实施例中，在需要设置容器网络时，nsm-cni组件20b可将工作节点201中部署的容器实例(如pod等)接入到网络服务集群30中的网络服务中。在本技术实施例中，容器实例可实现为容器组形式，如pod。其中，一个容器组可包括一个或多个容器。多个是指2个或2个以上。由于网络服务为访问网络的网关抽象，因此，容器实例可通过网络服务访问其它网络。其中，其它网络是指相对于计算集群20来说的，是指计算集群20的内部网络之外的网络，主要用于实现计算集群20中的容器实例对其它网络中的节点的访问。
[0048]
具体地，结合图3、图4和图5，nsm-cni组件20b可在工作节点201部署容器实例的过程中，为容器实例分配虚拟网卡(如图3-图5中的nsm0)。该虚拟网卡是与网络服务集群30通信的虚拟网络。对于网络服务集群为nsm集群的实施例中，虚拟网卡可称为nsm虚拟网卡。图3-图5中nsm0表示虚拟网卡的名称。
[0049]
可选地，结合图3和图4，在工作节点201部署容器实例过程中，节点代理组件(如kubelet)20a可调用容器运行时组件(container runtime)20d，容器运行时组件20d可调用nsm-cni组件20b为容器实例(如pod)分配nsm虚拟网卡nsm0。具体地，在容器配置(setup pod)阶段，容器运行时组件20d可调用nsm-cni组件20b执行cni add接口，为容器实例分配nsm虚拟网卡nsm0。
[0050]
当然，在一些实施例中，为了实现容器实例在计算集群中的通信，容器运行时组件20d还可调用其它cni插件(如图3和图4所示的cni插件20f)为容器实例分配计算集群内通信的网卡。具体地，在容器配置(setup pod)阶段，容器运行时组件20d可调用其它cni插件执行cni add接口，为容器实例分配计算集群内通信的网卡(如集群网卡等)。
[0051]
在一些实施例中，为了避免有些不需要nsm的容器实例也被分配了nsm虚拟网卡，nsm-cni组件20b只为容器资源(如pod资源)的注释(annotations)中注明了需要使用nsm的容器实例分配nsm虚拟网卡。例如，容器资源的注释字段的nsm.cloud.com/ansm-cni字段表
示容器是否使用nsm。若nsm.cloud.com/ansm-cni字段的值设置为true，则表示容器实例使用nsm。相应地，若nsm.cloud.com/ansm-cni字段的值设置为false，则表示容器实例不使用nsm。
[0052]
在本技术实施例中，如图4所示，容器网络可由网络命名空间(network namespaces，netns)tap接口和流量控制(traffic control，tc)策略打通，创建沙箱(sandbox)环境之前，首先创建网络命名空间，网络命名空间有veth-pair和tap两种网络接口。eth0和nsm0属于veth-pair类型接口，一端接入cni创建的网络命名空间，一端接入宿主机。tap0_kata和tap1_kata属于tap类型接口，一端接入cni创建的网络命名空间，一端接入qemu创建的hypervisor，并且在cni插件20f创建的网络命名空间使用tc策略打通eth0网络接口和tap0_kata网络接口，相当于把eth0和tap0_kata两个网络接口连通。当然，在以及，nsm-cni组件20b创建的网络命名空间使用tc策略打通nsm0网络接口和tap1_kata网络接口，相当于把nsm0和tap1_kata两个网络接口连通。
[0053]
sandbox环境中只有eth0和nsm0网络接口，这两个接口是qemu和tap模拟出的接口，mac地址、ip地址和掩码分别于宿主机中cni插件(上述cni插件20f和nsm-cni组件20b)创建的网络命名空间中eth0和nsm0的配置相同。
[0054]
nsm-cni组件20b在为容器实例分配完nsm虚拟网卡(即nsm0网络接口)之后，还可将容器实例的名称、容器实例的命名空间、容器实例的网络命名空间及容器实例的沙箱环境持久化至工作节点201对应的存储介质中，以便后续对容器实例进行网络流表更新。
[0055]
在本技术实施例中，对于网络服务集群来说，工作节点201中设置有网络服务集群对应数据面组件20c。对于nsm来说，该数据面组件20c也可称为nsm数据面组件。其中，数据面组件20c为逻辑功能组件，该组件可采用编程语言(如go语言等)实现网关的全量能力。其中，数据面组件用于负责打通网络服务集群30与计算集群20之间的overlay链路，可实现overlay链路的负载均衡，保证链路高可用，并且有overlay链路端到端的探测能力。
[0056]
基于上述数据面组件20c，nsm-cni组件20b可将nsm虚拟网卡(如图3中的nsm0)接管至数据面组件20c。进一步，数据面组件20c可建立nsm虚拟网卡(nsm0)与网络服务之间的连接。具体地，数据面组件20c与网络服务集群30的工作节点301上的数据面组件30a之间可建立网络通信。数据面组件30a的功能与数据面组件20c相同。对于数据面组件30a来说，后端服务为网络服务，可将工作节点201中的容器实例的访问请求转发给网络服务，经网络服务访问其它网络。该网络配置过程将容器的网络配置能力从容器的生命周期中移出，使得容器的网络命名空间(net namespace)对容器网络变化无感知。
[0057]
本技术实施例提供的计算系统，利用网络服务集群中的网络服务可为容器打通不同网络的能力，在计算集群的工作节点中增设网络服务集群对应的容器网络接口组件(cni组件)，该cni组件可将工作节点中部署的容器实例接入到网络服务中，这样，容器实例可通过网络服务访问其它网络。cni组件可将工作节点中部署的容器实例接入到网络服务的过程，可发生在容器实例的生命周期的任意阶段，实现了容器网络配置与容器的生命周期的解耦，有助于提高容器网络配置的灵活性。例如，容器实例处于运行时(runtime)状态，也可动态改变容器的网络属性等。
[0058]
在本技术实施例中，容器实例运行时，若要访问某些或某个网络，只需将容器和网络规则的绑定条件更新到计算系统的自定义资源(crd)。对于k8s系统来说，crd是k8s为提
高可扩展性，让开发者去自定义资源的一种方式。crd资源可以动态注册到k8s集群中，注册完毕后，可以调用kube-apiserver的client api来访问这个自定义的资源对象。crd是资源的定义，需要一个控制器去监听crd的各种事件来添加自定义的处理逻辑。在本技术实施例中，为了能够监听容器实例的网络需求资源，在管控节点10中增设网络服务集群对应的管控组件10a。其中，管控组件10a为逻辑功能组件，主要实现的是对容器实例的网络需求资源进行监听，并在监听到针对网络需求资源的crd的更新或创建事件时，添加自定义的网络需求处理逻辑。下面对管控组件10a的工作逻辑进行示例性说明。
[0059]
结合图2和图4，对于计算系统的管理端40来说，计算系统的管理员在需要容器实例的网络进行配置时，可将网络服务规则(network service role)资源以crd形式注册到api服务(api server)组件10b。api服务组件10b是k8s系统中用于资源对象的增、删、查、改、盯(监听)的服务端。数据存储在etcd数据库中，api服务组件10b可通过etcd中存储的数据的认证鉴权、缓存、api版本适配转换等一系列的功能。管控节点10中的其它模块可通过api服务组件10b查询或修改etcd中的数据。其中，etcd数据库是一个分布式的、高可用的、一致的key-value(键值对)存储数据库，主要用于共享配置和服务发现。
[0060]
对于上述网络服务规则资源，可包括：容器选择(pod selector)字段及路由字段等。其中，容器选择字段用于确定适用于该网络服务规则资源的容器；路由字段用于决定适用于该网络服务规则资源的容器的网络信息。结合图5，网络服务规则资源的crd示例如下：
[0061]
数据结构2：网络服务规则资源的crd示例：
[0062]
[0063][0064]
在上述网络服务规则资源的crd示例中，apiversion表示crd定义的资源对象的版本信息；kind表示crd定义的资源对象类型为网络服务规则资源。generation表示网络服务规则资源的crd的当前的版本，每次网络服务规则资源的crd每次更新后，该字段都会更新。spec字段表示crd定义的资源对象的资源清单。其中，spec字段中的容器选择字段(podselector)：表示networkservicerole适配的pod范围。路由字段routes：routes字段的每一条都会决定pod内的网络走向。target字段表示网络服务规则资源决定的访问目的地。target字段可以ip/掩码(ip/mask)进行表示，例如，可写主机明晰路由(mask＝＝32)，也可以写一个网络地址(mask《32)。或者，target字段也可以内置网络地址进行表示。内置网络地址可以由k8s管理员自行配置，以满足自己应用场景。via字段决定如何去往访问目的地。其中，via字段中的类型(type)字段的值是可选的。类型(type)字段的值可为：networkservice，即通过networkservice(网络服务)访问目的地；或者，host，即通过主机网络访问目的地。via字段中的value字段，当type为network sevice时，value为网络服务的名称；对于其他type，value字段可不填写。
[0065]
上述网络服务规则资源的crd示例中，status字段统计routes规则在pods中的应用状态；其中，observedgeneration表示当前status描述的资源版本号。totalcount表示podselector匹配到的pod的总数量。readycount表示已经成功刷入网络服务规则的pod的数量。annotations字段中nsm.aclound.com/ready为该annotation为kubernetes管理员和nsm管控组件10a的交互协议。每次修改网络服务规则资源中的路由字段route时，需要将nsm.aclound.com/ready的值改为false。nsm管控组件10a对网络服务规则资源处理完后，再置nsm.aclound.com/ready的值为true。其中，nsm.aclound.com/ready的值为false表示网络服务规则资源刷新至podselector选择出的pod未完成；true表示网络服务规则资源刷新至podselector选择出的pod全部完成。如图5所示，上述网络服务规则资源中的资源清单(spec)中各字段的值可由用户指定，具体是由管理端40侧的用户指定。
[0066]
基于上述网络服务规则资源，管控组件10a可监测网络服务规则资源。具体地，管
控组件10a可调用api服务(api server)组件10b监测网络服务规则资源；并在监测到有新的网络服务规则资源的情况下，根据新的网络服务规则资源，生成反映容器实例的网络需求的流表，即网络服务流表(network service flows)。在本技术实施例中，有新的网络服务规则资源包括：api服务组件10b中增加了原来不存在的网络服务规则资源，也可包括：api服务组件10b中的网络服务规则资源发生更新。
[0067]
具体地，管控组件10a可根据网络服务规则资源中的容器选择规则，确定网络服务规则资源适配的目标容器实例。即根据网络服务规则资源中的podselector字段的值，确定网络服务规则资源适配的目标容器实例。其中，目标容器实例的数量可为1个或多个。多个是指2个或2个以上。多个容器实例可部署于同一工作节点，也可部署于不同的工作节点。网络服务规则资源中的容器选择规则可以容器组(如pod)的标签(label)表示。容器组的标签用于筛选出具有该标签的容器组。
[0068]
进一步，管控组件10a可从网络服务规则资源的资源请求中，获取目标容器实例的网络资源，即routes字段的值。nsm管控组件10a可确定目标容器实例的网络资源为目标容器实例的流表中的网络资源，进而得到目标容器实例的流表(flow)。
[0069]
在本技术实施例中，容器实例的流表可作为crd方式注册到api服务组件10b。目标容器实例的流表中的网络资源可反映该目标容器实例的网络需求。结合图5，对流表的crd实现进行示例性说明：
[0070]
数据结构3：流表的crd示例：
[0071]
[0072][0073]
在上述流表的crd中，status字段用于描述流表中的routes在pods中应用的状态。phase字段表示网络服务规则资源在pod中的应用阶段。其中，bound表示已刷入，即已将流表刷入pod。unbound表示未刷入，即已将流表刷入pod。error表示刷入失败，即流表输入pod失败。message：状态和phase描述一致。
[0074]
基于上述网络服务规则资源和流表的crd示例，管控组件10a在生成目标容器实例的流表时，可根据网络服务规则资源的podselector字段描述的容器选择规则，确定网络服务规则资源适配的目标容器实例(如目标pod)；可确定网络服务规则资源中的routes字段描述的网络资源，为目标容器实例的流表中的routes字段的值，即为目标容器xxxxyyyyzzzz的流表的网络资源。进一步，管控组件10a还可确定目标容器组所在的工作节点；并将目标容器实例所在的工作节点的标识写入目标容器组的流表的标签字段。如上述流表的crd示例中“cloud.com/nodename:xxxxyyyyzzzz”，nodename表示节点名称。
[0075]
由于容器实例部署的工作节点是由管控节点10进行调度的，因此，管控节点10可确定容器实例与工作节点之间的对应关系；并将该对应关系持久化至etcd数据库中。基于etcd数据库，管控组件10a可利用目标容器实例的标识，查询etcd存储的容器实例与工作节点之间的对应关系得到目标容器实例所在的工作节点。进一步，可将标容器实例所在的工
作节点的标识写入该目标容器实例的流表的标签字段。
[0076]
当然，管控组件10a还可确定流表中其它字段的值。例如，管控组件10a可根据网络服务规则资源的名称，确定生成该流表所依赖的网络服务规则资源，并写入相应字段。如上述流表示例中“nsm.cloud.com/role:role-for-user1”，依赖的网络服务规则资源为“role-for-user1”等等。
[0077]
在得到目标容器实例的流表之后，管控组件10a还可将目标容器实例的流表以crd形式注册到api服务组件10b。对于nsm-cni组件20b可监测api服务组件10b注册的流表，即图2中的监测api服务组件10b的crd。具体地，nsm-cni组件20b可获取api服务组件10b注册的流表包含的工作节点的标识；并根据api服务组件10b注册的流表包含的工作节点的标识，识别nsm-cni组件20b所在的目标工作节点中部署的容器实例的流表。之后，nsm-cni组件20b可将目标工作节点中部署的容器实例的流表刷新至该目标工作节点部署的容器实例中。可选地，nsm-cni组件20b可通过远程过程调用(rpc)方式将目标工作节点中部署的容器实例的流表刷新至该目标工作节点部署的容器实例中。
[0078]
在一些实施例中，nsm-cni组件20b会监测属于其所在目标工作节点的流表；并按照容器实例的颗粒度，对每个容器实例的流表进行聚合，得到该容器实例的流表。其中，对同一容器实例的流表进行聚合可防止该容器实例后生成的流表对在先生成的流表进行覆盖。在对同一容器实例的流表进行聚合后，可将该容器实例聚合后的流表刷新至nsm节点插件20e；并由nsm节点插件20e刷新到数据面组件20c，进而实现将容器实例的流表刷新至容器实例中。
[0079]
在将nsm-cni组件20b所在的工作节点中部署的容器实例的流表刷新至该工作节点部署的容器实例之后，nsm-cni组件20b还可将对应容器实例的流表的刷新状态字段(如上述phase字段)设置为已刷入状态(bound)。
[0080]
在本技术实施例中，对于管控组件10a还可获取目标容器实例的流表包含的刷新状态字段的状态值；并根据目标容器实例的流表包含的刷新状态字段的状态值，判断目标容器实例的流表是否已被目标容器实例刷新完成。可选地，管控组件10a可根据目标容器实例的流表包含的刷新状态字段的状态值，确定状态值为已刷入状态的流表数量，即已成功刷入流表的目标容器实例的数量。管控组件10a还可将已成功刷入流表的目标容器实例的数量写入上述网络服务规则资源的readycount字段。进一步，若已成功刷入流表的目标容器实例的数量与上述网络服务规则资源podselector匹配到的pod的总数量相等，即网络服务规则资源中totalcount的值等于readycount的值，则确定目标容器实例的流表被目标容器实例刷新完成。进一步，在目标容器实例的流表被目标容器实例刷新完成的情况下，管控组件10a可将网络服务规则资源中表征路由规则完成状态的字段(如annotations：nsm.clound.com/ready)设置为表征完成的标识。例如，将annotations：nsm.clound.com/ready字段设置为ture等。这样，对于k8s系统的管理员可获取路由规则完成状态。
[0081]
在本技术实施例中，流表刷新至容器实例之后，容器实例可基于流表描述的网络资源，确定容器实例访问目的地的路由信息；并在路由信息为网络服务的情况下，通过流表中描述的目标网络服务访问目的地。例如，对于上述流表crd示例，可确定容器实例访问目的地为192.168.1.1/32；路由信息为通过网络服务访问目的地；目标网络服务的名称为：ansm-vpc-xxxxxxxxxx。即容器实例可通过ansm-vpc-xxxxxxxxxx的目标网络服务访问
192.168.1.1/32对应的目的地。
[0082]
在本技术实施例中，流表描述的网络资源可为1种或多种。多种是指2种或2种以上。其中，多种网络资源的目的地可能相同，也可能不同。在本实施例中，在确定待访问的目的地时，可遵循目的ip最长匹配原则，即选择目的ip的颗粒度最精细的目的ip作为待访问的目的地。相应地，nsm-cni组件20b可在流表包含的网络资源存在多种网络资源的情况下，从流表中获取所述多种网络资源的目的ip；根据多种网络资源的目的ip的路由长度，确定路由长度最长的目的ip为容器实例待访问的目的地；并确定访问该目的地的目标网络资源为容器实例访问目的地的路由信息。例如，上述流表crd示例中，目的地分别为：192.168.1.1/32、anytunnel及0.0.0.0/0。其中，anytunnel对应某个固定网段，0.0.0.0/0表示任意ip地址。因此，目的ip的路由长度为192.168.1.1/32》anytunnel》0.0.0.0/0，因此，可确定192.168.1.1/32为容器实例待访问的目的地；并确定192.168.1.1/32对应的目标网络资源，即名称为ansm-vpc-xxxxxxxxxx的网络服务为容器实例的路由信息。进一步，对于容器实例的访问请求，可通过名称为ansm-vpc-xxxxxxxxxx的网络服务发送至192.168.1.1/32对应的目的地。
[0083]
在本技术实施例中，如图6所示，还可在管控节点10中设置网络服务集群30对应的准入控制器(nsm-webhook)10c。准入控制器10c是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达api服务组件的请求。在本技术实施例中，针对上述网络服务规则资源，准入控制器可检测网络服务规则资源中的多种网络资源的目的地是否完全相同。具体地，准入控制器10c可检测网络服务规则资源中的多种网络资源的无类别域间路由(cidr)是否完全重叠；若网络服务规则资源中的多种网络资源的无类别域间路由(cidr)完全重叠，确定网络服务规则资源中的多种网络资源的目的地完全相同。在多种网络资源的目的地完全相同的情况下，后续生成的流表中的多种网络资源的目的地也是完全相同的，对于nsm-cni组件20b无法确定通过哪种网络资源去往目的地。因此，在多种网络资源的目的地完全相同的情况下，准入控制器10c可阻止在api服务组件10b中注册网络服务规则资源，可防止后续容器实例访问出错。
[0084]
在本技术实施例中，为了防止容器实例在网络完成初始化之前接收访问流量，准入控制器10c针对可通过网络服务访问目的地的容器实例，可在该容器实例对应的容器资源中配置容器实例的就绪状态(ready状态)条件为流表刷新完成。例如，准入控制器10c针对使用nsm的容器实例，可在容器资源(如pod资源)的资源清单(spec)中设置readinessgates来指定kubelet评估容器实例的就绪状态的附加条件列表。其中，readiness gates取决于pod的status.condition字段的当前状态。如果在容器的status.conditions字段中找不到这样的条件，则该条件的状态默认为“false”。只有到pod中的所有容器状态都是ready，且pod附加的额外状态检测的readinessgates条件也是ready的时候，pod的状态才是ready。kubelet判定一个pod是否ready的两个前提条件：(1)pod中容器全部ready(containersready condition为true)；(2)pod.spec.readinessgates中定义了一个或多个conditiontype，则需要这些conditiontype在pod.status.conditions中都有对应的status为“true”的状态。基于此，准入控制器10c可设置readinessgates中conditiontype为流表刷新完成(networkserviceflowexpected)，即设置容器的就绪状态附加条件为流表刷新完成。
[0085]
基于上述容器的就绪状态附加条件，管控组件10a可在流表已刷新至容器实例的情况下，将就绪状态附加条件对应的流表刷新状态设置为流表刷新完成，以供容器实例接收访问流量。例如，可将就绪状态附加条件对应的流表刷新状态networkserviceflowexpected设置为ture，这样在pod中所有容器达到就绪状态(ready)时，pod达到就绪状态(ready)，可接收访问流量。
[0086]
在本技术实施例中，对于新扩容的pod，在pod暂时还没有匹配的网络服务规则资源(networkservicerole)的情况下，nsm管控组件10a可将就绪状态附加条件对应的流表刷新状态设置为true，即流表刷新完成。若新扩容的pod存在匹配的网络服务规则资源(networkservicerole)，可基于网络服务规则资源，生成该pod对应的流表；并在流表的status.phase变为bound(已刷入状态)时，将就绪状态附加条件对应的流表刷新状态设置为true。
[0087]
在另一些实施例中，kubernetes管理员更新了网络服务规则资源(networkservicerole)。管控组件10a可根据更新后的网络服务规则资源，更新网络服务规则资源适配的pod的流表。在流表刷新至pod之前，管控组件10a可设置就绪状态附加条件对应的流表刷新状态设置为false。这样，pod不会接受来自service的新请求。进一步，在流表刷新至pod，流表的status.phase变为bound(已刷入状态)时，将等就绪状态附加条件对应的流表刷新状态设置为true。
[0088]
上述实施例主要示例性说明了管控组件10a处理k8s管理员提供的路由规则(即网络服务规则资源)以及将路由规则与pod绑定的过程。对于管控组件10a可包括2个控制器：(1)网络服务资源规则控制器；(2)网络服务控制器。其中，网络服务资源规则控制器主要用于处理k8s管理员提供的路由规则(即网络服务规则资源)以及将路由规则与pod绑定，即上述实施例示出的过程。网络服务控制器主要用于监测网络服务资源，并与网络服务集群进行交互，在网络服务集群中创建网络服务。下面对管控组件10a创建网络服务的过程进行示例性说明。
[0089]
如图4所示，管控组件10a可调用api服务组件10b监测网络服务；并在监测到存在网络服务资源更新的情况下，调用api服务组件10b获取更新的网络服务资源；并根据更新的网络服务资源，在网络服务集群中创建网络服务。具体地，管控组件10a可与网络服务集群30对应的管控节点中的协调组件30a进行交互，通过调用协调组件30a在网络服务集群中创建网络服务。可选地，管控组件10a可通过rpc方式调用协调组件30a根据更新的网络服务资源在网络服务集群中创建网络服务。其中，网络服务资源可为k8s集群的crd资源，可以crd形式注册到api服务组件10b。下面结合图5对网络服务资源的crd示例进行说明。
[0090]
数据结构4：网络服务资源的crd
[0091][0092]
上述网络服务资源的crd中，spec表示网络服务的资源清单。其中，spec的资源清单可由资源端40侧的用户决定。replicas字段表示网络服务的副本数量。处于高可用考虑，网络服务资源的crd创建时副本数量≥2。userid表示使用网络服务的用户的标识。userrolename表示网络服务的用户的网络服务规则资源角色的名称。usersecuritygroupid：表示网络服务用户的安全组id。uservpcid表示网络服务的id。在上述网络服务资源示例中，网络服务为vpc网络形式。网络服务集群创建出来的eni在该vpc下。uservswitches表示网络服务下的虚拟交换机标识(vswitch id)列表。nsm创建eni时，会从列表中挑选一个有ip余量的vswitch去创建eni。填写多个vswitch可以提升创建成功率。状态字段表示网络服务的状态信息。其中，networkserviceid表示网络服务的标识networkservice id全局唯一的id，每次重新创建都不同。phase表示网络服务的状态。当phase为available时，表示网络服务可用。
[0093]
除了上述网络服务资源示例示出的网络服务资源的字段之外，在一些实施例中，网络服务资源的crd还可包括：spechash字段。其中，spechash字段表示管控组件10a协调(reconcile)时，网络服务资源crd中资源清单(spec)所有字段的哈希hash结果。管控组件10a在收到网络服务增加(add)或更新(update)事件时，可以通过spechash字段的值和网络服务集群30中的网络服务的资源清单的hash结果进行对比。若网络服务资源的spechash字
段的值和网络服务集群30中的网络服务的资源清单的hash结果相同，则管控组件10a协调(reconcile)再进行协调，可减少对资源的消耗。
[0094]
基于上述网络服务的crd，管控组件10a可通过rpc方式调用协调组件30a根据更新的网络服务资源在网络服务集群中创建网络服务。具体地，管控组件10a可在工作节点201中调度与更新的网络服务资源适配的目标工作节点，并将更新的网络服务与该工作节点绑定。目标工作节点中的节点代理组件(如k8s中的kubelet组件)在监听到有网络服务绑定过来，可通过容器运行时组件创建并启动容器(如pod等)，实现网络服务在目标工作节点中的部署。
[0095]
除了上述实施例提供的计算系统之外，本技术实施例还提供容器网络配置方法，下面从计算系统的角度对本技术实施例提供的容器网络配置方法进行示例性说明。
[0096]
图7为本技术实施例提供的容器网络配置方法的流程示意图。如图7所示，该容器网络配置方法主要包括：
[0097]
701、确定目标工作节点部署的容器实例。
[0098]
702、利用目标工作节点中的nsm-cni组件将容器实例接入到网络服务集群的网络服务，以供容器实例通过网络服务访问其它网络。
[0099]
为了实现容器网络配置与容器生命周期解耦，在本技术实施例中，利用网络服务集群能为容器打通不同网络的能力，在计算集群中的工作节点中设置网络服务集群对应的cni(简称nsm-cni)组件。关于nsm-cni组件的描述可参见上述系统实施例的相关内容，在此不再赘述。
[0100]
在本技术实施例中，针对计算集群中任一工作节点，定义为目标工作节点，在步骤701中，可确定目标工作节点部署的容器实例；并在需要设置容器网络时，在步骤702中，可利用目标工作节点中的nsm-cni组件将目标工作节点中部署的容器实例(如pod等)接入到网络服务集群中的网络服务中。由于网络服务为访问网络的网关抽象，因此，容器实例可通过网络服务访问其它网络。其中，其它网络是指相对于计算集群来说的，是指计算集群的内部网络之外的网络，主要用于实现计算集群中的容器实例对其它网络中的节点的访问。
[0101]
具体地，结合图3、图4和图5，可在目标工作节点部署容器实例的过程中，可利用nsm-cni组件为目标工作节中的容器实例分配虚拟网卡。其中，该虚拟网卡是指容器实例与网络服务进行通信的虚拟网卡，可称为nsm虚拟网卡。关于为目标工作节中的容器实例分配虚拟网卡的具体实施方式可参见上述系统实施例的相关内容，在此不再赘述。
[0102]
在一些实施例中，为了避免有些不需要网络服务集群提供的网络服务的容器实例也被分配了与网络服务集群通信的虚拟网卡，可只为容器资源(如pod资源)的注释(annotations)中注明了需要使用网络服务集群提供的网络服务的容器实例分配与网络服务集群通信的，即nsm虚拟网卡。
[0103]
在本技术实施例中，对于网络服务集群来说，工作节点中设置有网络服务集群对应的数据面组件。可利用nsm-cni组件将nsm虚拟网卡接管至该数据面组件，并利用数据面组件建立nsm虚拟网卡(nsm0)与网络服务之间的连接。具体地，数据面组件与网络服务集群的工作节点上的数据面组件之间可建立网络通信。对于网络服务集群中的数据面组件来说，后端服务为网络服务，可将计算集群中的工作节点中的容器实例的访问请求转发给网络服务，经网络服务访问其它网络。该网络配置过程将容器的网络配置能力从容器的生命
周期中移出，使得容器的网络命名空间(net namespace)对容器网络变化无感知。
[0104]
本技术实施例提供的计算系统，利用网络服务集群中的网络服务可为容器打通不同网络的能力，在计算集群的工作节点中增设网络服务集群对应的容器网络接口组件(nsm-cni组件)，该nsm-cni组件可将工作节点中部署的容器实例接入到网络服务中，这样，容器实例可通过网络服务访问其它网络。nsm-cni组件可将工作节点中部署的容器实例接入到网络服务的过程，可发生在容器实例的生命周期的任意阶段，实现了容器网络配置与容器的生命周期的解耦，有助于提高容器网络配置的灵活性。例如，容器实例处于运行时(runtime)状态，也可动态改变容器的网络属性等。
[0105]
在本技术实施例中，容器实例运行时，若要访问某些或某个网络，只需将容器和网络规则的绑定条件更新到计算系统的自定义资源(crd)。在本技术实施例中，为了能够监听容器实例的网络需求资源，可在管控节点中增设网络服务集群对应的管控组件。其中，管控组件为逻辑功能组件，主要实现的是对容器实例的网络需求资源进行监听，并在监听到针对网络需求资源的crd的更新或创建事件时，添加自定义的网络需求处理逻辑。对于计算系统的管理端来说，计算系统的管理员在需要容器实例的网络进行配置时，可将网络服务规则(network service role)资源以crd形式注册到api服务(api server)组件。对于上述网络服务规则资源，可包括：容器选择(pod selector)规则字段及路由字段等。其中，容器选择规则字段用于确定适用于该网络服务规则资源的容器；路由字段用于决定适用于该网络服务规则资源的容器的网络信息。关于网络服务规则资源的crd示例可参见上述系统实施例的相关内容，可参见上述系统实施例。
[0106]
基于上述网络服务规则资源，可利用管控组件监测网络服务规则资源；并在监测到有新的网络服务规则资源的情况下，根据新的网络服务规则资源，生成反映容器实例的网络需求的流表，即网络服务流表(network service flows)。在本技术实施例中，有新的网络服务规则资源包括：api服务组件中增加了原来不存在的网络服务规则资源，也可包括：api服务组件中的网络服务规则资源发生更新。
[0107]
具体地，可根据网络服务规则资源中的容器选择规则，确定网络服务规则资源适配的目标容器实例。即根据网络服务规则资源中的podselector字段的值，确定网络服务规则资源适配的目标容器实例。其中，目标容器实例的数量可为1个或多个。多个是指2个或2个以上。多个容器实例可部署于同一工作节点，也可部署于不同的工作节点。
[0108]
进一步，可利用管控组件从网络服务规则资源的资源请求中，获取目标容器实例的网络资源，即routes字段的值。管控组件可确定目标容器实例的网络资源为目标容器实例的流表中的网络资源，进而得到目标容器实例的流表(flow)。
[0109]
在本技术实施例中，容器实例的流表可作为crd方式注册到api服务组件。目标容器实例的流表中的网络资源可反映该目标容器实例的网络需求。关于流表的crd实现可参见上述数据结构3，在此不再赘述。
[0110]
基于上述网络服务规则资源和流表的crd示例，在生成目标容器实例的流表时，可根据网络服务规则资源的podselector字段描述的容器选择规则，确定网络服务规则资源适配的目标容器实例；可确定网络服务规则资源中的routes字段描述的网络资源，为目标容器实例的流表中的routes字段的值，即为目标容器实例的流表的网络资源。进一步，还可确定目标容器实例所在的工作节点；并将目标容器实例所在的工作节点的标识写入目标容
器实例的流表的标签字段。
[0111]
当然，还可利用管控组件确定流表中其它字段的值。例如，可根据网络服务规则资源的名称，确定生成该流表所依赖的网络服务规则资源，并写入相应字段。在得到目标容器实例的流表之后，还可利用管控组件将目标容器实例的流表以crd形式注册到api服务组件。相应地，可利用nsm-cni组件可监测api服务组件注册的流表，并在监测到目标工作节点的容器实例对应的流表发生更新的情况下，将更新的流表刷新至目标工作节点的容器实例。
[0112]
具体地，可利用nsm-cni组件获取api服务组件注册的流表包含的工作节点的标识；并根据api服务组件注册的流表包含的工作节点的标识，识别目标工作节点中部署的容器实例的流表。进一步，在目标工作节点部署的容器实例的流表发生更新的情况下，可利用nsm-cni组件将目标工作节点中部署的容器实例对应的更新的流表刷新至该目标工作节点部署的容器实例中。可选地，可通过远程过程调用(rpc)方式将目标工作节点中部署的容器实例对应的更新的流表刷新至该目标工作节点部署的容器实例中。
[0113]
在一些实施例中，nsm-cni组件会监测属于其所在目标工作节点的流表；并按照容器实例的颗粒度，对每个容器实例的流表进行聚合，得到该容器实例的流表。其中，对同一容器实例的流表进行聚合可防止该容器实例后生成的流表对在先生成的流表进行覆盖。在对同一容器实例的流表进行聚合后，可将该容器实例聚合后的流表刷新至容器实例中。
[0114]
在将nsm-cni组件所在的工作节点中部署的容器实例的流表刷新至该工作节点部署的容器实例之后，还可利用nsm-cni组件将对应容器实例的流表的刷新状态字段(如上述phase字段)设置为已刷入状态(bound)。
[0115]
在本技术实施例中，还可利用nsm管控组件基于更新的流表的刷新状态字段的状态值，确定更新的流表是否被目标容器实例刷新完成。其中，目标容器实例是指由生成更新的流表的网络服务规则资源的容器选择规则确定出的容器实例。可选地，可利用nsm管控组件获取更新的流表对应的目标容器实例的流表包含的刷新状态字段的状态值。进一步，根据目标容器实例的流表包含的刷新状态字段的状态值，判断目标容器实例的流表是否已被目标容器实例刷新完成。可选地，可根据目标容器实例的流表包含的刷新状态字段的状态值，确定状态值为已刷入状态的流表数量，即已成功刷入流表的目标容器实例的数量。进一步，若已成功刷入流表的目标容器实例的数量与上述网络服务规则资源podselector匹配到的pod的总数量相等，即网络服务规则资源中totalcount的值等于readycount的值，则确定目标容器实例的流表被目标容器实例刷新完成。进一步，在目标容器实例的流表被目标容器实例刷新完成的情况下，可将网络服务规则资源中表征路由规则完成状态的字段设置为表征完成的标识。这样，对于k8s系统的管理员可获取路由规则完成状态。
[0116]
在本技术实施例中，流表刷新至容器实例之后，容器实例可基于流表描述的网络资源，确定容器实例访问目的地的路由信息；并在路由信息为网络服务的情况下，通过流表中描述的目标网络服务访问目的地。在本技术实施例中，流表描述的网络资源可为1种或多种。多种是指2种或2种以上。其中，多种网络资源的目的地可能相同，也可能不同。在本实施例中，在确定待访问的目的地时，可遵循目的ip最长匹配原则，即选择目的ip的颗粒度最精细的目的ip作为待访问的目的地。相应地，在流表包含的网络资源存在多种网络资源的情况下，可利用nsm-cni组件从流表中获取多种网络资源的目的ip；根据多种网络资源的目的
ip的路由长度，确定路由长度最长的目的ip为容器实例待访问的目的地；并确定访问该目的地的目标网络资源为容器实例访问目的地的路由信息。在本技术实施例中，还可在管控节点中设置网络服务集群对应的准入控制器(nsm-webhook)，即nsm准入控制器。针对上述网络服务规则资源，可利用nsm准入控制器检测网络服务规则资源中的多种网络资源的目的地是否完全相同。在多种网络资源的目的地完全相同的情况下，可利用nsm准入控制器阻止在api服务组件中注册网络服务规则资源，可防止后续容器实例访问出错。
[0117]
在本技术实施例中，为了防止容器实例在网络完成初始化之前接收访问流量，可利用nsm准入控制器针对使用nsm的容器实例，可在该容器实例对应的容器资源中配置容器实例的就绪状态(ready状态)附加条件为流表刷新完成。基于上述容器的就绪状态附加条件，可利用nsm管控组件在流表已刷新至容器实例的情况下，将就绪状态附加条件对应的流表刷新状态设置为流表刷新完成，以供容器实例接收访问流量。在另一些实施例中，kubernetes管理端更新了网络服务规则资源(networkservicerole)。可利用管控组件根据更新后的网络服务规则资源，更新网络服务规则资源适配的pod的流表。在流表刷新至pod之前，可利用管控组件设置就绪状态附加条件对应的流表刷新状态设置为false。这样，pod不会接受来自service的新请求。进一步，在流表刷新至pod，流表的status.phase变为bound(已刷入状态)时，可利用管控组件将等就绪状态附加条件对应的流表刷新状态设置为true。
[0118]
在本技术实施例中，还可利用管控组件在网络服务集群中创建网络服务。具体地，可利用管控组件监测网络服务；并在监测到存在网络服务资源更新的情况下，利用管控组件调用api服务组件获取更新的网络服务资源；并根据更新的网络服务资源，在网络服务集群中创建网络服务。
[0119]
需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤701和702的执行主体可以为设备a；又比如，步骤701的执行主体可以为设备a，步骤702的执行主体可以为设备b；等等。
[0120]
另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如701、702等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。
[0121]
相应地，本技术实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述容器网络配置方法中的步骤。
[0122]
需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
[0123]
本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0124]
本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0125]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0126]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0127]
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
[0128]
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
[0129]
计算机的存储介质为可读存储介质，也可称为可读介质。可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0130]
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0131]
以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。