CN115987778A - 一种基于Kubernetes集群的容器通信方法 - Google Patents

Abstract

本发明提供了一种基于Kubernetes集群的容器通信方法，该容器通信方法包括：获取Kubernetes集群中的各节点分别被纳管的对象以及SDN控制器被纳管的对象，以确定与Kubernetes集群适配的网络配置模式；基于适配的网络配置模式下所部署的虚拟路由器建立节点间的数据网络连接，以实现容器通信。通过本发明，实现了多样化场景下的网络部署，不依赖于第三方插件，以保证了网络的隔离性和安全性。同时，对管理网络和数据网络进行的分离和划分，有效地保障了网络间的隔离性。

Description

一种基于Kubernetes集群的容器通信方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于Kubernetes集群的容器通信方法。

背景技术

Kubernetes是一种轻便的可扩展的开源平台，用于管理容器化应用和服务。在Kubernetes集群中，计算、存储以及网络是核心的三大基础服务，而在这三者中，网络是一种应用场景最广且最难掌握的服务。SDN(Software Defined Networking，软件定义网络)是一种基于软件的网络架构及技术，其核心为OpenFlow技术，SDN通过控制器(Controller)及OpenFlow交换机(Switcher)将网络设备的控制面与数据面分开，从而实现对网络流量的灵活控制及数据报文的转发操作。

目前，最常见的应用场景是通过多个虚拟机部署Kubernetes集群以编排和调度容器。现有技术中大多是针对Kubernetes集群网络中的某个功能或者某种第三方插件(例如，CNI插件)来实现。CNI(Container Network Interface)插件是一种基于事件驱动模型的第三方插件，极容易存在遇到丢事件的问题，并具体表现为执行失败、Kubernetes集群对服务无法响应、主机挂起等，从而导致IP泄露、IP冲突等。由此导致依赖第三方插件来实现Pod跨集群通信的现有技术存在稳定性和数据报文转发性能方面的不足。

另外，诸如Calico等网络插件管理网络和数据网络(均为内网网络)分离时，均需要通过外网予以实现，因此存在内网网络与外网网络隔离不彻底和安全性等问题。此外，现有技术中主要是保障集群中Pod之间以及Pod和Service之间的内部通信，在Pod和虚拟机、物理机通信方面存在一定的局限性。同时，对于Pod跨集群通信主要依赖第三方插件，而使用网络插件实现跨集群网络通信也存在一定的缺陷。

有鉴于此，有必要对现有技术中的Kubernetes集群下的容器网络通信方法予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示现有技术中依赖第三方插件实现网络通信所存在的稳定性和数据报文转发性能不足的问题；同时，还解决了内网网络和外网网络隔离不彻底和安全性不足的问题。

为实现上述目的之一，本发明提供了一种基于Kubernetes集群的容器通信方法，包括：

获取Kubernetes集群中的各节点分别被纳管的对象以及SDN控制器被纳管的对象，以确定与所述Kubernetes集群适配的网络配置模式；

基于所述适配的网络配置模式下所部署的虚拟路由器建立节点间的数据网络连接，以实现容器通信。

作为本发明的进一步改进，所述Kubernetes集群中的各节点包括控制节点和业务节点；所述被纳管的对象包括物理节点或者虚拟节点。

作为本发明的进一步改进，所述各节点分别被纳管的对象由各节点分别对应的网络接口信息以及设备所属值予以确定，所述SDN控制器被纳管的对象由SDN控制器所存储的网络接口信息予以确定。

作为本发明的进一步改进，所述网络配置模式包括：嵌套模式、非嵌套模式以及混合模式；

其中，在所述嵌套模式下，Kubernetes集群中的各节点部署于虚拟节点中，并在虚拟节点所在的物理节点内部署SDN控制器；在非嵌套模式下，Kubernetes集群中的各节点部署于物理节点或者虚拟节点中，在所述物理节点和虚拟节点内部署独立于Kubernetes集群的SDN控制器；在混合模式下，控制节点部署于虚拟节点中，将虚拟节点所在的物理节点作为计算节点，并将计算节点作为Kubernetes集群的业务节点，在物理节点内部署独立于虚拟节点的SDN控制器。

作为本发明的进一步改进，所述确定与所述Kubernetes集群适配的网络配置模式具体为：

对控制节点与业务节点分别对应的网络接口信息在SDN控制器中执行查询操作，并查询控制节点和业务节点分别对应的设备所属值，以确定网络配置模式；

若SDN控制器中存储控制节点和业务节点分别对应的网络接口信息，且控制节点和业务节点分别对应的设备所属值的逻辑定义为虚拟节点，则将网络配置模式确定为嵌套模式；

若SDN控制器中存储控制节点和业务节点分别对应的网络接口信息，且控制节点和业务节点分别对应的设备所属值的逻辑定义为物理节点，则将网络配置模式确定为非嵌套模式；

若SDN控制器中仅存储控制节点对应的网络接口信息，且控制节点的设备所属值为虚拟节点，业务节点对应的网络接口信息不存在于SDN控制器中，业务节点内部署SDN控制器，则将网络配置模式确定为混合模式。

作为本发明的进一步改进，所述网络接口信息包括：与控制节点或者业务节点中的容器对应的网卡；

将所述网卡加入虚拟路由器中，并建立与接入数据网络的Tap端口之间的映射关系。

作为本发明的进一步改进，在所述嵌套模式下，虚拟路由器独立部署于虚拟节点所在的物理节点；在所述非嵌套模式下，虚拟路由器分别部署于控制节点和业务节点；在所述混合模式下，虚拟路由器独立部署于虚拟节点所在的物理节点。

作为本发明的进一步改进，所述容器将流量引流至对应的虚拟路由器，虚拟路由器之间通过overlay网络实现通信，以实现容器基于所述映射关系形成跨节点或者跨容器的通信。

作为本发明的进一步改进，还包括：

由第一节点中的容器将流量引流至第一节点对应的虚拟路由器中，所述第一节点对应的虚拟路由器通过所述overlay网络将流量转发至第二节点对应的虚拟路由器中，所述第二节点对应的虚拟路由器将所述流量引流至第二节点中的容器；

其中，所述第一节点和第二节点为控制节点、业务节点、物理节点或者虚拟节点。

作为本发明的进一步改进，还包括：

创建Pod网络、Service网络以及内部管理网络，通过NetworkPolicy网络策略建立所述Pod网络与所述内部管理网络的通信连接，以通过所述通信连接实现所述Pod网络与所述Service网络的通信。

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

根据Kubernetes集群各节点被纳管的对象以及SDN控制器被纳管的对象，以自动确定出适合当前状态的网络配置模式，以适应多样化场景下的网络部署，降低了用户的学习成本和运维复杂度。通过给虚拟节点添加内部管理网卡和数据网卡，实现了Kubernetes集群管理网络与数据网络的分离，相比于现有技术中CNI网络分离场景需要使用外部网卡的方式，不依赖于第三方插件，以保证了网络的隔离性和安全性。

附图说明

图1为本发明所示出的一种基于Kubernetes集群的容器通信方法的整体流程图；

图2为嵌套模式下网络配置模式的拓扑图；

图3为非嵌套模式下网络配置模式的拓扑图；

图4为混合模式下网络配置模式的拓扑图；

图5为嵌套模式下网络部署的拓扑图；

图6为非嵌套模式下网络部署的拓扑图；

图7为混合模式下网络部署的拓扑图；

图8为容器之间跨节点通信的拓扑图；

图9为嵌套模式下容器与内部管理网络通信的拓扑图；

图10为容器与虚拟节点通信的拓扑图；

图11为容器跨集群通信的拓扑图；

图12为非嵌套模式下容器与内部管理网络通信的拓扑图；

图13为主机与容器通信的拓扑图。

具体实施方式

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

在详细阐述本发明各实施例之前，对实施例所涉及的主要技术术语含义予以简要说明或者定义。

请参图1至图13所示出的一种基于Kubernetes集群的容器通信方法的一种具体实施方式。

本发明所揭示的一种基于Kubernetes集群的容器通信方法的应用场景为不同部署模式下的Kubernetes集群下的容器网络通信，主要用以解决现有技术中依赖于第三方插件实现网络通信所存在的稳定性和数据转发性能不足的问题。基于不同部署模式下的Kubernetes集群以确定适配的网络配置模式，从而基于适配的网络配置模式下部署的虚拟路由器创建数据网络，以建立不同节点间的网络连接，以最终通过虚拟路由器实现节点下的容器通信。其中，网络配置模式包括：嵌套模式、非嵌套模式以及混合模式。在嵌套模式下，Kubernetes集群中的各节点部署于虚拟节点中，并在虚拟节点所在的物理节点内部署SDN控制器；在非嵌套模式下，Kubernetes集群中的各节点部署于物理节点或者虚拟节点中，在物理节点和虚拟节点内部署独立于Kubernetes集群的SDN控制器；在混合模式下，控制节点部署于虚拟节点中，在虚拟节点所在的物理节点内部署独立于虚拟节点的计算节点，在计算节点内部署SDN控制器，并将计算节点作为Kubernetes集群的业务节点。

参图1所示，一种基于Kubernetes集群的容器通信方法具体包括以下步骤S1至步骤S2。

步骤S1、获取Kubernetes集群中的各节点分别被纳管的对象以及SDN控制器被纳管的对象，以确定与Kubernetes集群适配的网络配置模式。

示例性地，Kubernetes集群中的各节点包括控制节点和业务节点，控制节点即为Master节点，业务节点即为Node节点。其中，控制节点是Kubernetes集群的控制平面，用于负责集群的决策；业务节点是Kubernetes集群的数据平面，用于负责为容器提供运行环境。被纳管的对象包括物理节点或者虚拟节点。获取Kubernetes集群各节点被分别被纳管的对象由各节点分别对应的网络接口信息以及设备所属值予以确定。

参图2至图4所示，网络配置模式具体包括：图2所示出的嵌套模式，图3所示出的非嵌套模式以及图4所示出的混合模式。在图2所示出的嵌套模式下，由控制节点和业务节点构成的Kubernetes集群12部署于虚拟节点11内，虚拟节点11和SDN控制器13独立部署于物理节点10内。在图3所示出的非嵌套模式下，由控制节点和业务节点构成的Kubernetes集群22部署于物理节点20或者虚拟节点21内，在物理节点20或者虚拟节点21中部署独立于Kubernetes集群22的SDN控制器23。在图4所示出的混合模式下，控制节点32部署于虚拟节点31内，将虚拟节点31所在的物理节点30作为计算节点33，并将计算节点33作为Kubernetes集群的业务节点，在物理节点30内部署独立于虚拟节点31的SDN控制器34。

具体地，获取控制节点和业务节点所分别被纳管的对象以及SDN控制器被纳管的对象；其中，控制节点和业务节点所分别被纳管的对象由各节点分别对应的网络接口信息以及设备所属值予以确定，SDN控制器被纳管的对象由SDN控制器所存储的网络接口信息予以确定，从而确定与Kubernetes集群适配的网络配置模式。对控制节点和业务节点分别对应的网络接口信息在SDN控制器执行查询操作，并查询控制节点与业务节点分别对应的设备所属值，以确定当前场景下的网络配置模式。若SDN控制器中存储有控制节点和业务节点分别对应的网络接口信息，且控制节点和业务节点分别对应的设备所属值的逻辑定义为虚拟节点(即，device_owner的值为compute:nova)，则确定控制节点和业务节点都是SDN控制器所纳管的虚拟节点，从而将当前网络配置模式确定为嵌套模式。若SDN控制器中存储控制节点和业务节点分别对应的网络接口信息，且控制节点和业务节点分别对应的设备所属值的逻辑定义为物理节点(即，device_owner的值为physical)，则确定控制节点和业务节点均被SDN控制器所纳管，从而将当前网络配置模式确定为非嵌套模式。若SDN控制器中仅存储有控制节点对应的网络接口信息，且控制节点的设备所属值为虚拟节点(即，device_owner的值为compute:nova)，所有业务节点对应的网络接口信息均不存在于SDN控制器中，业务节点中均部署有SDN控制器，从而将当前网络配置模式确定为混合模式。

其中，网络接口信息包括：与控制节点或者业务节点中的Pod容器对应的Pod网卡；将Pod网卡加入虚拟路由器，并建立与接入的数据网络的Tap端口之间的映射关系。

步骤S2、基于适配的网络配置模式下所部署的虚拟路由器建立节点间的数据网络连接，以实现容器通信。

示例性地，参图2至图4所示，在嵌套模式下，虚拟路由器14部署于虚拟节点11所在的物理节点10；在非嵌套模式下，虚拟路由器分别部署于共同形成Kubernetes集群22的控制节点和业务节点；在混合模式下，虚拟路由器35部署于虚拟节点31所在的物理节点30。

具体地，参图5所示，在嵌套模式下，Controller1、Controller2以及Controller3分别表示一个物理节点。其中，Controller1中部署多个虚拟节点，例如，虚拟节点1和虚拟节点2。虚拟节点1中部署Pod1和Pod2，Pod1和Pod2分别对应不同的IP地址，即，Pod1的IP地址为10.244.0.10，Pod2的IP地址为10.244.0.11。配置Pod1、Pod2以及虚拟节点1分别对应的网卡，即，Pod1和Pod2分别对应的网卡eth0，以及虚拟节点1对应的网卡eth1。Pod1对应的网卡eth0以及Pod2对应的网卡eth0分别与虚拟节点1对应的网卡eth1建立连接。在Controller1所部署的虚拟路由器中建立与网卡eth1连接的Tap1端口，以通过虚拟节点1对应的网卡eth1将Pod1和Pod2分别对应的网卡加入虚拟路由器中，并在虚拟路由器中建立与接入数据网络的Tap端口之间的映射关系，即，虚拟节点1与Tap1端口的映射关系，Pod1对应的网卡eth0以及Pod2对应的网卡eth0分别与Tap-1端口以及Tap-2端口的映射关系。同理，将虚拟节点2对应的网卡加入虚拟路由器中，并建立该网卡与接入数据网络的Tap2端口的映射关系。Controller2与Controller3中网卡与端口的连接方式与Controller1类似，在此不再赘述。最终，将Controller1中所部署的虚拟路由器中的Tap1端口与Tap2端口，Controller2中所部署的虚拟路由器中的Tap1端口，以及Controller3中所部署的虚拟路由器中的Tap1端口与Tap2端口均接入同一数据网络，以成功创建数据网络。其次，创建管理网络分别与Controller1、Controller2以及Controller3耦接，以提供Pod网络和Service网络分别对应的主机路由。最后，基于预配置的Pod CIDR和Service CIDR通过代码的方式分别创建Pod网络和Service网络。其中，Pod网络是指能够保证Kubernetes集群中的所有Pod(包括同一节点上的Pod以及不同节点上的Pod)，逻辑上都在同一平面网络内，能够互相作IP寻址以及通信的网络。Service网络构建于Pod网络之上，用于解决服务发现和负载均衡的问题。创建内部管理网卡和子网，子网禁用网关，以通过内部管理网访问Pod网络，并在创建内部管理网时添加Pod网络和Service网络的主机路由。创建数据网卡和子网，子网禁用网关。将上述创建的内部管理网卡和数据网卡添加到虚拟节点。通过创建管理网络以实现了Kubernetes集群管理网络与数据网络的分离(即，Kubernetes集群中控制面通信与数据面通信的分离)，同时有效地保障了网络间的隔离性和安全性。

需要说明的是，前述添加Pod网络的主机路由参考如下代码：

#neutron net-create k8s-mgr-net1

#neutron subnet-create k8s-mgr-net1 10.20.30.0/24--no-gateway\

--host-route destination＝10.244.0/24,nexthoop＝10.20.30.2\

--host-route destination＝10.96.0/24,nexthoop＝10.20.30.2

#ip r

10.244.0.0/24via 10.20.30.2dev eth1 proto dhcp metric 101

10.96.0.0/24via 10.20.30.2dev eth1 proto dhcp metric 101

参图6所示，在非嵌套模式下，以控制节点为例，在控制节点中部署Pod1，对应的IP地址为10.244.0.10。同时，在控制节点中部署虚拟路由器，在虚拟路由器中配置与Pod1对应的Tap1端口，建立Tap1端口与Pod1对应的网卡的连接，以将Pod1对应的网卡加入虚拟路由器中，并建立与接入数据网络的Tap1端口之间的映射关系，即，Pod1对应的网卡与Tap1端口的映射关系。同理，业务节点1、业务节点2、以及SDN控制器中网卡与端口的连接方式与控制节点类似，在此不再赘述。最终，将控制节点部署的虚拟路由器中的Tap1端口、业务节点1部署的虚拟路由器中的Tap1端口、业务节点2部署的虚拟路由器中的Tap1端口、以及SDN控制器部署的虚拟路由器中的Tap1端口接入同一数据网络，以成功创建数据网络。其次，创建管理网络分别与控制节点、业务节点1、业务节点2以及SDN控制器耦接，以提供Pod网络和Service网络分别对应的主机路由。最后，基于预配置的Pod CIDR和Service CIDR通过代码的方式分别创建Pod网络和Service网络，并将其添加到控制节点、业务节点1、业务节点2以及SDN控制器上。

参图7所示，在混合模式下，Controller1、Controller2以及Controller3分别表示一个物理节点。以Controller1为例，Controller1中部署虚拟节点1、虚拟节点2、Pod1以及SDN控制器。控制节点部署于虚拟节点1中，将物理节点作为计算节点，并将计算节点作为业务节点，即，Controller1可视为业务节点，Pod1为业务节点所部署的容器。基于预配置的Pod CIDR和Service CIDR通过代码的方式分别创建Pod网络和Service网络，并将Pod网络和Service网络添加到控制节点所在的虚拟节点上。同时，为了保障Pod1后续访问apiservice的网络源进源出，在虚拟节点内部添加外网到Pod网络的策略路由，可参考如下代码：

ip rule add from<mgr-ip>table 10212

ip route add default via 10.0.215.254dev eth1 table 10212

ip route add 10.0.212.0/24dev eth1 table 10212

ip route add 10.244.0.0/16dev eth1 table 10212

其中，10.0.215.254dev eth1 table 10212是指eth1网卡默认的网关地址。

创建数据网卡并将其添加到Controller1上，将Controller1的管理网络与虚拟节点1的外网通过三层打通，以实现后续与虚拟节点外网的通信。在Controller1所部署的虚拟路由器中配置Tap端口，即，Tap1端口和Tap2端口。Tap1端口与Pod1对应的网卡连接，Tap2端口与虚拟节点2对应的网卡连接，将Pod1对应的网卡和虚拟节点2对应的网卡加入虚拟路由器中，并分别建立该网卡与接入数据网络的Tap1端口和Tap2端口的映射关系。Controller2与Controller3中网卡与端口的连接方式与Controller1类似，在此不再赘述。最终，将Controller1部署的虚拟路由器中的Tap1端口与Tap2端口、Controller2部署的虚拟路由器中的Tap1端口与Tap2端口以及Controller3部署的虚拟路由器中的Tap1端口与Tap2端口接入同一数据网络，以成功创建数据网络。

由此，基于上述三种网络配置模式下的网络部署方式实现容器通信。由于三种网络配置模式下的不同节点(即，控制节点、业务节点、物理节点或者虚拟节点等)中均部署了虚拟路由器，容器将流量引流至对应的虚拟路由器，虚拟路由器之间通过overlay网络实现通信，以实现容器基于映射关系形成跨节点或者跨容器的通信。例如，由第一节点中的容器将流量引流至第一节点对应的虚拟路由器中，第一节点对应的虚拟路由器通过overlay网络将流量转发至第二节点对应的虚拟路由器中，第二节点对应的虚拟路由器将流量引流至第二节点中的容器；其中，第一节点与第二节点为控制节点、业务节点、物理节点或者虚拟节点等。

具体而言，在嵌套模式下，参图5与图8所示，容器之间的跨节点通信，以Controller1中部署的虚拟节点1中的Pod1和Controller2中部署的虚拟节点中的Pod3之间的跨节点通信为例予以示范性说明。在虚拟路由器中采用sub interface(即，以太网子接口)的方式设置vlan tag对应不同容器的网卡，相同vlan tag的网卡可以互通，不同虚拟路由器之间通过overlay网络打通，相同vlan tag的网卡之间的数据包可以通过overlay网络实现跨节点传输。Pod1将流量通过虚拟节点1对应的网卡引流到Controller1部署的虚拟路由器中，相同vlan tag的网卡可以互通，从而实现将流量引流至Pod2，以实现了容器之间的跨节点通信。并具体为，Kubernetes集群中各个节点的数据网络(例如，图5中的eth1)与虚拟路由器中的Tap1端口为一对，因此Pod1访问Pod3的流量会被转发至Tap1端口，然后虚拟路由表会提供访问Pod3所在节点以及Pod3所对应的子接口的vlan tag，因此Controller1的Tap1端口将流量转发至Controller2的Tap-1端口，由于Pod3的vlan tag与Tap-1的vlantag相同，因此流量最终被转发至Pod3。

在嵌套模式下，容器与内部管理网络的通信方式。参图9所示，Pod网络、Service网络以及内部管理网络(即，api server)是三种不同的虚拟网络，在默认情况下是相互隔离的。由于Service网络通过负载均衡(即，Load Balance,LB)予以实现，因此Pod网络访问Service网络会转换为Pod网络访问内部管理网络，Pod网络和内部管理网络通过Networkpolicy网络策略打通，从而实现了Pod网络、Service网络以及内部管理网络之间的通信。其中，Mgmt：6443中的Mgmt表示内部管理网络，6443表示apiserver服务的端口，因此将Mgmt：6443作为一整体并表示为apiserver服务。

在嵌套模式下，容器与虚拟节点的通信方式。参图5与图10所示，容器与虚拟节点之间的通信，以Controller1中部署的Pod1与虚拟节点2为例予以示范性说明。Pod1将流量通过虚拟节点1对应的网卡引流到Controller1部署的虚拟路由器中，虚拟路由器中与虚拟节点1对应的Tap1端口，以及与虚拟节点2对应的Tap2端口在虚拟路由器内通过overlay网络打通，以将流量根据Tap2端口引流至虚拟节点2，从而实现了容器与虚拟节点之间的通信。

在嵌套模式下，主机与容器之间的通信方式。由于前述在内部管理网络中添加了Pod网络的主机路由(参考如上代码)，以使得主机(即，Host)访问容器(即，Pod)的路由转换为从内部网络访问容器，而Pod网络和内部管理网络通过Network policy网络策略打通，因此实现了主机、内部管理网络以及Pod网络之间的通信。另外，在嵌套模式下，参图11所示，容器的跨集群通信方式。多个不同集群的Pod网络之间是相互隔离的，但是被同一SDN集群(即，由多个SDN控制器所构成的SDN集群)所纳管，例如，虚拟节点1与虚拟节点2所分别对应的Pod网络之间是相互隔离的，通过Pod网络1、Pod网络2以及虚拟路由器三层打通实现了Pod1与Pod2之间的通信，从而实现了容器(即，Pod)的跨集群通信。

在非嵌套模式下，结合图6与图8所示，容器之间的跨节点通信，以控制节点所部署的Pod1与业务节点1所部署的Pod2为例予以示范性说明。与上述嵌套模式下的容器之间的跨节点通信不同，非嵌套模式不需要采用sub interface的方式设置vlan tag对应不同容器的网卡，而是直接将容器对应的网卡加入对应的虚拟路由器中，虚拟路由器之间通过overlay网络打通，以实现容器的跨节点通信。Pod1将流量通过其对应的网卡引流至控制节点所部署的虚拟路由器中，控制节点所部署的虚拟路由器与业务节点1所部署的虚拟路由器之间通过overlay网络打通，以通过overlay网络将流量引流至业务节点1所部署的虚拟路由器中，从而通过业务节点1所部署的虚拟路由器将该流量引流至Pod2，从而实现了容器之间的跨节点通信。

在非嵌套模式下，容器与内部管理网络(即，api server服务)的通信方式。参图5与图12所示，Pod网络和Service网络是两个不同的虚拟网络，默认情况下是相互隔离的。在非嵌套模式下，管理网络和数据网络不是SDN集群(即，由多个SDN控制器所构成的SDN集群)内的虚拟网络，因此通过SDN控制器的link-local方式，将容器访问Service IP的请求透传至数据网络，通过SNAT方式将Pod IP转换为业务节点对应的主机IP，然后转发至控制节点以实现容器与api server的通信。其中，Mgmt：6443是指api server服务，业务节点业务网络vhost0是指Pod1所在的业务节点的数据网络，Mgmt节点业务网络vhost0是指控制节点的数据网络。在非嵌套模式下的容器与虚拟节点之间的通信，与上述嵌套模式类似。将容器的网卡加入对应的虚拟路由器中，虚拟节点的网卡也加入对应的虚拟路由器中，虚拟路由器之间通过overlay网络打通，以实现了容器与虚拟节点之间的通信。

在非嵌套模式下，主机与容器之间的通信方式。参图6与图13所示，通过ip-fabric方式在kubernetes集群的所有节点(即，控制节点、业务节点1以及业务节点2)添加到Pod网络的路由规则，可参考如下代码：

10.244.0.0/16dev vhost0 proto 109scope link

因此，从主机访问Pod会转发至SDN控制器对应的虚拟节点对应的网卡，并转发至虚拟路由器中，从而通过虚拟路由器实现了主机(即，Host)与容器(即，Pod)之间的通信。

另外，结合图6与图11所示，在非嵌套模式下的容器跨集群通信，与嵌套模式类似。多个不同kubernetes集群的Pod网络之间是相互隔离的，但是被同一SDN集群(即，由多个SDN控制器所构成的SDN集群)所纳管，例如，虚拟节点1与虚拟节点2所分别对应的Pod网络之间是相互隔离的，通过Pod网络1、Pod网络2以及虚拟路由器三层网络打通，实现了Pod1与Pod2之间的通信，从而实现了容器(即，Pod)的跨集群通信。

在混合模式下，结合图7与图8所示，容器之间的跨节点通信，以Controller1所部署的Pod1与Controller2所部署的Pod2为例予以示范性说明。与上述非嵌套模式类似，直接将容器对应的网卡加入对应的虚拟路由器中，虚拟路由器之间通过overlay网络打通，以实现容器的跨节点通信，在此不再赘述。

混合模式下的容器与内部管理网络的通信方式也与上述嵌套模式类似。由于Service网络通过负载均衡(LB)予以实现，因此Pod网络访问Service网络会转换为容器访问内部管理网络，Pod网络和内部管理网络通过Network policy网络策略打通，从而实现了Pod网络、Service网络以及内部管理网络之间的通信。

混合模式下的容器与虚拟节点的通信方式与非嵌套模式类似。将容器的网卡加入对应的虚拟路由器中，虚拟节点的网卡也加入对应的虚拟路由器中，虚拟路由器之间通过overlay网络打通，以实现了容器与虚拟节点之间的通信。

混合模式下的业务节点对应的主机与容器的通信方式，由于混合模式下的控制节点和业务节点分开部署，因此对控制节点对应的主机与业务节点对应的主机予以分别说明。业务节点对应的主机与容器之间的通信方式，与上述非嵌套模式类似，通过ip-fabric方式在虚拟路由器所在的业务节点天界到Pod网络的路由规则，从业务节点对应的主机访问容器会转发至SDN控制器对应的虚拟节点的网卡，并转发至虚拟路由器中，从而通过虚拟路由器实现了业务节点对应的主机与容器之间的通信。控制节点对应的主机与容器之间的通信方式，通过将虚拟节点加入Pod网络，并在虚拟节点内部添加Pod网络路由以实现控制节点对应的主机与容器的通信。

混合模式下的容器跨集群的通信方式，与嵌套模式和非嵌套模式类似。多个不同集群的Pod网络之间是相互隔离的，但是被同一SDN集群(即，由多个SDN控制器所构成的SDN集群)所纳管，例如，虚拟节点1与虚拟节点2所分别对应的Pod网络之间是相互隔离的，通过将多个集群的Pod网络加上路由器三层打通实现了容器(即，Pod)的跨集群通信。

本发明所揭示的一种基于Kubernetes集群的容器通信方法，通过获取Kubernetes集群中的各节点分别被纳管的对象以及SDN控制器被纳管的对象，以确定与Kubernetes集群适配的网络配置模式；基于适配的网络配置模式下所部署的虚拟路由器建立节点间的数据网络连接，以实现容器通信。根据Kubernetes集群各节点被纳管的对象以及SDN控制器被纳管的对象，以自动确定出适合当前状态的网络配置模式，以适应多样化场景下的网络部署，降低了用户的学习成本和运维复杂度。通过给虚拟节点添加内部管理网卡和数据网卡，实现了Kubernetes集群管理网络与数据网络的分离，相比于现有技术中CNI网络分离场景需要使用外部网卡的方式，不依赖于第三方插件，以保证了网络的隔离性和安全性。

另外，上述三种网络配置模式下，对容器之间的跨节点通信、容器与内部管理网络(即，api server)的通信、容器与虚拟节点之间的通信、主机与容器之间的通信以及容器的跨节点通信予以详细的网络部署方式，以弥补了现有技术中在不同的网络配置模式下对基础通信方式的缺乏，从而为相应的网络方案的落地和维护提供了保障。尤其容器与虚拟节点之间的通信，解决了现有技术中一些主流的网络插件只能提供容器之间或者容器与内部管理网络的通信所存在的不足，以提升了容器与云平台融合的网络灵活性。

同时，上述三种网络配置模式对管理网络和数据网络进行了分离和划分，有效地保障了网络间的隔离性，尤其在嵌套模式下，管理网络和数据网络都属于内部网络，有效地避免了类似Calico等网络插件管理网络和数据网络需要通过外网网络予以实现所带来的隔离不彻底和安全性等问题。

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

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

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

Claims (10)

1.一种基于Kubernetes集群的容器通信方法，其特征在于，包括：

获取Kubernetes集群中的各节点分别被纳管的对象以及SDN控制器被纳管的对象，以确定与所述Kubernetes集群适配的网络配置模式；

基于所述适配的网络配置模式下所部署的虚拟路由器建立节点间的数据网络连接，以实现容器通信。

2.根据权利要求1所述的基于Kubernetes集群的容器通信方法，其特征在于，所述Kubernetes集群中的各节点包括控制节点和业务节点；所述被纳管的对象包括物理节点或者虚拟节点。

3.根据权利要求2所述的基于Kubernetes集群的容器通信方法，其特征在于，所述各节点分别被纳管的对象由各节点分别对应的网络接口信息以及设备所属值予以确定，所述SDN控制器被纳管的对象由SDN控制器所存储的网络接口信息予以确定。

4.根据权利要求3所述的基于Kubernetes集群的容器通信方法，其特征在于，所述网络配置模式包括：嵌套模式、非嵌套模式以及混合模式；

其中，在所述嵌套模式下，Kubernetes集群中的各节点部署于虚拟节点中，并在虚拟节点所在的物理节点内部署SDN控制器；在非嵌套模式下，Kubernetes集群中的各节点部署于物理节点或者虚拟节点中，在所述物理节点和虚拟节点内部署独立于Kubernetes集群的SDN控制器；在混合模式下，控制节点部署于虚拟节点中，将虚拟节点所在的物理节点作为计算节点，并将计算节点作为Kubernetes集群的业务节点，在物理节点内部署独立于虚拟节点的SDN控制器。

5.根据权利要求4所述的基于Kubernetes集群的容器通信方法，其特征在于，所述确定与所述Kubernetes集群适配的网络配置模式具体为：

对控制节点与业务节点分别对应的网络接口信息在SDN控制器中执行查询操作，并查询控制节点和业务节点分别对应的设备所属值，以确定网络配置模式；

若SDN控制器中存储控制节点和业务节点分别对应的网络接口信息，且控制节点和业务节点分别对应的设备所属值的逻辑定义为虚拟节点，则将网络配置模式确定为嵌套模式；

若SDN控制器中存储控制节点和业务节点分别对应的网络接口信息，且控制节点和业务节点分别对应的设备所属值的逻辑定义为物理节点，则将网络配置模式确定为非嵌套模式；

若SDN控制器中仅存储控制节点对应的网络接口信息，且控制节点的设备所属值为虚拟节点，业务节点对应的网络接口信息不存在于SDN控制器中，业务节点内部署SDN控制器，则将网络配置模式确定为混合模式。

6.根据权利要求5所述的基于Kubernetes集群的容器通信方法，其特征在于，所述网络接口信息包括：与控制节点或者业务节点中的容器对应的网卡；

将所述网卡加入虚拟路由器中，并建立与接入数据网络的Tap端口之间的映射关系。

7.根据权利要求4所述的基于Kubernetes集群的容器通信方法，其特征在于，在所述嵌套模式下，虚拟路由器独立部署于虚拟节点所在的物理节点；在所述非嵌套模式下，虚拟路由器分别部署于控制节点和业务节点；在所述混合模式下，虚拟路由器独立部署于虚拟节点所在的物理节点。

8.根据权利要求6所述的基于Kubernetes集群的容器通信方法，其特征在于，所述容器将流量引流至对应的虚拟路由器，虚拟路由器之间通过overlay网络实现通信，以实现容器基于所述映射关系形成跨节点或者跨容器的通信。

9.根据权利要求8所述的基于Kubernetes集群的容器通信方法，其特征在于，还包括：

由第一节点中的容器将流量引流至第一节点对应的虚拟路由器中，所述第一节点对应的虚拟路由器通过所述overlay网络将流量转发至第二节点对应的虚拟路由器中，所述第二节点对应的虚拟路由器将所述流量引流至第二节点中的容器；

其中，所述第一节点和第二节点为控制节点、业务节点、物理节点或者虚拟节点。

10.根据权利要求1所述的基于Kubernetes集群的容器通信方法，其特征在于，还包括：

创建Pod网络、Service网络以及内部管理网络，通过NetworkPolicy网络策略建立所述Pod网络与所述内部管理网络的通信连接，以通过所述通信连接实现所述Pod网络与所述Service网络的通信。

Images