CN116132435A - 一种容器云平台的双栈跨节点通信方法和*** - Google Patents
一种容器云平台的双栈跨节点通信方法和*** Download PDFInfo
- Publication number
- CN116132435A CN116132435A CN202310135077.9A CN202310135077A CN116132435A CN 116132435 A CN116132435 A CN 116132435A CN 202310135077 A CN202310135077 A CN 202310135077A CN 116132435 A CN116132435 A CN 116132435A
- Authority
- CN
- China
- Prior art keywords
- node
- network
- container
- network card
- cloud platform
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/08—Protocols specially adapted for terminal emulation, e.g. Telnet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请涉及云原生技术领域,提供了一种容器云平台的双栈跨节点通信方法和***。该方法中:CNI插件通过边界网关协议获取容器云平台的网络信息;其中,网络信息包括容器云平台中所有节点的节点网卡的网络信息,以及各节点中的所有容器组的网络信息;将网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组;其中,第一容器组部署在第一节点中,第二容器组部署在第二节点中,报文支持的网络协议与第二节点的节点网卡支持的网络协议不同。由此,第一容器组发出的报文能够经由支持不同网络协议的节点网卡传输至另一节点中的第二容器组,以突破网络协议带来的限制。
Description
技术领域
本申请涉及云原生技术领域,特别涉及一种容器云平台的双栈跨节点通信方法、***、计算机可读存储介质和电子设备。
背景技术
目前,Kubernetes集群的网络虚拟化通常由CNI(Container Network Interface,容器网络接口)插件实现,常见的CNI插件包括Calico,Cilium,MacVlan等。
使用CNI插件实现容器组(Pod)之间通信的过程需要以互联网通信协议为基础,传统的互联网通信协议为互联网协议第4版(Internet Protocol Version 4,IPv4),然而由于其存在诸多问题,互联网协议第6版(Internet Protocol Version 6,IPv6)正在逐步取代IPv4网络协议。可以理解,这个逐步取代的过程是一个循序渐进的过程,因此,在相当一段时间内IPv4和IPv6两种网络协议会共存在一个Kubernetes集群中,这就要求CNI插件同时支持IPv4和IPv6两种网络协议类型。
以Calico为例,Kubernetes集群中部署的Calico通常运行在Overlay模式下,Overlay网络则是建立在底层物理网络(Underlay网络)之上的逻辑网络,Kubernetes集群通过Overlay网络实现控制与转发的分离,从而实现物理网络的虚拟化。根据采用的隧道技术不同,Overlay网络又具体分为IPIP模式与VXLAN模式,其中,IPIP模式尚未支持双栈跨节点通信,新版本的Calico在VXLAN模式下能够同时支持IPv4和IPv6的双栈跨节点通信。
然而,要让运行在VXLAN模式下新版本的Calico能够同时支持IPv4和IPv6的双栈跨节点通信,节点网卡需要同时支持IPv4和IPv6两种网络协议,在节点网卡仅支持IPv4网络协议的情况下,仍然无法实现节点上的容器组的双栈跨节点通信,适用性较差。
因此,需要提供一种针对上述现有技术不足的改进技术方案。
发明内容
本申请的目的在于提供一种容器云平台的双栈跨节点通信方法、***、计算机可读存储介质和电子设备,以解决或缓解上述现有技术中存在的问题。
为了实现上述目的,本申请提供如下技术方案:
本申请提供了一种容器云平台的双栈跨节点通信方法,所述容器云平台包括多个节点,每个所述节点中部署有CNI插件,且所述CNI插件运行在VXLAN模式下,所述方法应用于任一所述CNI插件,包括:
通过边界网关协议获取所述容器云平台的网络信息;
其中,所述网络信息包括所述容器云平台中所有所述节点的节点网卡的网络信息,以及各所述节点中的所有容器组的网络信息;
将所述网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一所述节点中每个所述VXLAN虚拟网卡支持不同的网络协议;
所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组;
其中,所述第一容器组部署在第一节点中,所述第二容器组部署在第二节点中,所述报文支持的网络协议与所述第二节点的节点网卡支持的网络协议不同。
在一种可能的实现中,在所述通过边界网关协议获取所述容器云平台的网络信息之前,还包括:
各所述节点中部署的所述CNI插件获取所述容器云平台中所有所述节点的信息,并根据所有所述节点的信息,在各所述节点中部署边界网关协议的客户端组件;
各所述节点中部署的所述CNI插件对所述边界网关协议的客户端组件进行配置,以使任意两个所述节点中的所述边界网关协议的客户端组件能够相互通信。
在一种可能的实现中,还包括:
响应于所述容器云平台新增节点,在所述新增节点中部署所述CNI插件;
所述新增节点中部署的CNI插件在所述新增节点中部署所述边界网关协议的客户端组件,并对所述新增节点中的所述边界网关协议的客户端组件进行配置,以使所述新增节点中部署的所述边界网关协议的客户端组件能够与任一现有节点中的所述边界网关协议的客户端组件相互通信。
在一种可能的实现中,在所述通过边界网关协议获取所述容器云平台的网络信息之前,还包括:
所述CNI插件获取所在节点中所有容器组使用的网络协议的类型;
所述CNI插件根据所在节点中所有容器组使用的网络协议的类型,创建对应的所述VXLAN虚拟网卡。
在一种可能的实现中,所述通过边界网关协议获取所述容器云平台的网络信息,具体为:
各所述边界网关协议的客户端组件收集所在节点中的所有容器组的网络信息;
将收集到的所述所在节点中的节点网卡的网络信息和所有容器组的网络信息以广播的形式发送给所述容器云平台中其他所有节点中的边界网关协议的客户端组件,以使每个所述边界网关协议的客户端组件获知所述容器云平台中所有节点的节点网卡的网络信息和所有容器组的网络信息。
在一种可能的实现中,所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组之前,还包括:
所述第一容器组将所述报文发送至目标VXLAN虚拟网卡的发送端;所述目标VXLAN虚拟网卡支持的网络协议与所述报文支持的网络协议相同;
所述目标VXLAN虚拟网卡根据所述报文的目的地址和所述网络信息,确定所述报文的接收方为所述第二容器组,并确定所述第二容器组所在的所述第二节点的节点网卡支持的网络协议。
在一种可能的实现中,所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组,具体为:
所述目标VXLAN虚拟网卡的发送端对所述报文进行封装,以将所述第二节点的节点网卡的网络地址添加为所述报文的外层目的地址,将所述VXLAN虚拟网卡的接收端对应的端口号添加为所述外层目的地址的端口号;
所述VXLAN虚拟网卡的发送端基于所述外层目的地址和所述外层目的地址的端口号,将所述报文经由所述第二节点的节点网卡发送至所述VXLAN虚拟网卡的接收端,以由所述VXLAN虚拟网卡的接收端对所述报文进行拆封,并将拆封后的报文发送至所述第二容器组。
本申请实施例提供一种容器云平台的双栈跨节点通信***,所述容器云平台包括多个节点,每个所述节点中部署有CNI插件,且所述CNI插件运行在VXLAN模式下,包括:
获取单元,配置为通过边界网关协议获取所述容器云平台的网络信息;
其中,所述网络信息包括所述容器云平台中所有所述节点的节点网卡的网络信息,以及各所述节点中的所有容器组的网络信息;
写入单元,配置为将所述网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一所述节点中每个所述VXLAN虚拟网卡支持不同的网络协议;
发送单元,配置为所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组;
其中,所述第一容器组部署在第一节点中,所述第二容器组部署在第二节点中,所述报文支持的网络协议与所述第二节点的节点网卡支持的网络协议不同。
本申请实施例还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时,实现如上任一所述的容器云平台的双栈跨节点通信方法。
本申请实施例还提供一种电子设备,包括:存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序,所述处理器执行所述程序时实现如上任一所述的容器云平台的双栈跨节点通信方法。
有益效果:
本申请的技术方案中,容器云平台中包括多个节点,每个节点中均部署有CNI插件,该CNI插件运行在VXLAN模式下,该技术方案由任一CNI插件执行,通过边界网关协议(Border Gateway Protocol,以下简称BGP路由协议)获取容器云平台的网络信息,其中,网络信息既包括容器云平台中所有节点的节点网卡的网络信息,也包括各节点中的所有容器组的网络信息;将网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一节点中每个VXLAN虚拟网卡支持不同的网络协议;VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组;其中,第一容器组部署在第一节点中,第二容器组部署在第二节点中,报文支持的网络协议与第二节点的节点网卡支持的网络协议不同。由于利用BGP路由协议能够获取所有节点的节点网卡的网络信息和所有容器组的网络信息,也即不管各个容器组之间通信使用的网络协议与各个节点网卡支持的网络协议是否相同,BGP路由协议均能够正确获取相应的网络信息,进而能够将这些网络信息写入所在节点的VXLAN虚拟网卡中,使得第一容器组发出的报文支持的网络协议(比如该报文支持IPv6协议)与第二节点的节点网卡支持的网络协议(比如IPv4协议)不同时,VXLAN虚拟网卡基于所写入的网络信息仍然能够对该报文进行正确地封装,并将封装后的报文经由第二节点的节点网卡发送至第二容器组。该方案中,使用BGP路由协议实现网络信息的跨节点传输,破除了运行在VXLAN模式下的CNI插件不能使用BGP路由协议的技术偏见。同时,对于节点网卡仅支持IPv4协议的节点,无需对节点网卡进行改造升级,即可让节点上部署的各个容器组之间实现IPv4和IPv6的双栈跨节点通信,降低了成本。
附图说明
构成本申请的一部分的说明书附图用来提供对本申请的进一步理解,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。其中:
图1为相关技术提供的Calico在VXLAN模式下实现双栈跨节点通信的逻辑示意图;
图2为根据本申请的一些实施例提供的容器云平台的双栈跨节点通信方法的逻辑示意图;
图3为根据本申请的一些实施例提供的容器云平台的双栈跨节点通信方法的流程示意图;
图4为根据本申请的一些实施例提供的BIRD组件对所在节点的网络信息进行收集的结果示意图;
图5为根据本申请的一些实施例提供的容器云平台的双栈跨节点通信***的结构示意图;
图6为根据本申请的一些实施例提供的电子设备的结构示意图;
图7为根据本申请的一些实施例提供的电子设备的硬件结构图。
具体实施方式
下面将参考附图并结合实施例来详细说明本申请。
各个示例通过本申请的解释的方式提供而非限制本申请。实际上,本领域的技术人员将清楚,在不脱离本申请的范围或精神的情况下,可在本申请中进行修改和变型。例如,示为或描述为一个实施例的一部分的特征可用于另一个实施例,以产生又一个实施例。因此,所期望的是,本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。
本申请实施例所述双栈,指的是能够同时支持IPv4和IPv6两种协议栈进行通信。
本申请所述容器云平台,是依靠容器技术、结合云原生技术,采用容器、容器编排、服务网格、微服务等技术构建的一种轻量化云平台,Kubernetes集群是应用最广的容器云平台之一。Kubernetes集群是部署有Kubernetes***的集群,是Google开源的容器编排引擎,用于管理容器云平台中多个主机上容器化应用实例,Kubernetes集群通常包括多个节点(Node),每个节点中部署有多个容器组(Pod),容器组中运行有业务应用,容器组之间通过虚拟化网络进行通信。
SDN(Software Defined Network,软件定义网络)即软件定义虚拟网络,是在物理网络(包括互联网和局域网)基础之上,采用Multi code packet encryption技术、Multilayered技术、Network Slicing技术、DLT技术、Next-Hops技术等技术,快速实现基于互联网(Internet)的点对点、点对网、网对网的安全私有虚拟网络搭建,完成人与物的可靠、高速、安全、互利连接,保证数据能够快速、准确、安全的从生产者抵达指定的消费者。
与依赖物理基础设施(如交换机和路由器)来建立连接并正常运行的传统网络相比,SDN网络基于软件搭建,通过虚拟化整个网络,创建物理网络的抽象版本,容器云平台使用SDN网络能够将网络和计算资源更加紧密地联系起来并实现有效控制,自由扩展、灵活组网,轻松搭建私有网络、组件服务集群,以更高性价比扩容企业网络、提升运维效果、确保服务稳定。
SDN网络包括物理网络和虚拟网络两个部分,一些场景中,物理网络又称为Underlay网络,虚拟网络是建立在Underlay网络上的逻辑网络,又称为Overlay网络。而Kubernetes集群通常运行在Overlay网络,以支持集群中各业务***的动态伸缩。
在容器云平台中,Kubernetes集群包括多个节点,每个节点中部署有多个容器组,且每个节点中部署有CNI插件。每当有新的容器组被创建,由容器组所在节点的Kubelet组件调用CNI插件为容器组分配IP地址,不同容器组之间可以使用IP地址进行相互通信。
也就是说,目前,容器云平台的网络虚拟化通常由CNI插件实现。需要说明的是,CNI规范,是一组用于配置Linux容器网络接口的规范和库,其包括网络资源分配接口和网络资源释放接口。CNI插件是一组实现CNI规范的程序,用于在容器组创建时为其分配IP地址等网络资源,以及在容器组被删除时释放其占用的IP地址等网络资源。在容器云平台中,CNI插件负责将网络接口连接到容器网络的命名空间、对节点进行必要的更改、为网络接口分配IP以及为其设置路由。
Calico是一套开源的网络和网络安全方案,用于容器、虚拟机、宿节点之间的网络连接,具有完整的网络策略支持能力,能够兼容CNI规范,也是一种常见的CNI插件,常被用于对容器云平台进行网络配置和管理。
Calico支持两种网络模式,分别是Overlay模式和Underlay模式,其中,在Underlay模式下,各个节点上的容器组直接物理网络进行通信;Overlay模式下,各个节点上的容器组通过虚拟网络进行通信。根据所使用的隧道技术不同,Calico的Overlay模式又具体分为IPIP模式与VXLAN(Virtual Extensible LAN,虚拟扩展局域网)模式,且IPIP模式与VXLAN模式不能同时使用。
当Calico运行在IPIP模式下时,可以使用BGP路由协议在节点之间路由数据包。其中,BGP路由协议是一种自治***的路由协议,能够将节点作为虚拟路由器来实现集群内容器之间的网络访问。目前,在IPIP模式下各个节点上的容器组只能通过IPv4协议进行跨节点通信,尚未支持IPv6协议。
新版本的Calico在VXLAN模式下能够同时支持IPv4和IPv6的双栈跨节点通信。其中,VXLAN是一种隧道技术,其能够在三层网络的基础上建立二层以太网网络隧道,从而实现跨地域的二层互连。VXLAN采取了将原始以太网报文封装在UDP(User DatagramProtocol,用户数据报协议)数据包里的封装格式,将原来的二层数据帧加上VXLAN头部一起封装在一个UDP数据包里。VXLAN头部包含有一个VXLAN标识(即VNI,VXLAN NetworkIdentifier),只有在同一个VXLAN中的节点之间才能相互通信。具体地,VXLAN通过VTEP(VXLAN Tunnel Endpoints,也叫做VXLAN隧道端点,即VXLAN隧道的起点和终点)对原始以太网报文进行封装和拆封,即将原始报文“变身”并加以“包装”,使其可以在承载网络(比如IP网络)上传输。从节点的角度看,就好像原始报文的起点和终点之间,有一条直通的链路一样。而这个看起来直通的链路,就是“隧道”。“VXLAN隧道”便是用来传输经过VXLAN封装的报文的,它是建立在两个VTEP之间的一条虚拟通道。VTEP会将原始报文封装成一个新的UDP报文,并使用物理网络的IP和MAC地址作为外层头,对网络中的其他设备只表现为封装后的参数。也就是说,网络中的其他设备看不到原始报文。
需要说明的是,现有技术中,当Calico运行在IPIP模式下时,可以使用BGP路由协议在节点之间路由数据包,而当Calico运行在VXLAN模式下时,并没有使用BGP路由协议在节点之间路由数据包。因此,为了实现双栈跨节点通信Calico需要运行在VXLAN模式下。旧版本的Calico运行在VXLAN模式下时,只能支持IPv4的跨节点通信,虽然新版本的Calico已经支持VXLAN模式下的双栈跨节点通信,但是,其适用范围仍存在一定的局限性。
具体地,图1为现有技术中在VXLAN模式下Calico进行双栈跨节点通信实现逻辑示意图,如图1所示,Kubernetes集群包括多个节点,比如第一节点和第二节点。其中,第一节点上部署有Pod A,第二节点上部署有Pod B,Pod A、Pod B中运行的组件均同时支持IPv4和IPv6网络协议。
每个节点上还部署有Calico,Calico运行在VXLAN模式下时,能够同时支持IPv4和IPv6的双栈跨节点通信,也即,位于第一节点中的Pod A可以分别使用IPv4网络协议和IPv6网络协议向位于第二节点中的Pod B发送通信数据包(也称为报文)。
具体来说,在将Calico部署在Kubernetes集群中后,即在每个节点中创建VXLAN虚拟网卡(即VXLAN隧道端点VTEP),包括支持IPv4网络协议的VXLAN IPv4虚拟网卡和支持IPv6网络协议的VXLAN IPv6虚拟网卡。Calico通过对Kubernetes集群的API-Server组件进行监听,获取集群中所有容器组(包括但不限于所有Pod、所有节点的节点网卡)的网络信息,该网络信息的内容包括单不限于:IP地址和MAC地址相关信息。然后,Calico将获取的容器组网络信息按照所支持的网络协议类型,分别写入VXLAN IPv4虚拟网卡和VXLAN IPv6虚拟网卡。当集群中某个容器组的网络信息发生变化时,Calico通过对Kubernetes集群的API-Server组件的持续监听,对所有节点中的Calico虚拟网卡中记录的该容器组网络信息进行及时更新。
当位于第一节点中的Pod A向位于第二节点中的Pod B发出IPv6通信数据包时,第一节点中的Calico首先对通信数据包所使用的网络协议进行识别,在确定该通信数据包支持IPv6网络协议后,由第一节点中的VXLAN IPv6虚拟网卡对该通信数据包进行封装处理。
进一步地,VXLAN采用MAC-in-UDP的封装方式对该通信数据包进行封装,得到封装后的VXLAN报文。具体来说,VXLAN IPv6虚拟网卡对该通信数据包进行封装处理时,使用第一节点中的节点IPv6网卡(即第一节点中支持IPv6网络协议的节点网卡)的IPv6地址作为外层头的源IP地址,使用第二节点中的节点IPv6网卡(即第二节点中支持IPv6网络协议的节点网卡)的IPv6地址作为外层头的目的地址,将上述源IP地址和目的IP地址作为封装后的VXLAN报文的外层头对Pod A发送的IPv6通信数据包进行封装,以生成一个新的数据包(UDP数据包,即封装后的VXLAN报文)。接着,由第一节点中的VXLAN IPv6虚拟网卡将封装后的VXLAN报文先后经由第一节点中的节点IPv6网卡和第二节点中的节点IPv6网卡转发至第二节点中的VXLAN IPv6虚拟网卡,再由第二节点中的VXLAN IPv6虚拟网卡对其进行拆封,并将原始通信数据包发送至Pod B。
类似的,当位于第一节点中的Pod A向位于第二节点中的Pod B发出IPv4通信数据包,第一节点中的Calico首先对通信数据包所使用的网络协议进行识别,在确定该通信数据包支持IPv4网络协议后,由第一节点中的VXLAN IPv4虚拟网卡使用第一节点中的节点IPv4网卡(即第一节点中支持IPv4网络协议的节点网卡)的IPv4地址作为源IP地址,使用第二节点中的节点IPv4网卡(即第二节点中支持IPv4网络协议的节点网卡)的IPv4地址作为目的地址,使用上述源IP地址和目的IP地址作为外层头,对该通信数据包进行封装处理,得到封装后的VXLAN报文。然后,由第一节点中的VXLAN IPv4虚拟网卡将封装后的VXLAN报文先后经由第一节点中的节点IPv4网卡和第二节点中的节点IPv4网卡转发至第二节点中的VXLAN IPv4虚拟网卡,再由第二节点中的VXLAN IPv4虚拟网卡对封装后的通信数据包进行拆封,并将原始通信数据包发送至Pod B。
从上面的描述可知,现有技术中,要让运行在VXLAN模式下的Calico同时支持IPv4和IPv6的双栈跨节点通信,则需要发出访问的容器组所在的节点(比如Pod A所在的第一节点)和被访问容器组所在节点(比如Pod B所在的第二节点)的节点网卡都能够同时支持IPv4和IPv6的网络协议,即节点网卡需要包括节点IPv4网卡和节点IPv6网卡。
换句话说,如果被访问容器组所在节点的节点网卡只支持IPv4网络协议,那么发出访问的容器组只能使用IPv4网络协议的通信数据包与被访问的容器组进行通信,若发出访问的容器组使用IPv6网络协议的通信数据包与被访问的容器组进行通信,该通信数据包将无法到达被访问容器组。
申请人通过对Calico的运行原理进行深入分析后发现,上述问题产生的根本原因在于:即便Calico在每个节点中均创建了支持IPv4和IPv6的VXLAN虚拟网卡,即VXLAN IPv4虚拟网卡和VXLAN IPv6虚拟网卡,但是,如果被访问容器组所在节点的节点网卡只支持IPv4网络协议,Calico在将所有容器组的网络信息写入VXLAN IPv4虚拟网卡和VXLAN IPv6虚拟网卡时,只会将被访问容器组所在节点的节点网卡的IPv4网络信息写入VXLAN IPv4虚拟网卡,而由于被访问容器组所在节点的节点网卡不支持IPv6网络协议,也就没有IPv6网络信息,因此VXLAN IPv6虚拟网卡中不会被写入被访问容器组所在节点的节点网卡的任何网络信息。此时,如果发出访问的容器组使用IPv6通信数据包,该IPv6通信数据包将被发送至所在节点的VXLAN IPv6虚拟网卡,交由VXLAN IPv6虚拟网卡对其进行封装处理时,VXLANIPv6虚拟网卡中没有被访问容器组所在节点的节点网卡的任何网络信息,无法完成封装,进而导致该通信数据包无法到达被访问容器组。
为此,本申请提供一种容器云平台的双栈跨节点通信方法,该方法通过BGP路由协议获取容器云平台的网络信息(包括各节点的节点网卡的网络信息以及各节点中所有容器组的网络信息),然后将所获取的网络信息写入到VXLAN虚拟网卡中,使得每个VXLAN虚拟网卡均包含有各节点的节点网卡的网络信息以及各节点中所有容器组的网络信息,当第一容器组向第二容器组发出报文时,VXLAN虚拟网卡基于所获取的全量的网络信息,能够对报文进行正确的封装处理,最终通过第二节点的节点网卡将报文发送到第二容器组,从而解决了报文支持的网络协议与被访问容器组所在节点(第二节点)的节点网卡支持网络协议不同的情况下报文无法到达被访问容器组的问题。该技术方案提供了一种不同于现有的Calico双栈跨节点通信的技术实现思路,不仅破除了现有CNI组件运行在VXLAN模式下不能使用BGP路由协议的技术偏见,拓展了双栈跨节点通信技术方案的适用范围,而且不管报文支持的网络协议与节点网卡的网络协议是否相同均能够正常进行通信,提高了双栈跨节点通信的灵活性。
示例性方法
本申请实施例提供一种容器云平台的双栈跨节点通信方法,其中,容器云平台包括多个节点,每个节点中部署有CNI插件,且CNI插件运行在VXLAN模式下,该方法应用于任一CNI插件,如图2、图3、图4所示,包括:
步骤S101、通过边界网关协议获取容器云平台的网络信息。
其中,网络信息包括容器云平台中所有节点的节点网卡的网络信息,以及各节点中的所有容器组的网络信息。
基于前述说明可知,现有技术中,当发出访问的报文所采用的网络协议与被访问容器组所在节点的节点网卡支持的网络协议不相同时,由于原有的CNI插件(比如Calico)无法正确获取相应的网络信息并写入到与通信数据包所采用的网络协议对应的VXLAN虚拟网卡,致使该VXLAN虚拟网卡无法完成对报文的封装,最终导致报文无法正确发送到被访问容器组。也就是说,当发出访问的通信数据包所采用的网络协议与被访问容器组所在节点的节点网卡支持的网络协议不相同时,传统方法无法实现双栈跨节点通信的原因在于:发出访问的通信数据包无法完成封装,而通信数据包无法完成封装的根本原因在于缺失被访问容器组所在节点的网络信息,因此,各VXLAN虚拟网卡中需要存储有容器云平台全量的网络信息,包括节点网卡的网络信息和各节点中所有容器组的网络信息。
本申请实施例中,容器云平台的网络信息的获取不再由CNI插件通过API-Server组件收集,而是由BGP路由协议完成。具体地,在BGP路由协议中,所有的数据包均基于TCP会话传递,因此可以通过TCP会话来进行节点/容器组的发现及数据包的发送与确认,以获取到相应的网络信息。也就是说,本实施例摒弃了原有CNI插件收集网络信息的方式,利用BGP路由协议,通过TCP会话获取容器云平台的网络信息,包括容器云平台中所有节点的节点网卡的网络信息,以及各节点中的所有容器组的网络信息,以确保所得到的网络信息是容器云平台所有的网络信息,为VXLAN虚拟网卡进行数据包正确封装奠定基础。
BGP路由协议的具体执行需要由支持该协议的组件完成,为此,一些实施例中,在通过边界网关协议获取容器云平台的网络信息之前,还包括:各节点中部署的CNI插件获取容器云平台中所有节点的信息,并根据所有节点的信息,在各节点中部署边界网关协议的客户端组件;各节点中部署的CNI插件对边界网关协议的客户端组件进行配置,以使任意两个节点中的边界网关协议的客户端组件能够相互通信。
本申请实施例中,CNI插件获取的节点信息包括但不限于:节点的标识信息、节点的网络配置信息等。在容器云平台中,节点信息可以存储在节点对应的资源配置文件中,或者存储在分布式键值数据库中。CNI插件可以通过各个节点上部署的应用服务接口获取容器云平台中所有节点的信息。
比如在Kubernetes集群中,节点可以分为控制节点和工作节点,集群中所有节点的信息可以通过各节点对应的资源配置文件(如yaml格式文件或者json格式文件)存储在控制节点中,也可以统一存储在分布式键值数据库ETCD中。当CNI插件需要获取各个节点的信息时,可以通过访问控制节点上的API-Server组件提供的统一接口进行获取。
在获取所有节点的信息之后,CNI插件根据所有节点的信息,在每个节点中部署边界网关协议的客户端组件,以通过边界网关协议的客户端组件执行BGP路由协议获取容器云平台的网络信息。
需要说明的是,BGP路由协议执行的前提是能够发送/接收TCP数据包,因此,在部署边界网关协议的客户端组件之后,CNI插件还应根据所收集到的节点信息对边界网关协议的客户端组件进行相应的网络配置,以使得任意两个节点中的边界网关协议的客户端组件能够基于IP地址进行通信。
本申请实施例中,边界网关协议的客户端组件可以是任意支持BGP路由协议的组件,只要其能够实现基于BGP路由协议进行网络拓扑发现即可,本申请对边界网关协议的客户端组件具体的选型不作限定。
其中,BIRD(BIRD Internet Routing Daemon)是一款支持BGP路由协议的客户端组件,其可运行在Linux和其他类Unix***上的路由软件,本申请实施例中,以BIRD组件实现BGP路由协议的网络信息采集为例进行说明。
具体地,图2示出了本申请实施例提供的双栈跨节点通信场景,如图2所示,Pod A(第一容器组)部署在第一节点上,Pod B(第二容器组)部署在第二节点上,Pod A、Pod B均同时支持IPv4和IPv6网络协议,其中,第一节点的节点网卡可能仅支持IPv4网络协议,也可能同时支持IPv4和IPv6网络协议,但第二节点的节点网卡只支持IPv4网络协议,使得Pod A可能向Pod B发出IPv4网络协议的通信数据包,也可能向Pod B发出IPv6网络协议的通信数据包,但第一节点的节点网卡和第二节点的节点网卡之间只能传输IPv4网络协议的通信数据包。也就是说,Pod A发向Pod B的通信数据包使用的网络协议类型可能与第一节点、第二节点的节点网卡所支持的网络协议类型不同。应理解,图2中第一节点、第二节点的节点网卡仅支持的IPv4网络协议不应当理解为对本实施例的技术方案的限制,本实施例所提供的技术方案对Pod A和Pod B支持的网络协议、第一节点的节点网卡和第二节点的节点网卡支持的网络协议均不做限定。
作为一个示例,Pod A的网络信息可以包括如下内容:
default via 169.254.1.1dev eth0 169.254.1.1dev eth0 scope link#路由设置;
172.29.0.34/32#IPv4地址;
fdff:ffff:ffff:ffff:e994:41/128#IPV6地址;
00:00:ac:1d:00:22#MAC地址。
第一节点上的VXLAN虚拟网卡的网络信息可以包括如下内容:
172.28.5.0/32#VXLAN IPv4虚拟网卡的IP地址;
fdff:ffff:ffff:ffff:4:0:ab1e:1003#VXLAN IPv6虚拟网卡的IP地址;
66:15:a5:89:c8:a2#MAC地址。
第一节点的节点IPv4网卡的网络信息包括IPv4地址和MAC地址,在图2中未示出。
Pod B的网络信息可以包括如下内容:
default via 169.254.1.1dev eth0 169.254.1.1dev eth0 scope link#路由信息;
172.29.0.33/32#IPv4地址;
fdff:ffff:ffff:ffff:e994:40/128#IPv6地址;
00:00:ac:1d:00:21#MAC地址。
第二节点上的VXLAN虚拟网卡的网络信息可以包括如下内容:
172.28.0.32/32#VXLAN IPv4虚拟网卡的IP地址;
fdff:ffff:ffff:ffff:4:0:ab1e:1003#VXLAN IPv6虚拟网卡的IP地址;
66:44:90:94:b2:e9#MAC地址。
第一节点的节点IPv4网卡的网络信息包括IPv4地址和MAC地址,在图2中未示出。
在将CNI插件部署到Kubernetes集群后,CNI插件首先通过Kubernetes集群的API-Server组件进行监听,获取集群中所有节点的信息和所在节点中所有组件的网络信息,比如第一节点中的CNI插件需要获取第一节点和第二节点的节点标识信息、节点网卡的IP地址和MAC地址,Pod A的IPv4地址、IPv6地址、MAC地址,第二节点中的CNI插件需要获取第一节点和第二节点的节点标识信息、节点网卡的IP地址和MAC地址,Pod B的IPv4地址、IPv6地址、MAC地址等。然后,根据所有节点的信息,CNI插件在每个节点中部署BIRD组件,并对部署的每个BIRD组件进行配置,以使任意两个节点中的BIRD组件能够相互通信。此外,每个节点中的CNI插件在对所在节点中的BIRD组件进行配置时,还需要将所在节点中所有组件的网络信息写入该BIRD组件。任意两个节点中的BIRD组件相互进行通信,即可让每个BIRD组件获取所有节点中所有组件的网络信息。
也就是说,在部署和配置BIRD组件之后,一些实施例中,通过边界网关协议获取容器云平台的网络信息,具体为:各边界网关协议的客户端组件收集所在节点中的所有容器组的网络信息;将收集到的所在节点中的节点网卡的网络信息和所有容器组的网络信息以广播的形式发送给容器云平台中其他所有节点中的边界网关协议的客户端组件,以使每个边界网关协议的客户端组件获知容器云平台中所有节点的节点网卡的网络信息和所有容器组的网络信息。
具体地,每个节点中的各BIRD组件收集所在节点的节点网卡的网络信息以及所有容器组的网络信息,并以广播的形式发送给集群中其他所有节点上的BIRD组件,使得每个BIRD组件均能够获知集群中所有节点的节点网卡的网络信息以及各节点上所有容器组的网络信息。
举例来说,参见图4,BIRD组件所在节点的节点网卡的IP地址为10.6.158.150,该节点与另外两个节点的节点网卡IP地址分别为10.6.158.73、10.6.158.75,且该节点中的BIRD组件与集群中的其他节点中的BIRD组件采用全互联模式(Node-to-Node mesh),在全互联模式下,每个节点上的BIRD组件都与其他所有节点上的BIRD组件建立BGP连接,使得BIRD组件能够将所在节点的节点网卡的网络信息和所有容器组的网络信息广播至其他所有节点上的BIRD组件,实现网络信息的收集和跨节点传输。
现有的Calico只有在IPIP模式时才使用BGP路由协议,而通常认为运行在VXLAN模式下的Calico应通过API-Server组件获取网络信息,本实施例中,通过在每个节点中部署BIRD组件(即BGP的客户端),并通过配置实现不同节点中的BIRD组件之间的相互通信,能够将所在节点的节点网卡的网络信息和所在节点中所有容器组的网络信息传输至其他所有节点的BRID组件,从而破除了Calico运行在VXLAN模式下不能使用BGP路由协议的技术偏见,使用BGP路由协议实现了网络信息的跨节点传输。
此外,传统的VXLAN采用单播或洪泛的方法收集网络信息,当发出的通信数据包所支持的网络协议与被访问容器组所在节点的节点网卡支持的网络协议不相同,由于不同网络协议之间无法通信,单播或者洪泛方法无法到达被访问容器组所在节点,也就无法获取到被访问容器组所在节点的节点网卡的网络信息,进而导致被访问容器组所在节点的节点网卡的网络信息无法正确写入到VXLAN虚拟网卡,引起网络信息缺失。而本实施例中,BIRD组件通过TCP会话获取所有的网络信息,避免了单播或洪泛方法由于网络协议不同而无法获取所有网络信息的缺陷,提高了双栈跨节点通信稳定性和可靠性。
实际应用中,容器云平台的节点数量可能会发生变化,包括节点的新增或删除,为使新增节点上的容器组能够与原有节点上的容器组进行双栈跨节点通信,一些实施例中,该方法还包括:响应于容器云平台新增节点,在新增节点中部署CNI插件;新增节点中部署的CNI插件在新增节点中部署边界网关协议的客户端组件,并对新增节点中的边界网关协议的客户端组件进行配置,以使新增节点中部署的边界网关协议的客户端组件能够与任一现有节点中的边界网关协议的客户端组件相互通信。
具体地,通过Kubernetes集群的API-Server组件对节点变化事件进行监听,当检测到集群中出现新增节点时,先在新增节点上部署CNI插件,然后由CNI插件在新增节点上部署BIRD组件,并对新增节点中的BIRD组件进行配置,使其能够与任一现有节点中的BIRD组件相互通信。
现有技术中,对网络信息的更新以容器组为单位,也就是说,Calico为了对所记录的容器组的网络信息进行及时更新,需要对Kubernetes集群的API-Server组件进行持续监听和访问,而集群中容器组的变化较为频繁,使得其网络信息也需要频繁进行更新,进而给API-Server组件增加了较大的负担。本申请实施例中,以节点为单位进行网络信息的更新,只需由CNI插件监控节点的新增事件,并在新增节点中部署和配置BIRD组件,并借助BIRD组件之间的相互通信,让Kubernetes集群中新增节点中的BIRD组件获取所有节点中所有组件的网络信息,让Kubernetes集群中所有现有节点中的BIRD组件获取新增节点中所有组件的网络信息,从而无需访问集群的API-Server组件,降低了API-Server组件的访问压力。
步骤S102、将网络信息写入所在节点中的至少一个VXLAN虚拟网卡中。
其中,同一节点中每个VXLAN虚拟网卡支持不同的网络协议。
具体地,在每个BIRD组件获知容器云平台中所有节点的节点网卡的网络信息和所有容器组的网络信息之后,将容器云平台中所有节点的节点网卡的网络信息和所有容器组的网络信息写入到VXLAN虚拟网卡。其中,每个节点上的VXLAN虚拟网卡可以有多个,同一节点中每个VXLAN虚拟网卡支持不同的网络协议,BIRD组件将所有容器云平台所有容器组的网络信息写入到所有的VXLAN虚拟网卡中,使得每个VXLAN虚拟网卡中均保存有容器云平台全量的网络信息。
比如,在图2所示场景中,BIRD组件会将第一节点的节点网卡的网络信息、第二节点的节点网卡的网络信息、Pod A的网络信息、Pod B的网络信息写入到所有VXLAN虚拟网卡,包括将Pod B的网络信息和第二节点的节点网卡的IPv4网络信息写入VXLAN IPv4虚拟网卡。也就是说,不管VXLAN虚拟网卡是VXLAN IPv4虚拟网卡,还是VXLAN IPv6虚拟网卡,BIRD组件都会写入容器云平台中所有节点的节点网卡的网络信息和所有容器组的网络信息。
可以理解,VXLAN虚拟网卡实际上是VXLAN隧道的端点(VTEP),其主要作用是对容器组之间的通信数据包进行封装/拆封,即VXLAN隧道的起始端点在容器组发出的通信数据包之外添加所在节点的节点网卡的网络信息作为源IP地址,被访问容器组所在节点的节点网卡的网络信息作为目的IP地址,由此形成一个新的数据包,也就是说,如果VXLAN虚拟网卡中没有记录被访问容器组所在节点的节点网卡的网络信息,将会导致VXLAN虚拟网卡封装失败。因此,为保证通信数据包正确封装,需要将BIRD组件所收集到的容器云平台全量的网络信息写入到所有的VXLAN虚拟网卡中,这样,无论被访问容器组所在节点的节点网卡支持何种网络协议类型,均能够基于被访问容器组所在节点的节点网卡的网络信息进行通信数据包的封装,进而将其传输到被访问容器组。
默认情况下CNI插件在各个节点上同时创建VXLAN IPv4虚拟网卡和VXLAN IPv6虚拟网卡,使得同一节点中每个VXLAN虚拟网卡支持不同的网络协议,以基于不同的网络协议采用不同的VXLAN虚拟网卡对通信数据包进行处理。
然而,生产环境中,存在一些节点中的全部容器组仅使用IPv4网络协议进行通信,或者节点中的全部容器组仅使用IPv6网络协议进行通信的情况,此时,如果在该节点上既创建了支持IPv4的VXLAN IPv4虚拟网卡,又创建了支持IPv6的VXLAN IPv6虚拟网卡,维护VXLAN虚拟网卡会造成不必要的资源浪费,为此,一些实施例中,在通过边界网关协议获取容器云平台的网络信息之前,还包括:CNI插件获取所在节点中所有容器组使用的网络协议的类型;CNI插件根据所在节点中所有容器组使用的网络协议的类型,创建对应的VXLAN虚拟网卡。
本申请实施例中,容器组的网络信息中包括所支持的网络协议的类型,CNI插件在获取所在节点中所有容器组使用的网络协议的类型之后,创建对应的VXLAN虚拟网卡。
具体来说,如果CNI插件发现所在节点的容器组全部使用IPv6网络协议(或IPv4网络协议)进行通信,则只需要创建VXLAN IPv6虚拟网卡(或VXLAN IPv4虚拟网卡)。如果CNI插件发现所在节点的容器组有的使用IPv6网络协议,有的使用IPv4网络协议进行通信,或者存在同时支持IPv4和IPv6网络协议的容器组,则CNI插件同时创建VXLAN IPv4虚拟网卡和VXLAN IPv6虚拟网卡。由此,根据所在节点容器组所使用的网络协议类型确定需要创建的VXLAN虚拟网卡,减轻了VXLAN虚拟网卡的维护工作量。
进一步地,在确定需要创建的VXLAN虚拟网卡后,CNI插件基于各节点的节点网卡的网络信息和各节点上所有容器组的网络信息创建相应的VXLAN虚拟网卡,其中,创建VXLAN虚拟网卡的参数包括但不限于:VXLAN虚拟网卡的IP地址、所属的VXLAN标识、与容器组的网络信息之间的映射关系(该映射关系用于表征VXLAN虚拟网卡用于处理哪些容器组发送的通信数据包)等。
步骤S103、VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组。
其中,第一容器组部署在第一节点中,第二容器组部署在第二节点中,报文支持的网络协议与第二节点的节点网卡支持的网络协议不同。
本申请实施例中,由于VXLAN虚拟网卡(包括VXLAN IPv4虚拟网卡和VXLAN IPv6虚拟网卡)中存储的网络信息是由BIRD组件写入的整个集群的所有网络信息,因此,即使是报文支持的网络协议与第二节点的节点网卡支持的网络协议不同,VXLAN虚拟网卡仍然能够基于BIRD组件写入的网络信息,使用第二节点的节点网卡的网络信息对不同网络协议的报文进行封装处理,最终将该报文经由第二节点的节点网卡正确发送到Pod B中,实现在报文支持的网络协议与第二节点的节点网卡支持的网络协议不同的情况下双栈跨节点通信。
一些实施例中,VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组之前,还包括:第一容器组将报文发送至目标VXLAN虚拟网卡的发送端;目标VXLAN虚拟网卡支持的网络协议与报文支持的网络协议相同;目标VXLAN虚拟网卡根据报文的目的地址和网络信息,确定报文的接收方为第二容器组,并确定第二容器组所在的第二节点的节点网卡支持的网络协议。
基于前述说明可知,VXLAN是一种隧道技术,在接收到Pod A向Pod B发送的报文之后,VXLAN需要通过VTEP对报文进行封装,使其变成可以在承载网络上传输的数据包。具体地,当位于第一节点的Pod A需要使用IPv6网络协议向位于第二节点的Pod B发送报文时,CNI插件首先从第一节点的VXLAN虚拟网卡中选择支持的网络协议与报文使用的网络协议相同的VXLAN虚拟网卡(即目标VXLAN虚拟网卡),用于对该报文进行封装。然后,CNI插件将报文通过虚拟设备(Veth)从Pod A传输到目标VXLAN虚拟网卡的发送端以对其进行封装。由于报文支持的网络协议(IPv6)与第二节点的节点网卡支持的网络协议(IPv4)可能相同,也可能不同,在目标VXLAN虚拟网卡封装前,CNI插件还对该报文的接收方进行识别,若检测到该报文的目的地址是Pod B的网络地址,则可以根据Pod B的配置信息确定其位于第二节点中,进一步确定第二节点的节点网卡支持的网络协议类型是IPv4网络协议。也就是说,目标VXLAN虚拟网卡可以是VXLAN IPv4虚拟网卡,也可以是VXLAN IPv6虚拟网卡,具体需要根据报文所使用的网络协议类型来确定。由于目标VXLAN虚拟网卡中存储有整个集群的所有网络信息,因此在目标VXLAN虚拟网卡对报文进行封装的过程中,其外层头既可以使用IPv4网络地址,也可以使用IPv6网络地址,具体支持的网络协议类型取决于第二节点的节点网卡支持的网络协议类型。
在确定Pod B所在的第二节点的节点网卡所支持的网络协议类型后,目标VXLAN虚拟网卡即可开始对Pod A进行封装处理,一些实施例中,VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组,具体为:目标VXLAN虚拟网卡的发送端对报文进行封装,以将第二节点的节点网卡的网络地址添加为报文的外层目的地址,将VXLAN虚拟网卡的接收端对应的端口号添加为外层目的地址的端口号;VXLAN虚拟网卡的发送端基于外层目的地址和外层目的地址的端口号,将报文经由第二节点的节点网卡发送至VXLAN虚拟网卡的接收端,以由VXLAN虚拟网卡的接收端对报文进行拆封,并将拆封后的报文发送至第二容器组。
本申请实施例中,Pod A使用IPv6网络协议向Pod B发送报文,根据报文使用的网络协议的类型可以确定,使用第一节点上的VXLAN IPv6虚拟网卡作为目标VXLAN虚拟网卡,对报文进行封装处理。在CNI插件确定第二节点的节点网卡使用的是IPv4网络协议后,第一节点上的VXLAN IPv6虚拟网卡使用第一节点中节点IPv4网卡的IPv4地址作为报文的外层源IP地址,使用第二节点中节点IPv4网卡的IPv4地址作为外层目的IP地址,并将第二节点上的VXLAN IPv6虚拟网卡的接收端对应的端口号添加为外层目的地址的端口号,将报文封装成一个新的UDP数据包。接着,由第一节点中的目标VXLAN虚拟网卡将封装后的报文先后经由第一节点中的节点IPv4网卡和第二节点中的节点IPv4网卡转发到第二节点上的VXLANIPv6虚拟网卡的接收端,以由第二节点上的VXLAN IPv6虚拟网卡的接收端对报文进行拆封,并将拆封后的报文发送至Pod B。这样,在第二节点的节点网卡仅支持IPv4网络协议的情况下仍然能够使用第二节点的节点网卡的IPv4地址对报文进行正确封装,无需对第二节点的节点网卡进行升级,即可让第二节点中部署的容器组实现双栈跨节点通信,降低了成本。
综上所述,本申请实施例中,容器云平台中包括多个节点,每个节点中均部署有CNI插件,该CNI插件运行在VXLAN模式下,本申请实施例提供的技术方案由任一CNI插件执行,通过边界网关协议获取容器云平台的网络信息,该网络信息既包括容器云平台中所有节点的节点网卡的网络信息,也包括各节点中的所有容器组的网络信息;然后将网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;且同一节点中每个VXLAN虚拟网卡支持不同的网络协议;VXLAN虚拟网卡基于上述网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组;其中,第一容器组部署在第一节点中,第二容器组部署在第二节点中,报文支持的网络协议与第二节点的节点网卡支持的网络协议不同。由于利用BGP路由协议能够获取所有节点的节点网卡的网络信息和所有容器组的网络信息,并将所获取的网络信息写入所在节点的VXLAN虚拟网卡中,在第一容器组发出的报文支持的网络协议与第二节点的节点网卡支持的网络协议不相同的情况下,VXLAN虚拟网卡基于所写入的网络信息仍然能够对该报文进行正确地封装,并将封装后的报文经由第二节点的节点网卡发送至第二容器组。
本申请实施例中,使用BGP路由协议实现网络信息的跨节点传输,破除了运行在VXLAN模式下的CNI插件不能使用BGP路由协议的技术偏见。同时,对于节点网卡仅支持IPv4网络协议的节点,无需对节点网卡进行改造升级,即可让节点上部署的各个容器组之间实现IPv4和IPv6的双栈跨节点通信,降低了成本。
示例性***
本申请实施例提供一种容器云平台的双栈跨节点通信***,如图5所示,容器云平台包括多个节点,每个节点中部署有CNI插件,且CNI插件运行在VXLAN模式下,该容器云平台的双栈跨节点通信***还包括:获取单元501、写入单元502和发送单元503。其中:
获取单元501,配置为通过边界网关协议获取容器云平台的网络信息。
其中,网络信息包括容器云平台中所有节点的节点网卡的网络信息,以及各节点中的所有容器组的网络信息。
写入单元502,配置为将网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一节点中每个VXLAN虚拟网卡支持不同的网络协议。
发送单元503,配置为VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组。
其中,第一容器组部署在第一节点中,第二容器组部署在第二节点中,报文支持的网络协议与第二节点的节点网卡支持的网络协议不同。
本申请实施例提供的容器云平台的双栈跨节点通信***,能够实现上述任一实施例提供的容器云平台的双栈跨节点通信方法的流程、步骤,并达到相同的技术效果,在此不再一一赘述。
示例性设备
图6为根据本申请的一些实施例提供的电子设备的结构示意图;如图6所示,该电子设备包括:
一个或多个处理器601;
计算机可读介质,可以配置为存储一个或多个程序602,一个或多个处理器601执行一个或多个程序602时,实现如下步骤:通过边界网关协议获取容器云平台的网络信息;其中,网络信息包括容器云平台中所有节点的节点网卡的网络信息,以及各节点中的所有容器组的网络信息;将网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一节点中每个VXLAN虚拟网卡支持不同的网络协议;VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组;其中,第一容器组部署在第一节点中,第二容器组部署在第二节点中,报文支持的网络协议与第二节点的节点网卡支持的网络协议不同。
图7为根据本申请的一些实施例提供的电子设备的硬件结构;如图7所示,该电子设备的硬件结构可以包括:处理器701、通信接口702、计算机可读介质703和通信总线704。
其中,处理器701、通信接口702、计算机可读存储介质703通过通信总线704完成相互间的通信。
可选地,通信接口702可以为通信模块的接口,如GSM模块的接口。
其中,处理器701具体可以配置为:通过边界网关协议获取容器云平台的网络信息;其中,网络信息包括容器云平台中所有节点的节点网卡的网络信息,以及各节点中的所有容器组的网络信息;将网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一节点中每个VXLAN虚拟网卡支持不同的网络协议;VXLAN虚拟网卡基于网络信息,将第一容器组发出的报文经由第二节点的节点网卡发送至第二容器组;其中,第一容器组部署在第一节点中,第二容器组部署在第二节点中,报文支持的网络协议与第二节点的节点网卡支持的网络协议不同。
处理器701可以是通用处理器,包括中央处理器(central processing unit,简称CPU)、网络处理器(Network Processor,简称NP)等,还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本申请实施例的电子设备以多种形式存在,包括但不限于:
(1)移动通信设备:这类设备的特点是具备移动通信功能,并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如:iPhone)、多媒体手机、功能性手机,以及低端手机等。
(2)超移动个人计算机设备:这类设备属于个人计算机的范畴,有计算和处理功能,一般也具备移动上网特性。这类终端包括:PDA、MID和UMPC设备等,例如iPad。
(3)便携式娱乐设备:这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如:iPod),掌上游戏机,电子书,以及智能玩具和便携式车载导航设备。
(4)服务器:提供计算服务的设备,服务器的构成包括处理器、硬盘、内存、***总线等,服务器和通用的计算机架构类似,但是由于需要提供高可靠的服务,因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
(5)其他具有数据交互功能的电子装置。
需要指出,根据实施的需要,可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤,也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤,以实现本申请实施例的目的。
上述根据本申请实施例的方法可在硬件、固件中实现,或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码,或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码,从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解,计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如,RAM、ROM、闪存等),当软件或计算机代码被计算机、处理器或硬件访问且执行时,实现在此描述的容器云平台的双栈跨节点通信方法。此外,当通用计算机访问用于实现在此示出的方法的代码时,代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及方法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请实施例的范围。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于设备及***实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。
以上所描述的设备及***实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元提示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅为本申请的优选实施例,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (10)
1.一种容器云平台的双栈跨节点通信方法,其特征在于,所述容器云平台包括多个节点,每个所述节点中部署有CNI插件,且所述CNI插件运行在VXLAN模式下,所述方法应用于任一所述CNI插件,包括:
通过边界网关协议获取所述容器云平台的网络信息;
其中,所述网络信息包括所述容器云平台中所有所述节点的节点网卡的网络信息,以及各所述节点中的所有容器组的网络信息;
将所述网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一所述节点中每个所述VXLAN虚拟网卡支持不同的网络协议;
所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组;
其中,所述第一容器组部署在第一节点中,所述第二容器组部署在第二节点中,所述报文支持的网络协议与所述第二节点的节点网卡支持的网络协议不同。
2.根据权利要求1所述的容器云平台的双栈跨节点通信方法,其特征在于,在所述通过边界网关协议获取所述容器云平台的网络信息之前,还包括:
各所述节点中部署的所述CNI插件获取所述容器云平台中所有所述节点的信息,并根据所有所述节点的信息,在各所述节点中部署边界网关协议的客户端组件;
各所述节点中部署的所述CNI插件对所述边界网关协议的客户端组件进行配置,以使任意两个所述节点中的所述边界网关协议的客户端组件能够相互通信。
3.根据权利要求2所述的容器云平台的双栈跨节点通信方法,其特征在于,还包括:
响应于所述容器云平台新增节点,在所述新增节点中部署所述CNI插件;
所述新增节点中部署的CNI插件在所述新增节点中部署所述边界网关协议的客户端组件,并对所述新增节点中的所述边界网关协议的客户端组件进行配置,以使所述新增节点中部署的所述边界网关协议的客户端组件能够与任一现有节点中的所述边界网关协议的客户端组件相互通信。
4.根据权利要求2或3所述的容器云平台的双栈跨节点通信方法,其特征在于,在所述通过边界网关协议获取所述容器云平台的网络信息之前,还包括:
所述CNI插件获取所在节点中所有容器组使用的网络协议的类型;
所述CNI插件根据所在节点中所有容器组使用的网络协议的类型,创建对应的所述VXLAN虚拟网卡。
5.根据权利要求2所述的容器云平台的双栈跨节点通信方法,其特征在于,所述通过边界网关协议获取所述容器云平台的网络信息,具体为:
各所述边界网关协议的客户端组件收集所在节点中的所有容器组的网络信息;
将收集到的所述所在节点中的节点网卡的网络信息和所有容器组的网络信息以广播的形式发送给所述容器云平台中其他所有节点中的边界网关协议的客户端组件,以使每个所述边界网关协议的客户端组件获知所述容器云平台中所有节点的节点网卡的网络信息和所有容器组的网络信息。
6.根据权利要求1所述的容器云平台的双栈跨节点通信方法,其特征在于,所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组之前,还包括:
所述第一容器组将所述报文发送至目标VXLAN虚拟网卡的发送端;所述目标VXLAN虚拟网卡支持的网络协议与所述报文支持的网络协议相同;
所述目标VXLAN虚拟网卡根据所述报文的目的地址和所述网络信息,确定所述报文的接收方为所述第二容器组,并确定所述第二容器组所在的所述第二节点的节点网卡支持的网络协议。
7.根据权利要求6所述的容器云平台的双栈跨节点通信方法,其特征在于,所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组,具体为:
所述目标VXLAN虚拟网卡的发送端对所述报文进行封装,以将所述第二节点的节点网卡的网络地址添加为所述报文的外层目的地址,将所述VXLAN虚拟网卡的接收端对应的端口号添加为所述外层目的地址的端口号;
所述VXLAN虚拟网卡的发送端基于所述外层目的地址和所述外层目的地址的端口号,将所述报文经由所述第二节点的节点网卡发送至所述VXLAN虚拟网卡的接收端,以由所述VXLAN虚拟网卡的接收端对所述报文进行拆封,并将拆封后的报文发送至所述第二容器组。
8.一种容器云平台的双栈跨节点通信***,其特征在于,所述容器云平台包括多个节点,每个所述节点中部署有CNI插件,且所述CNI插件运行在VXLAN模式下,包括:
获取单元,配置为通过边界网关协议获取所述容器云平台的网络信息;
其中,所述网络信息包括所述容器云平台中所有所述节点的节点网卡的网络信息,以及各所述节点中的所有容器组的网络信息;
写入单元,配置为将所述网络信息写入所在节点中的至少一个VXLAN虚拟网卡中;同一所述节点中每个所述VXLAN虚拟网卡支持不同的网络协议;
发送单元,配置为所述VXLAN虚拟网卡基于所述网络信息,将第一容器组发出的报文经由所述第二节点的节点网卡发送至第二容器组;
其中,所述第一容器组部署在第一节点中,所述第二容器组部署在第二节点中,所述报文支持的网络协议与所述第二节点的节点网卡支持的网络协议不同。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时,实现权利要求1-7任一所述的容器云平台的双栈跨节点通信方法。
10.一种电子设备,其特征在于,包括:存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序,所述处理器执行所述程序时实现如权利要求1-7任一所述的容器云平台的双栈跨节点通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310135077.9A CN116132435B (zh) | 2023-02-17 | 2023-02-17 | 一种容器云平台的双栈跨节点通信方法和*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310135077.9A CN116132435B (zh) | 2023-02-17 | 2023-02-17 | 一种容器云平台的双栈跨节点通信方法和*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN116132435A true CN116132435A (zh) | 2023-05-16 |
CN116132435B CN116132435B (zh) | 2023-09-01 |
Family
ID=86300920
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310135077.9A Active CN116132435B (zh) | 2023-02-17 | 2023-02-17 | 一种容器云平台的双栈跨节点通信方法和*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116132435B (zh) |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107770066A (zh) * | 2017-10-20 | 2018-03-06 | 成都精灵云科技有限公司 | 一种跨主机、跨VLAN、跨集群的Docker容器导流方法 |
CN111857873A (zh) * | 2020-07-15 | 2020-10-30 | 浪潮云信息技术股份公司 | 一种实现云原生容器网络的方法 |
CN112104499A (zh) * | 2020-09-14 | 2020-12-18 | 浪潮思科网络科技有限公司 | 一种容器网络模型构建方法、装置、设备及介质 |
CN112470436A (zh) * | 2018-07-17 | 2021-03-09 | 思科技术公司 | 使用srv6和bgp的多云连通性 |
CN114172865A (zh) * | 2021-12-03 | 2022-03-11 | 紫光云(南京)数字技术有限公司 | 一种云网络下IPv6双栈的实现方法 |
CN114172802A (zh) * | 2021-12-01 | 2022-03-11 | 百果园技术(新加坡)有限公司 | 容器网络配置方法、装置、计算节点、主节点及存储介质 |
WO2022187796A1 (en) * | 2021-03-01 | 2022-09-09 | Juniper Networks, Inc. | Containerized router with virtual networking |
CN115686729A (zh) * | 2021-07-26 | 2023-02-03 | 阿里巴巴新加坡控股有限公司 | 容器集群网络***、数据处理方法、设备及计算机程序产品 |
-
2023
- 2023-02-17 CN CN202310135077.9A patent/CN116132435B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107770066A (zh) * | 2017-10-20 | 2018-03-06 | 成都精灵云科技有限公司 | 一种跨主机、跨VLAN、跨集群的Docker容器导流方法 |
CN112470436A (zh) * | 2018-07-17 | 2021-03-09 | 思科技术公司 | 使用srv6和bgp的多云连通性 |
CN111857873A (zh) * | 2020-07-15 | 2020-10-30 | 浪潮云信息技术股份公司 | 一种实现云原生容器网络的方法 |
CN112104499A (zh) * | 2020-09-14 | 2020-12-18 | 浪潮思科网络科技有限公司 | 一种容器网络模型构建方法、装置、设备及介质 |
WO2022187796A1 (en) * | 2021-03-01 | 2022-09-09 | Juniper Networks, Inc. | Containerized router with virtual networking |
CN115686729A (zh) * | 2021-07-26 | 2023-02-03 | 阿里巴巴新加坡控股有限公司 | 容器集群网络***、数据处理方法、设备及计算机程序产品 |
CN114172802A (zh) * | 2021-12-01 | 2022-03-11 | 百果园技术(新加坡)有限公司 | 容器网络配置方法、装置、计算节点、主节点及存储介质 |
CN114172865A (zh) * | 2021-12-03 | 2022-03-11 | 紫光云(南京)数字技术有限公司 | 一种云网络下IPv6双栈的实现方法 |
Non-Patent Citations (1)
Title |
---|
毕小红;刘渊;陈飞;: "微服务应用平台的网络性能研究与优化", 计算机工程, no. 05, pages 53 - 59 * |
Also Published As
Publication number | Publication date |
---|---|
CN116132435B (zh) | 2023-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11909586B2 (en) | Managing communications in a virtual network of virtual machines using telecommunications infrastructure systems | |
US11546288B2 (en) | Techniques for managing software defined networking controller in-band communications in a data center network | |
US11102079B2 (en) | Cross-regional virtual network peering | |
CN111885075B (zh) | 容器通信方法、装置、网络设备及存储介质 | |
US8725898B1 (en) | Scalable port address translations | |
US11050586B2 (en) | Inter-cloud communication method and related device, and inter-cloud communication configuration method and related device | |
CN103814554B (zh) | 一种虚拟可扩展局域网的通信方法、装置和*** | |
US10171357B2 (en) | Techniques for managing software defined networking controller in-band communications in a data center network | |
US9736016B2 (en) | Managing failure behavior for computing nodes of provided computer networks | |
CN106452857B (zh) | 生成配置信息的方法和网络控制单元 | |
EP3437259B1 (en) | Interworking between physical network and virtual network | |
US7499451B2 (en) | Computer node, cluster system, cluster managing method, and cluster managing program | |
US11398956B2 (en) | Multi-Edge EtherChannel (MEEC) creation and management | |
WO2018137369A1 (zh) | 混合云管理方法、装置和计算设备 | |
US9258272B1 (en) | Stateless deterministic network address translation | |
CN106878136B (zh) | 一种报文转发方法及装置 | |
CN112583618B (zh) | 为业务提供网络服务的方法、装置和计算设备 | |
US10237235B1 (en) | System for network address translation | |
CN113364660B (zh) | Lvs负载均衡中的数据包处理方法及装置 | |
US11595306B2 (en) | Executing workloads across multiple cloud service providers | |
EP4302469A1 (en) | Containerized router with virtual networking | |
Merlino et al. | Enabling mechanisms for cloud-based network virtualization in iot | |
KR101481410B1 (ko) | 메모리 카드 장치 | |
CN116132435B (zh) | 一种容器云平台的双栈跨节点通信方法和*** | |
CN117097818A (zh) | 一种报文处理的方法及相关设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |