CN114143258A - 一种在Kubernetes环境下基于Open vSwitch的服务代理方法 - Google Patents

Abstract

本申请涉及一种在Kubernetes环境下基于Open vSwitch的服务代理方法，属于通信技术领域，其包括在Open vSwitch接收到目标报文时，通过Open vSwitch将目标报文的报文信息基于OpenFlow协议发送至Ryu控制器；通过Ryu控制器将报文信息上报至网络控制器；通过网络控制器确定目标报文对应的网络策略，并将网络策略返回至Ryu控制器；通过Ryu控制器对网络策略翻译为OpenFlow协议的流表响应到Open vSwitch；通过Open vSwitch安装对应的流表，并按照流表进行目标报文的转发；将Kubernetes中原有的kube‑proxy的功能整合进了网络控制器中可以为集群节省硬件资源，且减少了Kubernetes集群系统中安装的规则。

Description

一种在Kubernetes环境下基于Open vSwitch的服务代理方法

【技术领域】

本申请涉及一种在Kubernetes环境下基于Open vSwitch的服务代理方法，属于通信技术领域。

【背景技术】

Kubernetes是一个开源的容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理，是构建PaaS(Platform as a service)平台的基础平台，帮助用户将云端基础设施部署和创建到客户端，用户不再需要管理和控制云端的基础设置(包括网络、服务器、操作系统和存储)，仅仅需要直接面向其所需要部署的应用进行管理即可。PaaS平台抽象掉了硬件和操作系统细节，以便于能够使用户更加关注自己的业务逻辑和扩展自己的业务。当在生产环境中部署一个应用程序(即这个业务)时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

在Kubernetes中，通过名为Service的资源来实现到业务侧的负载均衡与故障隔离，同时也可以对外提供访问。Kubernetes实现这一负载均衡主要通过其内置的kube-proxy实现，kube-proxy通过在操作系统上安装对应的规则或者在Linux内核中直接配置IP虚拟服务器(IP Virtual Server，IPVS)，实现负载均衡及对外访问能力。

然而，Kubernetes中的kube-proxy同时依赖Linux系统的控制面与转发面，报文处理依赖客户端代理(iptables)模块，在规则较多时性能下降；同时，报文需要进入系统中处理，安装规则繁多，容易造成冲突。另外，kube-proxy在Linux系统下和在Windows系统下表现出不同的行为，这为跨系统的功能开发带来了不便。kube-proxy依赖Linux操作系统处理报文，在系统中处理时对开放式系统互联通信参考模型(Open System InterconnectionReference Model，OSI)第二层的报文处理能力有限，并且不适合大量规则安装。

【发明内容】

本申请提供了一种在Kubernetes环境中基于Open vSwitch的服务代理方法，可以对操作系统数据平面进行一次抽象，使得整个网络系统可以在不同的系统中使用，程序仅仅需要为OpenFlow控制器安装对应的流表项即可，同时，本发明的网络控制器作为控制控制面能够取代kube-proxy，无需再为操作系统安装规则处理报文。另外，系统中仅仅安装NodePort类型的iptables规则，其他类型的Service均可交由Open vSwitch在内部直接处理并转发，而无需再进入系统中依靠iptables处理。同时，可以实现负载均衡、故障隔离的同时提供了数据面的抽象，控制面始终只需要通过OpenFlow协议与数据面通信并且下发流表即可，而无需再单独在不同的操作系统中安装不同的配置。基于Open vSwitch设计，通过OpenFlow协议为Open vSwitch安装流表，同时Open vSwitch能够按照预先的设定向Ryu控制器查询逐包的策略，能够支持OSI多层的报文处理，流审计也可以从OSI第二层一直覆盖到第四层。本申请提供如下技术方案：

提供在Kubernetes环境中基于Open vSwitch的服务代理方法，用于Kubernetes集群中的节点中，所述节点安装有网络控制器、Ryu控制器和Open vSwitch；所述网络控制器通过所述Ryu控制器与所述Open vSwitch通信相连；所述方法包括：

在所述Open vSwitch接收到目标报文时，通过所述Open vSwitch将所述目标报文的报文信息基于OpenFlow协议发送至所述Ryu控制器；

通过所述Ryu控制器将所述报文信息上报至所述网络控制器；

通过所述网络控制器确定所述目标报文对应的网络策略，并将所述网络策略返回至所述Ryu控制器；

通过所述Ryu控制器对所述网络策略翻译为所述OpenFlow协议的流表响应到所述Open vSwitch；

通过所述Open vSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发。

可选地，所述方法还包括：

通过所述网络控制器调用所述Ryu控制器发起流表操作指示，所述流表操作指示包括流表删除指示和流表添加指示；

通过所述Open vSwitch按照所述流表操作指示操作对应的流表。

可选地，所述Kubernetes集群中Service的类型包括NodePort类型，所述在所述Open vSwitch接收到目标报文时，通过所述Open vSwitch将所述目标报文的报文信息基于OpenFlow协议发送至所述Ryu控制器之前，还包括：

响应于用户通过NodePort访问所述NodePort类型的Service，通过Linux系统的iptables确定一个端点并对所述目标报文进行目标网络地址转换DNAT；

通过系统路由选中到所述Open vSwitch的接口，并在所述目标报文进入所述OpenvSwitch前对所述目标报文进行源网络地址转换SNAT；

通过所述Open vSwitch的接口将DNAT和SNAT后的目标报文传送至所述OpenvSwitch。

可选地，所述端点与所述Open vSwitch位于同一所述节点内，所述通过所述OpenvSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发，包括：

通过所述Open vSwitch将所述目标报文转发至所述端点。

可选地，所述端点安装在与所述节点相独立的其它节点中，所述节点与所述其它节点之间通过隧道通信相连；

所述通过所述Open vSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发，包括：

通过所述Open vSwitch将所述目标报文转发至所述其它节点的Open vSwitch中，以使所述其它节点的Open vSwitch将所述目标报文转发至所述端点。

可选地，所述Kubernetes集群中Service的类型包括ClusterIP类型；所述在所述Open vSwitch接收到目标报文时，通过所述Open vSwitch将所述目标报文的报文信息基于OpenFlow协议发送至所述Ryu控制器，包括：

响应于所述Kubernetes集群中的容器Pod访问所述ClusterIP类型的Service，通过所述Open vSwitch接收所述Pod的目标报文，并将所述目标报文上报至所述Ryu控制器，以获取流表。

可选地，所述通过所述Open vSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发，包括：

通过所述Open vSwitch按照所述流表对所述目标报文进行连接跟踪与DNAT；将新的目标报文重新上报，以获取转发流表；

按照所述流表进行所述新的目标报文的转发。

可选地，所述Pod与所述端点位于同一所述节点内，所述按照所述流表进行所述新的目标报文的转发，包括：

通过所述Open vSwitch将所述新的目标报文转发至所述端点。

可选地，所述Pod安装在所述节点中，所述端点安装在与所述节点相独立的其它节点中；所述节点与所述其它节点之间通过隧道通信相连；所述按照所述流表进行所述新的目标报文的转发，包括：

通过所述Open vSwitch将所述新的目标报文转发至所述其它节点的OpenvSwitch中，以使所述其它节点的Open vSwitch将所述目标报文转发至所述端点。

可选地，所述通过所述Open vSwitch将所述新的目标报文转发至所述其它节点的Open vSwitch中之后，还包括：

在接收到所述其它节点的Open vSwitch反馈的回程报文时，对所述回程报文进行SNAT，再转发至所述Pod。

本申请的有益效果至少包括：通过在Open vSwitch接收到目标报文时，通过OpenvSwitch将目标报文的报文信息基于OpenFlow协议发送至Ryu控制器；通过Ryu控制器将报文信息上报至网络控制器；通过网络控制器确定目标报文对应的网络策略，并将网络策略返回至Ryu控制器；通过Ryu控制器对网络策略翻译为OpenFlow协议的流表响应到OpenvSwitch；通过Open vSwitch安装对应的流表，并按照流表进行目标报文的转发；将Kubernetes中原有的kube-proxy的功能被整合进了网络控制器中，在容器创建时安全策略、负载均衡策略等就已经一并准备就绪；可以为集群节省硬件资源。

另外，Pod访问ClusterIP类型的Service的路径缩短，无需次次经过内核路由和iptables，也节省了一定的CPU资源。

另外，原本kube-proxy将所有的报文都放在Linux系统中进行处理，使得系统中的iptables规则非常繁多，随着Pod和Service的增加，iptables的规则数量会非常大。而本申请中，系统中仅有少量NodePort的规则，相对之前大大减少，大大减少了系统中安装的规则。

另外，跨操作系统仅需维护一套流表，提高了开发效率，没有了额外适配不同操作系统的工作量。换言之，控制不同操作系统的容器网络仅仅需要编程下发不同的OpenFlow流表即可，不需要对不同操作系统进行单独适配。

另外，以往使用iptables大量规则会影响性能，对OSI第二层支持也欠佳。而本申请中可以支持第二层甚至端口粒度的匹配，大大提高了报文转发的灵活性。

另外，原本的kube-proxy实现Service主要借助iptables，规则繁多时性能会下降。而本申请中，所有的规则会从控制器的哈希表中查询，不损失性能的情况下支持大量规则安装。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，并可依照说明书的内容予以实施，以下以本申请的较佳实施例并配合附图详细说明如后。

【附图说明】

图1是本申请一个实施例提供的在Kubernetes环境中基于Open vSwitch的服务代理系统的结构示意图；

图2是本申请一个实施例提供的网络控制器、Ryu控制器和Open vSwitch之间的通信关系示意图；

图3是本申请一个实施例提供的在Kubernetes环境中基于Open vSwitch的服务代理方法的流程图；

图4是本申请一个实施例提供的对流表进行操作的方法的流程图；

图5是本申请一个实施例提供的NodePort类型的服务代理方法的流程图；

图6是本申请一个实施例提供的ClusterIP类型的服务代理方法的流程图。

【具体实施方式】

下面结合附图和实施例，对本申请的具体实施方式做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

首先，对于本申请涉及的若干名词进行介绍。

Kubernetes：简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。Kubernetes是一个开源的容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理，是构建PaaS(Platform as a service)平台的基础平台，帮助用户将云端基础设施部署和创建到客户端，用户不再需要管理和控制云端的基础设置(包括网络、服务器、操作系统和存储)，仅仅需要直接面向其所需要部署的应用进行管理即可。PaaS平台抽象掉了硬件和操作系统细节，以便于能够使用户更加关注自己的业务逻辑和扩展自己的业务。当在生产环境中部署一个应用程序(即这个业务)时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问。

Kubernetes中存在众多的资源，如：外部机器可访问的端口(NodePort)、服务器集群(Cluster)IP、节点(Node)、容器(Pod)、服务器(Service)、隧道(Tunnel)、端点(Endpoint)。Node为集群中的某一个节点，Pod则为节点上的容器集。其中，Service资源进一步又细分为NodePort、ClusterIP等类型，主要是为应用集提供负载均衡与故障隔离服务。Endpoint指Service最终所指向的负载均衡器后众多的Pod。Tunnel则为覆盖(Overlay)模式下互通的隧道，用于在不同的机器间传输数据。

其中，NodePort类型的Service是指在每个Node上分配一个端口作为外部访问入口。

ClusterIP类型的Service是指分配一个集群内部可以访问的虚拟IP(VIP)。

Kube-proxy：是kubernetes工作节点上的一个网络代理组件，运行在每个节点上。Kube-proxy维护节点上的网络规则，实现了Kubernetes Service概念的一部分。它的作用是使发往Service的流量(通过ClusterIP和端口)负载均衡到正确的后端Pod。

Open vSwitch：是一款可用于生产的、支持开放式系统互联通信参考模型(OpenSystems Interconnection，OSI)多层的虚拟交换机，是Linux基金会的开源项目之一。其支持主流的交换机功能，最大的特点就是支持OpenFlow这一数据包处理规范。

网络控制器：用于管理所有的Pod、Service等的网络策略规则，与Ryu、OpenvSwitch联合使用，指导报文处理与转发。

Ryu：是开源的软件定义网络的控制器开发框架，其支持OpenFlow等协议，为OpenvSwitch提供OpenFlow协议流表下发，支撑Open vSwitch处理和转发报文。

超文本传输协议(Hypertext Transfer Protocol，HTTP)和应用程序接口(Application Programming Interface，API)是基于编程语言构建的结构，提供一些预先定义来提供应用程序在不需要访问源码的情况下使用程序的功能。

目标网络地址转换(Destination Network Address Translation，DNAT)与源网络地址转换(Source Network Address Translation，SNAT)统称为NAT，是将IP数据包包头的IP地址转换为另外一个地址的协议。

虚拟局域网(Virtual Local Area Network，VLAN)：是将一个物理上的LAN在逻辑上划分成多个广播域的通信技术。VLAN内的主机可以直接通信，而不同VLAN间则不可以，从而将广播报文限制在一个VLAN内。

媒体存取控制(Media Access Control，MAC)地址：也称为区域网络地址，其由网卡确定，用于OSI第二层的报文传输。

OpenFlow：一种网络通信协议，属于数据链路层，能够控制网上交换器或路由器的转发平面(forwarding plane)，借此改变网络数据包所走的网络路径。OpenFlow允许从远程控制网络交换器的数据包转送表，透过新增、修改与移除数据包控制规则与行动，来改变数据包转送的路径。同时，OpenFlow允许不同供应商用开源的协议远程管理交换机(通常提供专有的接口和描述语言)。

流表：可被视作是OpenFlow对网络设备的数据转发功能的一种抽象。在传统网络设备中，交换机和路由器的数据转发需要依赖设备中保存的二层MAC地址转发表或者三层IP地址路由表。而OpenFlow交换机中使用的流表也是如此，不过在它的表项中整合了网络中各个层次的网络配置信息，从而在进行数据转发时可以使用更丰富的规则。

访问控制列表(Access Control Lists，ACL)：是一种基于包过滤的访问控制技术，它可以根据设定的条件对接口上的数据包进行过滤，允许其通过或丢弃。访问控制列表被广泛地应用于路由器和三层交换机，借助于访问控制列表，可以有效地控制用户对网络的访问，从而最大程度地保障网络安全。

Linux系统是一套免费使用和自由传播的类Unix操作系统，iptables是Linux的一个应用软件，用于操作Linux内核对特定条件的报文进行处理。

图1是本申请一个实施例提供的在Kubernetes环境中基于Open vSwitch的服务代理系统的结构示意图，该系统包括：Kubernetes集群中的节点Node106和110。图1中以节点的数量为2个为例进行说明，在实际实现时，节点的数量也可以为两个以上，本实施例不对节点的数量作限定。

各个节点中安装有网络控制器(图中未示出)、Ryu控制器(图中未示出)和OpenvSwitch；参考图2，网络控制器21通过Ryu控制器22与Open vSwitch23通信相连。

其中，网络控制器和Ryu控制器均为本申请创造地开发出的程序。

基于图2可知，本实施例提供的服务代理方法参考图3，该方法至少包括如下几个步骤：

步骤301，在Open vSwitch接收到目标报文时，通过Open vSwitch将目标报文的报文信息基于OpenFlow协议发送至Ryu控制器。

可选地，报文信息包括但不限于：报文的五元组信息、VLAN信息、和/或MAC地址信息等，本实施例不对报文信息的内容作限定。

步骤302，通过Ryu控制器将报文信息上报至网络控制器。

具体地，Ryu控制器可以通过HTTP调用网络控制器21的API(如图2中HTTP API211)，以查询目标报文所对应的网络策略，进而决定为Open vSwitch安装何种规则、何种类型的流表。

步骤303，通过网络控制器确定目标报文对应的网络策略，并将网络策略返回至Ryu控制器。

步骤304，通过Ryu控制器对网络策略翻译为OpenFlow协议的流表响应到OpenvSwitch。

步骤305，通过Open vSwitch安装对应的流表，并按照流表进行目标报文的转发。

比如：当一个目标报文进入Open vSwitch后，Open vSwitch会将该目标报文的五元组信息、VLAN信息、MAC地址信息等通过OpenFlow协议发送到Ryu控制器，Ryu控制器会将OpenFlow协议中的信息整理并上报到网络控制器，由网络控制器查找对应的下一跳、ACL策略等并返回给Ryu控制器，Ryu控制器再将该信息整理，并翻译成OpenFlow协议响应到OpenvSwitch，以便Open vSwitch安装对应的流表并且对报文及其后续报文进行匹配、操作。

可选地，网络控制器21还可以实现对Open vSwitch实时的流表删除、添加等操作。

具体地，参考图4，对对Open vSwitch实时的流表操作至少包括以下几个步骤：

步骤401，通过网络控制器调用Ryu控制器发起流表操作指示，流表操作指示包括流表删除指示和流表添加指示。

具体地，网络控制器可以通过HTTP协议调用Ryu控制器22的API(如图2中的HTTPAPI 221)。

Ryu控制器发起流表操作指示时可以基于OpenFlow协议向Open vSwitch发送流表操作指示。

步骤402，通过Open vSwitch按照流表操作指示操作对应的流表。

下面结合图1所示的具体在Kubernetes环境下基于Open vSwitch的服务代理的用例架构对本申请提供的服务代理方法进行详细介绍。

参考图1，节点106安装有Pod103、Pod104和Open vSwitch105。节点110安装有Pod107、Pod108和Open vSwitch109。图1中以节点106和节点110中均安装有两个Pod为例进行说明，在实际实现时，节点中可以有更多的Pod，且不同节点中Pod的数量相同或不同，本实施例不对Kubernetes集群的实现方式作限定。节点106中的Open vSwitch105与节点110中的Open vSwitch109之间通过隧道Tunnel 111打通，使得报文可以向远程机器发出。

本申请提出的服务代理分为两种，一种为NodePort类型，另一种为ClusterIP类型，下面分别对这两种类型进行介绍。

第一种：Kubernetes集群中Service的类型包括NodePort类型。此时，参考图5，服务代理方法至少包括以下几个步骤：

步骤51，响应于用户通过NodePort访问NodePort类型的Service，通过Linux系统的iptables确定一个端点并对目标报文进行目标网络地址转换DNAT。

步骤52，通过系统路由选中到Open vSwitch的接口，并在目标报文进入OpenvSwitch前对目标报文进行源网络地址转换SNAT。

步骤53，通过Open vSwitch的接口将DNAT和SNAT后的目标报文传送至OpenvSwitch，以执行步骤301-304。

步骤54，通过Open vSwitch确定是否到远程的端点；若是，作为步骤305的可替换步骤，执行步骤55；若否，作为步骤305的可替换步骤，执行步骤56；

步骤55，通过Open vSwitch将目标报文转发至其它节点的Open vSwitch中，以使其它节点的Open vSwitch将目标报文转发至端点。

端点安装在与节点相独立的其它节点中，节点与其它节点之间通过隧道通信相连。

步骤56，通过Open vSwitch将目标报文转发至端点。

比如：参考图1，创建NodePort类型的Service并绑定Pod104与Pod108为端点Endpoint，当用户端112访问该Service时，其可以访问任意一个节点(如图中节点106与节点110均可)。当访问节点106时，目标报文进入节点106系统中，经由Linux系统的iptables对该目标报文进行DNAT，目标IP将会随机选中Pod104或者Pod108之一进行转换。经过系统路由选中到Open vSwitch 105，在进入Open vSwitch 105前会再进行SNAT将源IP修改为节点106的网卡地址。最后，当选中Pod为104时，则直接转发到Pod104，否则经过Tunnel 111到节点110的Open vSwitch109，再由Open vSwitch109转发到Pod108。

第二种：Kubernetes集群中Service的类型包括ClusterIP类型。此时，参考图6，服务代理方法至少包括以下几个步骤：

作为步骤301的可替换步骤，步骤61，响应于Kubernetes集群中的容器Pod访问ClusterIP类型的Service，通过Open vSwitch接收Pod的目标报文，并将目标报文上报至Ryu控制器，执行步骤302-304，以获取流表。

作为步骤305的可替换步骤，步骤62，通过Open vSwitch按照流表对目标报文进行连接跟踪与DNAT；将新的目标报文重新上报，再次执行步骤302-304以获取转发流表。

获取到的内部转发的流表用于供Open vSwitch进行新的目标报文的转发。

步骤63，通过Open vSwitch确定是否到远程的端点；若是，执行步骤64；若否，执行步骤65；

步骤64，通过Open vSwitch将新的目标报文转发至其它节点的Open vSwitch中，以使其它节点的Open vSwitch将目标报文转发至端点。

此时，在接收到其它节点的Open vSwitch反馈的回程报文时，对回程报文进行SNAT，再转发至Pod。

步骤65，通过Open vSwitch将新的目标报文转发至端点。

比如：当有Pod103需要访问ClusterIP类型的Service时，该Service又绑定了端点Pod104与Pod108，该Pod103访问ClusterIP的目标报文发出抵达Open vSwitch 105时，其会将该目标报文上报并下发流表，按照流表将该报文进行连接跟踪与DNAT，再将新的目标报文重新上报，获取转发流表。

当选中Pod为104时，则由Open vSwitch 105直接转发，否则经过Tunnel111发送到Node 110的Open vSwitch 109，再由它转发到Pod 108。回程时，则都回到Open vSwitch105，经过Open vSwitch内置的连接跟踪模块直接完成源地址修改，无需再下发NAT流表，再转发回Pod 103，完成服务代理。

综上所述，本实施例提供的在Kubernetes环境下基于Open vSwitch的服务代理方法，通过在Open vSwitch接收到目标报文时，通过Open vSwitch将目标报文的报文信息基于OpenFlow协议发送至Ryu控制器；通过Ryu控制器将报文信息上报至网络控制器；通过网络控制器确定目标报文对应的网络策略，并将网络策略返回至Ryu控制器；通过Ryu控制器对网络策略翻译为OpenFlow协议的流表响应到Open vSwitch；通过Open vSwitch安装对应的流表，并按照流表进行目标报文的转发；将Kubernetes中原有的kube-proxy的功能被整合进了网络控制器中，在容器创建时安全策略、负载均衡策略等就已经一并准备就绪；可以为集群节省硬件资源。

另外，Pod访问ClusterIP类型的Service的路径缩短，无需次次经过内核路由和iptables，也节省了一定的CPU资源。

另外，原本kube-proxy将所有的报文都放在Linux系统中进行处理，使得系统中的iptables规则非常繁多，随着Pod和Service的增加，iptables的规则数量会非常大。而本申请中，系统中仅有少量NodePort的规则，相对之前大大减少，大大减少了系统中安装的规则。

另外，跨操作系统仅需维护一套流表，提高了开发效率，没有了额外适配不同操作系统的工作量。换言之，控制不同操作系统的容器网络仅仅需要编程下发不同的OpenFlow流表即可，不需要对不同操作系统进行单独适配。

另外，以往使用iptables大量规则会影响性能，对OSI第二层支持也欠佳。而本申请中可以支持第二层甚至端口粒度的匹配，大大提高了报文转发的灵活性。

另外，原本的kube-proxy实现Service主要借助iptables，规则繁多时性能会下降。而本申请中，所有的规则会从控制器的哈希表中查询，不损失性能的情况下支持大量规则安装。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种在Kubernetes环境下基于Open vSwitch的服务代理方法，其特征在于，用于Kubernetes集群中的节点中，所述节点安装有网络控制器、Ryu控制器和Open vSwitch；所述网络控制器通过所述Ryu控制器与所述Open vSwitch通信相连；所述方法包括：

在所述Open vSwitch接收到目标报文时，通过所述Open vSwitch将所述目标报文的报文信息基于OpenFlow协议发送至所述Ryu控制器；

通过所述Ryu控制器将所述报文信息上报至所述网络控制器；

通过所述网络控制器确定所述目标报文对应的网络策略，并将所述网络策略返回至所述Ryu控制器；

通过所述Ryu控制器对所述网络策略翻译为所述OpenFlow协议的流表响应到所述OpenvSwitch；

通过所述Open vSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

通过所述网络控制器调用所述Ryu控制器发起流表操作指示，所述流表操作指示包括流表删除指示和流表添加指示；

通过所述Open vSwitch按照所述流表操作指示操作对应的流表。

3.根据权利要求1所述的方法，其特征在于，所述Kubernetes集群中Service的类型包括NodePort类型，所述在所述Open vSwitch接收到目标报文时，通过所述Open vSwitch将所述目标报文的报文信息基于OpenFlow协议发送至所述Ryu控制器之前，还包括：

响应于用户通过NodePort访问所述NodePort类型的Service，通过Linux系统的iptables确定一个端点并对所述目标报文进行目标网络地址转换DNAT；

通过系统路由选中到所述Open vSwitch的接口，并在所述目标报文进入所述OpenvSwitch前对所述目标报文进行源网络地址转换SNAT；

通过所述Open vSwitch的接口将DNAT和SNAT后的目标报文传送至所述Open vSwitch。

4.根据权利要求3所述的方法，其特征在于，所述端点与所述Open vSwitch位于同一所述节点内，所述通过所述Open vSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发，包括：

通过所述Open vSwitch将所述目标报文转发至所述端点。

5.根据权利要求3所述的方法，其特征在于，所述端点安装在与所述节点相独立的其它节点中，所述节点与所述其它节点之间通过隧道通信相连；

所述通过所述Open vSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发，包括：

通过所述Open vSwitch将所述目标报文转发至所述其它节点的Open vSwitch中，以使所述其它节点的Open vSwitch将所述目标报文转发至所述端点。

6.根据权利要求1所述的方法，其特征在于，所述Kubernetes集群中Service的类型包括ClusterIP类型；所述在所述Open vSwitch接收到目标报文时，通过所述Open vSwitch将所述目标报文的报文信息基于OpenFlow协议发送至所述Ryu控制器，包括：

响应于所述Kubernetes集群中的容器Pod访问所述ClusterIP类型的Service，通过所述Open vSwitch接收所述Pod的目标报文，并将所述目标报文上报至所述Ryu控制器，以获取流表。

7.根据权利要求6所述的方法，其特征在于，所述通过所述Open vSwitch安装对应的流表，并按照所述流表进行所述目标报文的转发，包括：

通过所述Open vSwitch按照所述流表对所述目标报文进行连接跟踪与DNAT；将新的目标报文重新上报，以获取转发流表；

按照所述流表进行所述新的目标报文的转发。

8.根据权利要求7所述的方法，其特征在于，所述Pod与所述端点位于同一所述节点内，所述按照所述流表进行所述新的目标报文的转发，包括：

通过所述Open vSwitch将所述新的目标报文转发至所述端点。

9.根据权利要求7所述的方法，其特征在于，所述Pod安装在所述节点中，所述端点安装在与所述节点相独立的其它节点中；所述节点与所述其它节点之间通过隧道通信相连；所述按照所述流表进行所述新的目标报文的转发，包括：

通过所述Open vSwitch将所述新的目标报文转发至所述其它节点的Open vSwitch中，以使所述其它节点的Open vSwitch将所述目标报文转发至所述端点。

10.根据权利要求9所述的方法，其特征在于，所述通过所述Open vSwitch将所述新的目标报文转发至所述其它节点的Open vSwitch中之后，还包括：

在接收到所述其它节点的Open vSwitch反馈的回程报文时，对所述回程报文进行SNAT，再转发至所述Pod。

Images