CN107947961A

CN107947961A - 基于SDN的Kubernetes网络管理系统与方法

Info

Publication number: CN107947961A
Application number: CN201710965670.0A
Authority: CN
Inventors: 钱誉
Original assignee: Shanghai Data Solution Co Ltd
Current assignee: Shanghai Data Solution Co Ltd
Priority date: 2017-10-17
Filing date: 2017-10-17
Publication date: 2018-04-20
Anticipated expiration: 2037-10-17
Also published as: CN107947961B

Abstract

本申请提供了一种基于SDN的Kubernetes网络管理系统与方法，用以解决现有技术中原生Kubernetes网络管理难以支持多样化应用场景的问题。本申请实现了容器化网络及Kubernetes系统的SDN化，因此实现了网络服务的自动化，能够精确定位故障及分析故障，从而降低了运营商对资深技术人员的依赖和人员管理成本，极大提升了运维管理的工作效率，同时对于SDN技术落地提供了有效的支撑，为容器化服务及Kubernetes系统提供强有力的网络层面支持。

Description

基于SDN的Kubernetes网络管理系统与方法

技术领域

本申请涉及信息技术领域，尤其涉及一种基于SDN的Kubernetes网络管理系统与方法。

背景技术

Kubernetes，也称为K8S，是一个用于自动部署的开源平台，提供了应用程序容器集群的扩展和操作，实现了以容器为中心的基础设置，因此提供了一个可跨越公共云或私有云的便携式平台。Kubernetes支持的容器网络接口为CNI的可插拔框架。

SDN(Software Defined Network)即软件定义网络，是一种新型网络架构，是网络虚拟化的一种实现方式，其通过将网络设备控制面与数据面分离开来，从而实现了网络流量的灵活控制，使网络作为管道变得更加智能。目前，公知的SDN系统中缺失针对容器化及Kubernetes的网络支持，同时各大主流厂商针对SDN系统都设置了技术壁垒，使之无法大规模且广泛的进行应用，例如思科的ACI采用的是oplex协议，其属于思科的私有协议，且APIC的南向接口过于封闭，需要思科专用设备支持，无法兼容第三方设备；又如Big switch使用基于openflow工业标准，但其使用特定的lldp机制导致刀片服务器无法使用，同时目前也未支持容器化及Kubernetes网络架构；华为则采用的是ODL标准，目前也暂无支持容器化及Kubernetes网络技术，同时由于ODL系统架构过于复杂，对于实际使用者来说维护升级成本太大，且不容易做二次定向开发；第三方技术如calico，对于多数据中心网络的支持存在瑕疵，且非常小众化，国内用户接触甚少，无法支持大规模应用及推广。

申请内容

本申请的一个目的是提供一种基于SDN的Kubernetes网络管理系统与方法，用以解决现有技术中原生Kubernetes网络管理难以支持多样化应用场景的问题。

为实现上述目的，本申请提供了一种基于SDN的Kubernetes网络管理系统，其中，该系统包括：

控制装置，用于提供管理、控制和虚拟网络的分析功能，其中，该装置包括配置模块、控制模块和分析模块，所述配置模块用于提供应用接口服务，所述控制模块用于提供所述系统的集中控制和管理，并与虚拟路由装置协调工作，所述分析模块用于响应Kubernetes应用的网络信息查询请求；

虚拟路由装置，用于提供虚拟覆盖网络，其中，该装置包括虚拟路由代理模块和虚拟路由转发模块，所述虚拟路由代理模块用于提供虚拟路由的控制，所述虚拟路由转发模块用于提供数据包转发服务。

进一步地，所述配置模块用于提供北向接口、南向接口和东西向接口，所述北向接口用于与Kubernetes应用进行连接，所述南向接口用于与虚拟路由装置或者物理路由设备进行连接，所述东西向接口用于与其他对等控制装置进行连接。

进一步地，所述虚拟路由转发模块用于从控制模块接收其所有的路由状态信息。

进一步地，所述虚拟路由转发模块用于通过隧道技术将数据包从虚拟机转发到其他虚拟机，所述隧道技术包括MPLS over GRE/UDP隧道和/或VXLAN隧道。

进一步地，所述虚拟路由装置用于分发虚拟机和Kubernetes节点间的映射。

进一步地，所述虚拟路由装置使用mplsd UDP封装来实现虚拟机间的链接。

此外，本申请还提供了一种基于SDN的Kubernetes网络管理方法，其中，该方法包括：

所述控制装置中的分析模块监听Kubernetes应用中的北向接口API消息；

在接收到Kubernetes应用中的北向接口API消息时，所述分析模块解析所述消息获取对虚拟网络的操作请求；

所述分析模块将解析得到的虚拟网络操作请求提交给所述控制装置中的控制模块；

所述控制模块通过所述虚拟路由装置将虚拟网络映射到物理网络，并在相应物理网络设备上执行网络请求。

进一步地，该方法还包括：

将物理网络设备上执行网络请求的结果返回给Kubernetes应用。

进一步地，所述分析模块解析所述消息获取对虚拟网络的操作请求，包括：

所述分析模块从北向接口API消息中获取要查询的操作请求，并通过数据库查询获取对虚拟网络的操作请求。

进一步地，所述控制模块通过所述虚拟路由装置将虚拟网络映射到物理网络，包括：

所述控制模块将虚拟网络操作请求提交给所述虚拟路由装置；

所述虚拟路由装置获取所述虚拟网络操作请求中的虚拟网络，并通过查询虚拟网络与物理网络间的映射将虚拟网络操作请求转换为物理网络操作请求；

所述虚拟路由装置将所述物理网络操作请求通过虚拟路由转发模块转发到对应的物理网络设备上执行。

与现有技术相比，本申请实现了容器化网络及kubernetes系统的SDN化，因此实现了网络服务的自动化，能够精确定位故障及分析故障，从而降低了运营商对资深技术人员的依赖和人员管理成本，极大提升了运维管理的工作效率，同时对于SDN技术落地提供了有效的支撑，为容器化服务及Kubernetes系统提供强有力的网络层面支持。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例中网络管理系统的功能结构图；

图2为本申请实施例中网络管理方法的流程图；

图3为本申请实施例提供的一种优选的与Kubernetes系统的交互示意图；

图4为本申请实施例的monster系统的逻辑架构示意图；

图5为本申请实施例的配置模块的逻辑示意图；

图6为本申请实施例的控制模块的逻辑示意图；

图7为本申请实施例的分析模块的逻辑示意图；

图8为本申请实施例的虚拟路由装置的逻辑示意图。

附图标记说明：1、基于SDN的Kubernetes网络管理系统，2、控制装置，21、配置模块，22、控制模块，23、分析模块，3、虚拟路由装置，31、虚拟路由代理模块，32、虚拟路由转发模块。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例提供了一种基于SDN的Kubernetes网络管理系统，如图1所示，该系统具体包括用于提供管理、控制和虚拟网络的分析功能的控制装置和用于提供虚拟覆盖网络的虚拟路由装置。其中的控制装置包括配置模块、控制模块和分析模块，所述配置模块用于提供应用接口服务，所述控制模块用于提供所述系统的集中控制和管理，并与虚拟路由装置协调工作，所述分析模块用于响应Kubernetes应用的网络信息查询请求。虚拟路由装置包括虚拟路由代理模块和虚拟路由转发模块，所述虚拟路由代理模块用于提供虚拟路由的控制，所述虚拟路由转发模块用于提供数据包转发服务。

控制装置是逻辑上集中但物理上分布式的SDN控制器，负责提供管理、控制和虚拟网络的分析功能，它提供了该网络管理系统的集中控制与管理，与虚拟路由装置协调工作。

控制装置还提供了北向REST API，这些北向REST API是实现Kubernetes云编排系统的基础，同时这些API还可以用于其他应用程序如OSS/BSS，REST API也可以用来实现该网络管理系统的WEB的GUI展示。

控制装置包含三个主要组件：配置模块、控制模块和分析模块，配置模块负责将高级数据模型转为低水平的网络交互元素；控制模块负责传播这些低水平的网络元素，使得网络元素和对等系统保持一致；分析模块负责从网络获取实时数据元素，以抽象形式呈现给应用程序。

如图5所示的配置模块中包括API服务器、消息总线、模式转换器和服务监控单元。API服务器单元主要是为Kubernetes云编排程序配置系统提供的北向REST API接口。消息总线单元例如RabbitMQ，用于实现模块内部各单元间的信息交互。配置模块通过模块外部的数据库实现配置的持久性和高可用性。模式转换器单元将“高级数据模型”编译为虚拟路由装置和物理网关路由器支持的低级模型。服务监控单元的主要作用是管理服务链接和负载均衡。配置模块还通过分布式协作服务如Zookeeper等实现锁定资源和主从选择。

在此，配置模块提供了三个API界面：一组北向接口用于与Kubernetes应用进行连接，例如Kubernetes云编排系统和应用程序，一组南向接口用于和虚拟路由装置或者物理路由设备如网关路由器或交换机连接，以及一组东西向接口用于与其他对等控制装置进行链接。在此，东西向接口使用标准的边界网关协议BGP接口，控制装置使用XMPP协议的南向接口与虚拟路由装置进行对接，同时使用边界网关协议BGP和Netconf南向接口链接物理网关路由器和交换机。

如图6所示的控制模块中包括域名解析单元、网关交互单元、消息服务器单元和Proxies单元。域名解析单元使用域名解析技术如DNS实现对网络域名的映射。网关交互单元通过使用网关协议如BGP协议实现多个控制模块实例之间的连接互通。虚拟路由装置通过消息服务器单元实现的消息机制如XMPP协议链接多个控制模块实例来进行冗余保护。Proxies单元在处理某些请求时作为计算类型节点通过消息服务器单元发送XMPP消息。

控制模块的所有运行实例都是主动状态，从而实现了多活模式，这样的好处是任何一个运行实例出现问题时该故障实例能够被直接替换，因此提高了稳定性及容错率。控制模块的每个实例通过模块外部的消息总线如RabbitMQ来获得配置的更新。

如图7所示的分析模块包括API服务器单元、队列引擎单元、收集器单元、缓存单元、告警发生器单元等，其通过收集器单元与虚拟路由装置、控制模块、配置模块相连接，通过相互的协作来完成分析功能。分析模块还与外部的编译接口器交互来获得北向REST API被调用的消息。分析模块中的查询引擎从内部的API服务器得到需要查询的请求，然后查询存储了所有类型的持久性分析数据的数据库和数据库中的缓存并获得查询结果。分析模块中的收集器单元包括规则引擎，规则引擎在特定时间发生时候会自动进行数据收集，收集所有其他节点如虚拟路由装置、控制模块和配置模块发送的运行状态信息。

如图8所示的虚拟路由装置是转发平面的分布式路由器，例如可运行在虚拟服务器或容器内的管理程序，它扩展了在数据中心内的网络物理路由器和交换机，以提供虚拟覆盖网络的方式提供业务支持，还提供了比路由更高层的服务。虚拟路由装置可用于分发虚拟机和Kubernetes节点间的映射。

虚拟路由装置是完全软件实现的网络元素，它主要通过隧道技术负责将数据包从一个虚拟机(容器)转发到其他虚拟机(容器)。隧道形成一个覆盖物理网络IP-OVER-ETHERNET之上的网络。每个虚拟路由装置由两部分组成：虚拟路由代理模块和虚拟路由转发模块，虚拟路由代理模块实现控制平面，虚拟路由转发模块插入到虚拟机内核模块中以实现转发引擎。更具体地，虚拟路由转发模块用于从控制模块接收其所有的路由状态信息，并且用于通过隧道技术将数据包从虚拟机转发到其他虚拟机，隧道技术包括MPLS overGRE/UDP隧道和/或VXLAN隧道。

在本申请实施例的一种优选方案中，在物理机或虚拟机上使用Linux操作系统，使用虚拟路由转发模块替代Linux原有的Hypervisor Kernel中的Linux Bridge或OVS模块，然后虚拟路由转发模块执行网络的桥接与路由的功能，虚拟路由转发模块还可以执行安全策略、NAT、组播、镜像和负载均衡等网络层面的服务能力，要比原有的Linux Bridge或OVS所实现的功能更为强大，提供的网络服务也更为丰富。虚拟路由装置本身通过消息协议如XMPP协议链接到多个控制模块的实例以进行冗余保护，这样的好处在于业务感知度高，容错能力强，系统的安全性得到有力的保证。

本申请实施例中，Kubernetes提供了在部署中使用的3层基本架构，pod、replication controller和service。Pod是一个容器环境，可以执行一个或多个应用程序，每个Pod作为一个主机或可以作为多个共享相同环境的主机(包括网络)。Replicationcontroller与Pod具有相同的执行特征，协助确保制定的副本数量给Pod模板执行。Service为Pod集合提供消耗，通过一对一的IP中继，通常有多个后端作为负载均衡使用。

本申请实施例的网络管理系统没有修改Kubernetes代码库(如关闭V1.0.0RC2)，而是通过修改Kube网络管理端口的配置设置项来将Kubernetes原生的网络管理系统切换为本申请实施例的网络管理系统。例如，通过Kube网络管理端口kubelets执行：“network_plugin＝monster”，该语句用于指示kubelet执行命令到本申请实施例的Kubernetes网络管理系统monster，使用的配置文件保存在如下地址中：/Usr/libexec/kubernetes/kubelet-plguins/net/exec/monster/monstercontrol。本申请实施例的Kubernetes网络管理系统monster的逻辑架构如图4所示，其提供了对CNI的支持，通过对Kubernetes的综合提供了额外的网络功能，包括多租户、网络隔离、具有网络策略的分段及负载均衡等，以下都使用monster系统来具体说明本申请实施例的Kubernetes网络管理系统。

在此，monster系统中的控制装置作为kube代理使用，并禁止kube本身的功能，所有的pod链接直接通过monster系统中的虚拟路由装置使用mplsd UDP封装来覆盖整个网络。

Monster系统还负责分发pod和kubernetes节点之间的映射，这样就可以实现现有多供应商网络设备之间的相互操作。

在此，本申请实施例中使用KUBE-network-mngt通过kubernetes控制器来监听REST API，然后创建用于使用所描述的monster系统定义的虚拟网络、网络接口和访问控制策略应用到所对应的应用程序。其中网络前端RC的元数据信息先复制到由kube-control-manger创建的每一个pod，因此网络管理员可以看到这些pod，然后再创建虚拟网络与所述名称<名称空间：前端>，连接此网络与网络针对服务<名称空间：master redis>，根据来自集群范围的唯一私有IP地址(例如10.0.0.0/16)创建每个pod的副本接口。例如：以应用程序的k8s部署配置为例，其中包括RC和web服务器的服务对象、通过redis-master的POD和服务对象，

该元数据信息被复制到由kube-controller-manager创建的每个pod副本，当网络管理器看到这些POD时，它将创建名为<namespace:frontend>的虚拟网络，将该网络与服务<namespace:redis-master>的网络连接，使用来自集群范围的地址块(例如192.168.X.0)的唯一私有IP地址为每个POD副本创建一个接口。

然后kube-netwrok-manager使用monster创建UUID界面以及已分配的专用IP地址和MAC地址对POD进行注释，这些注释将被K8S中的kubelet读取。当POD由相应的kubelet启动时，调用插件脚本，该插件脚本删除与docker0网桥相管理的veth-pair，并将其分配给monster中的虚拟路由转发模块，并在每个虚拟机节点上执行。相同的脚本通知monster虚拟路由代理模块与veth接口相关联并到UUID界面，并配置POD的网络命名空间内的IP地址，这个阶段下，每个POD在集群中具有唯一的IP地址，但只能与同一虚拟网络内的其他端口通信，子网广播和IP链路本地组播数据包将被转发到同一虚拟网络(由labels.name标签定义)中存在的一组pod，然后为每个POD接口分配专用的转发表(即虚拟私有路由表)，与docker使用的网络命名空间相关联的veth-pair映射到一个表项中。该表具有在该POD已授权访问的同一网络或网络中定义的每个其他POD实例的路由条目。路由表由monster中控制模块集中计算，再分发给运行的每一个虚拟路由装置节点，并部署定义与WEB前端POD相关联的服务：

这里的selctor标签指定属于该服务的POD，然后该服务由kube-controller-manager分配一个clusterIP(集群)地址，这个clusterIP是一个唯一的地址，可以被其他POD用于使用该服务，该特定服务还可以分配可在集群外访问的public IP地址(即公网IP)。在定义服务的时候，kube-network-manager会为这个服务创建一个名称为<namespace:service-frontend>的虚拟网络，并由k8s指定的clusterIP分配一个浮动的IP地址，然后这个浮动的IP地址与每个副本相关联。然后在K8S中，有一个由RC定义的负载生成器层，具有以下元数据：

此时，network-manager进程将使用标签解释为BPS的网络隐式授权，以访问包含clusterIP的服务前端的网络，这是导致clusterIP地址与负载生成器POD相关联的专用路由表中可见的机制。当流量发送到clusterIP地址时，发送方有多个可用路径(如每个副本一个)，它是基于对数据包的5个元组(IP源、IP目的地址、协议、源端口、目标端口)的散列来选择其中之一，流量被封装到目的节点，内部分组的目的地址IP是clusterIP，目标节点中的虚拟路由转发模块然后对clusterIP执行目标NAT操作，并将该地址转为特定POD的专用IP。

负载发生器端口用于发送到WEB前端的clusterIP数据包，并执行以下步骤：数据包由容器中的IP堆栈通过源IP＝load-gen私有IP发送，目标IP＝clusterIP。该数据包发送到容器网络命名空间中的eth0，它是一个linux veth-pari的接口。数据包被传输到虚拟路由转发模块，对私有转发表“BPS”中的目的地IP地址(clusterIP)执行路由查找，路由查找返回下一跳(即可用路径列表)的负载平衡。然后ECMP算法选择一个可用路径并进行封装，以便通过源IP＝发送方节点地址，目的IP＝目的节点地址，将额外的IP报头添加到数据包中。另外，一个MPLS标签被添加到对应于目的端口的分组，分组在底层中传播到目的节点，目标节点剥去外部报头，并在MPLS标签上执行插座，并确定目标IP地址是“浮动IP”，并需要NAT转换。目标节点使用clusterIP的NAT映射创建一个flow-pair，并将目的端口的私有IP修改为有限负载的目标IP，分组被传送到POD，使得源IP是源POD的唯一私有IP，目的IP是本地POD的私有IP。

本申请实施例还提供了一种根据权利要求1所述的系统实现Kubernetes网络管理的方法，如图2所示，该方法包括如下步骤：

步骤S101，所述控制装置中的分析模块监听Kubernetes应用中的北向接口API消息；

步骤S102，在接收到Kubernetes应用中的北向接口API消息时，所述分析模块解析所述消息获取对虚拟网络的操作请求；

步骤S103，所述分析模块将解析得到的虚拟网络操作请求提交给所述控制装置中的控制模块；

步骤S104，所述控制模块通过所述虚拟路由装置将虚拟网络映射到物理网络，并在相应物理网络设备上执行网络请求。

在此，通过步骤S104在相应的物理网络设备上执行网络请求后，还需要将物理网络设备上执行网络请求的结果返回给Kubernetes应用。

具体地，在步骤S102中，分析模块从北向接口API消息中获取要查询的操作请求，并通过数据库查询获取对虚拟网络的操作请求。

在步骤S104中，控制模块通过所述虚拟路由装置将虚拟网络映射到物理网络，具体包括以下步骤：控制模块将虚拟网络操作请求提交给虚拟路由装置；虚拟路由装置获取虚拟网络操作请求中的虚拟网络，并通过查询虚拟网络与物理网络间的映射将虚拟网络操作请求转换为物理网络操作请求；虚拟路由装置将物理网络操作请求通过虚拟路由转发模块转发到对应的物理网络设备上执行。

在应用该Kubernetes网络管理的方法之前，还需要将本申请实施例的Kubernetes网络管理系统即monster系统接入到Kubernetes系统中，实现对原生Kubernetes网络管理系统的替换。具体地，是通过Kube网络管理端口修改Kubernetes网络管理配置文件，将K8S系统中原有的网络管理接口变更为本申请实施例的Kubernetes网络管理系统monster，并禁止kube本身的功能。

传统的K8S网络中存在两种IP(pod IP和service cluster IP)，pod IP地址是自己存在于某个网卡(虚拟设备)上的，service cluster IP是一个虚拟IP，是由kube-poxy使用操作系统如linux的iptables规则重新定向到其本地端口，再均衡到后端pod的。

Monster系统的做法是替换了kube-poxy的模块，使用容器网络接口(CNI)的可插拔框架，用于大多数基本的网络连接，包括容器框架寻址、网络隔离、基于策略的安全性、网关、SNAT和负载均衡器等。Monster系统通过实现SDN技术为K8S提供一个扁平的网络，使得容器(虚拟机)之间可以做到更好的安全性以及添加更多的网络策略，包括多租户、网络隔离、具有网络策略的微分段，因此提供了L7层的负载均衡能力，这是传统K8S做不到的地方。

Monster系统中提供了四种配置方式，默认模式、空间隔离方式、租户隔离方式和嵌套方式。

默认模式：在K8S中，所有的POD可以与所有其他POD通信，而不使用网络地址转换(NAT)，这个是monster中的默认模式。在默认模式下，monster创建一个由所有命名空间共享的虚拟网络，从中分配服务和PODIP地址。这样的话所产生的所有命名空间中的所有POD都可以互相通信，所有的POD IP地址都是从monster管理器配置的POD子网中分配得到。

空间隔离模式：对于空间隔离模式，集群管理员可以配置命名空间来注释打开隔离功能，除非安全组或网络策略被明确定义以允许访问，否则不能从其他命名空间访问该命名空间中的服务。例如配置为隔离的话：opencontrail.org/isolation:ture，命名空间隔离提供与POD网络隔离，因此孤立的命名空间中的POD不能与集群中的其他命名空间中的POD一起使用。命名空间隔离还提供与POD的服务隔离，如果K8S服务由孤立的命名空间中的POD实现，那么这些POD只能通过Kubernetes service-ip在同一命名空间中的达到POD。为了使服务保持可访问其他命名空间，通过命名空间上的附加注释来禁用服务隔离例如：

opencontrail.org/isolation.service:false。禁用服务隔离功能可使用服务在其他命名空间中可用POD，但孤立命名空间中的POD仍然无法连接到其他命名空间中的POD

租户模式：管理员和应用程序开发人员可以添加注释来制定要在其中配置命名空间中的POD或所有POD的虚拟网络。指定此自定义虚拟网络的注释例如：opencontrail.org/network:<fq_network_name>。如果在POD规范上配置了此注释，则该POD在该网络中启动。如果在命名空间规范中配置注释，则命名空间中所有的POD将在提供的网络中启动。

嵌套模式：monster系统支持在openstack集群中配置K8S，提供了折叠的控制和数据平面。其中单个monster控制平面和单个网络堆栈管理服务openstack和k8s集群。通过统一的控制和数据平面，互通和配置这些集群，在嵌套模式下，k8s集群接口CNI插件和monster-K8S管理器直接连接管理openstack的monster系统中的控制装置。

Monster系统中通过配置模块、控制模块和分析模块来对K8S系统中所有网络设备的虚拟网络。Monster系统提供了K8S管理器，用于实现需要的opencontrail API数据库中监听K8S API消息并创建相应的资源。更具体地，在其中会创建一个新的模块controller-kube-manger在docker容器中运行，用于监听来自K8S的API服务器的消息。

同时，Monster系统还提供了基于ECMP的K8S服务的负载均衡机制。K8S中的每个服务由负载均衡器对象表示，K8S分配的服务IP被用作负载均衡器的VIP(虚拟IP地址)。还为服务进行监听的端口创建监听器，每个POD都作为监听器池的成员进行添加。管理器根据服务标签或POD标签监听任何的更改项目，并使用任意添加、更新或删除的POD更新成员池列表。服务的负载均衡是基于ECMP的L4，而非代理负载平衡。Instance-ip(service ip)链接到服务中的每个POD的端口。然后在monster系统中创建ECMP下一跳，并且流量直接从源POD负载均衡。

对于K8S出口流量的负载均衡，是通过monster系统中的haproxy负载均衡器功能来实现k8s的ingrees。每当k8s中配置入口时，monster-kube-manager会在控制器中创建负载均衡器对象。Monster服务监听器监听负载均衡器对象，并根据活动待机模式下的入口规范，启动具有适当配置的haproxy。

Monster系统还提供了K8S网络策略安全组，用于规范POD之间和其他网络端点进行通信。Netwrokpolicy资源使用标签来选择POD并定义白名单规则，除了给定命名空间的策略所允许以为，还允许流量到所选的POD。Monster-kube-manager监听用用创建，更新，删除K8S网络策略事件，并将K8S网络策略转化为应用于虚拟机接口(VMI)的安全组对象，如果POD和标签被添加或删除，那么将会动态的更新VMI。

在K8S系统中的应用程序要访问虚拟网络时，通过Kubernetes控制器来监听北向REST API，然后将Monster中定义的虚拟网络、网络接口和访问控制策略提交给应用程序，如图3所示，图中的SDN monster control即为monster系统中的控制装置，用户可通过命令Kubectl访问Kubernetes系统中的API服务器，通过与其他功能服务如Kubelect服务信息、应答控制器、安排任务等的交互实现对Kubernetes应用的管理、配置工作，其中的虚拟网络的管理通过Kube网络管理接口对monster系统的控制装置完成。

Monster系统中的控制装置通过系统中的集中控制平面和管理平面与虚拟路由装置协调工作。每个控制模块都包含整个系统的所有操作状态，例如所有虚拟网络中的所有虚拟机的所有路由，控制状态的总量相对较小，可以简单快捷的适应每个控制节点(即控制模块存在的虚拟机)的存储器。随着更多功能的增加，控制模块的控制状态的聚合和分批可以使用BGP路由协议中的由目标特定路由反射器类似的机理来处理。

虚拟路由代理模块连接的所有节点都是主动激活的两个或多个控制节点。虚拟路由代理从每个控制节点接收其所有的状态如路由、路由实例配置等。从两个或多个节点收到的状态可以保证最终的一致性，在可能出现暂时不一致的情况下，它决定使用哪个控制器状态的副本，这个方式类似于BGP PE路由器接收相同路由的多个副本，并进行本地最佳路由选择。如果控制节点出现故障，那么虚拟路由代理将发现与该控制节点的链接丢失。虚拟路由代理将从失败的控制节点刷新所有状态。因为它具有来自其他控制节点的所有状态的冗余副本。虚拟路由可以立即切换而不需要重新同步，再次与服务发现服务器联系，重新建立与新控制节点的链接以替换故障控制节点。

虚拟路由装置运行在虚拟化或容器化的服务器中，在物理底层网络之上，使用动态隧道技术实现网络之间创建虚拟覆盖网络。这些隧道可以通过基于MPLS over GRE/UDP隧道或者VXLAN隧道。

虚拟路由装置是完全以软件方式实现的网络元组，其负责通过一组服务器到服务器的隧道将数据包从一个虚拟机(容器)转发到其他虚拟机(容器)，隧道形成了位于物理以太网的网络顶部覆盖网络。每个虚拟路由装置由两部分组成：实现控制平面的虚拟路由代理模块和实现转发引擎的虚拟路由转发模块。

虚拟路由装置的高可用性是基于包括BGP在内的许多路由协议使用的平滑重启模式。如果虚拟路由代理模块由于任何原因崩溃，虚拟路由转发模块将继续使用虚拟路由代理模块在重新启动之前安装的转发状态转发流量。当虚拟路由代理模块关闭时，虚拟路由转发模块以headless mode运行，所有转发状态都标记为过时。当虚拟路由代理模块重新启动时，它重新建立一对冗余控制节点的链接，会从控制节点重新学习所有状态，并重新安全转发平面中的新状态来替换旧状态。当虚拟路由代理模块完成从控制节点重新学习状态并完成在转发平台中的重新安装状态时，虚拟路由转发模块中的任何剩余过时的状态都将被刷新。

虚拟路由装置使用mplsd UDP封装来实现所有POD间的链接。当使用monster作为网络管理器的时候，在k8s中的kube-porxy进程会被禁用，并且所有的pod链接都是通过monster虚拟路由装置实现，该装置使用了mpls over udp作为封装的覆盖网络。虚拟路由装置使用基于标准的控制平面来分发端点(即POD)和位置(K8S节点)之间的映射。实现符合标准的网络环境可以与现有的多个品牌厂商的网络设备进行相互操作。然后kube-netwrok-manger进行使用k8s控制框架监听API中定义的对象中的更改，并向其中一些对象添加注释。然后由monster API为应用程序创建一个网络解决方案，以定义虚拟网络，网络接口和访问控制策略等对象。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个系统，该系统包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该系统运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。

Claims

1.一种基于SDN的Kubernetes网络管理系统，其中，该系统包括：

2.根据权利要求1所述的网络管理系统，其中，所述配置模块用于提供北向接口、南向接口和东西向接口，所述北向接口用于与Kubernetes应用进行连接，所述南向接口用于与虚拟路由装置或者物理路由设备进行连接，所述东西向接口用于与其他对等控制装置进行连接。

3.根据权利要求1所述的网络管理系统，其中，所述虚拟路由转发模块用于从控制模块接收其所有的路由状态信息。

4.根据权利要求1所述的网络管理系统，其中，所述虚拟路由转发模块用于通过隧道技术将数据包从虚拟机转发到其他虚拟机，所述隧道技术包括MPLS over GRE/UDP隧道和/或VXLAN隧道。

5.根据权利要求1所述的网络管理系统，其中，所述虚拟路由装置用于分发虚拟机和Kubernetes节点间的映射。

6.根据权利要求1所述的网络管理系统，其中，所述虚拟路由装置使用mplsd UDP封装来实现虚拟机间的链接。

7.一种根据权利要求1所述的系统实现Kubernetes网络管理的方法，其中，该方法包括：

8.根据权利要求7所述的方法，其中，该方法还包括：

将物理网络设备上执行网络请求的结果返回给Kubernetes应用。

9.根据权利要求7所述的方法，其中，所述分析模块解析所述消息获取对虚拟网络的操作请求，包括：

10.根据权利要求7所述的方法，其中，所述控制模块通过所述虚拟路由装置将虚拟网络映射到物理网络，包括：