CN113872997A - 基于容器集群服务的容器组pod重建方法及相关设备 - Google Patents
基于容器集群服务的容器组pod重建方法及相关设备 Download PDFInfo
- Publication number
- CN113872997A CN113872997A CN202010616265.XA CN202010616265A CN113872997A CN 113872997 A CN113872997 A CN 113872997A CN 202010616265 A CN202010616265 A CN 202010616265A CN 113872997 A CN113872997 A CN 113872997A
- Authority
- CN
- China
- Prior art keywords
- pod
- target
- node
- network
- detection unit
- 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/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/06—Generation of reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- 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/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
- H04L67/1046—Joining mechanisms
-
- 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/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
- H04L67/1048—Departure or maintenance mechanisms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Abstract
本申请实施例公开了一种基于容器集群服务的容器组POD重建方法及相关设备,用于通信技术领域。本申请实施例方法包括:主节点为多个计算节点中的每个计算节点部署检测单元;所述主节点通过所述管理网络接收所述检测单元发送的检测结果,所述检测结果用于指示所述检测单元对应的pod与目标pod在业务网络上的连接状态;所述主节点根据所述检测结果,确定是否异地重建所述目标pod。使用本方法,可以减少因主节点只基于管理网络进行节点故障判断和pod修复而导致的误判问题,更加精准的确定需要异地重建的pod,减少了pod重建的工作量,提供了网络性能。
Description
技术领域
本申请实施例涉及通信技术领域,尤其涉及一种基于容器集群服务的容器组POD重建方法及相关设备。
背景技术
网络功能虚拟化(network function virtualization,NFV)技术可以简单地理解为将网络中各个网元的功能从专用硬件平台迁移至通用的商用货架产品服务器上。通过NFV技术可以将各个网元转变为独立的应用,以便灵活部署在基于标准的服务器、交换机等其他设备构建的统一基础设施平台上,并通过虚拟化技术,对基础设施硬件设备虚拟化,为上层应用提供虚拟资源,实现应用程序、硬件解耦,使得每一个应用程序能够快速增加/减少虚拟资源以实现快速扩展/收缩系统容量的目的,大大提升网络的弹性。而容器技术作为一种新型虚拟化技术,其为应用程序提供了隔离的运行空间;即每个容器内部都包含一个独享的完整用户环境空间,并且一个容器内的变动不会影响其他容器的运行环境。
容器集群管理系统(Kubernetes,K8s)是一种基于容器的集群管理平台,包括主节点和与主节点(master)连接的多个计算节点(node),主节点用于管理和控制多个计算节点;计算节点部署在虚拟机上,每个计算节点都包括多个容器组(pod),pod为K8s平台的基本操作单元,每个pod封装有一个或多个用于承载应用程序的容器(container),并且属于同一pod的容器共享网络资源。在K8s平台中,基于电信业务的可靠性和安全要求会把管理网络和不同的业务网络进行网络平面隔离,避免不同类型的网络流量的相互影响,即管理网络用于主节点对计算节点进行管理,业务网络用于不同计算节点之间的业务数据传递。
k8s平台通过管理网络来监测主节点与计算节点之间的连接情况,当主节点与计算节点之间的管理网络发生故障时,K8s平台就会对pod进行异地重建,导致该pod上的业务数据传输发生中断;当主节点与计算节点之间的业务网络发生故障时,K8s平台无法感知其故障,将不会进行pod的重建,导致业务数据传输无法恢复。
发明内容
本申请实施例提供了一种基于容器集群服务的容器组POD重建方法及相关设备,用于解决K8s平台不能准确获取pod的状态进入不能准确进行pod重建的问题。
本申请的第一方面提供了一种基于容器集群服务的容器组pod重建方法,包括:
在k8s平台中,主节点与多个计算节点相连接,执行通过管理网络对计算节点进行包括建立计算节点,在计算节点上部署容器组pod,为计算节点调度资源等管理功能;其中,每个计算节点上又包括有至少一个pod,每个pod包括多个容器,容器中封装有应用,对外提供相关业务,其中,pod与pod之间是通过业务网络进行业务数据传输的,这样可以保证管理网络与业务网络相互独立,不同的数据流量互不干扰。主节点需要为每一个计算节点都部署一个检测单元,该检测单元用于检测自身对应的计算节点上一个目标pod与其他pod在业务网络上的连接状态,检测单元需要将检测结果通过管理网络上报给主节点,主节点再根据该检测结果来感知目标pod对应的计算节点是否出现故障,以及是否需要在异地重建该节点上的目标pod。
主节点根据检测单元上报的检测结果作为重建目标pod的判断调节,可以避免根据管理网络来确定计算节点是否发生故障而引起的误判,当目标pod与其他pod之间的业务数据传输正常时,即使目标pod对应的计算节点与主节点在管理网络上的连接发生故障,也无需进行目标pod的重建,大大减少了重建目标pod的工作量,提高了网络性能。
基于第一方面,本申请还提供了第一方面的第一种实施方式:
主节点还可以对目标pod对应的业务网络上的所有计算节点进行分组,当主节点为每个计算节点部署pod时,会建立每一个pod和计算节点的对应关系,主节点根据目标pod所提供的业务,就可以找到与目标pod提供的业务相关联的所有pod,从而得到与目标pod相关联的所有目标计算节点;然后,对目标计算节点进行分组,确定分组信息;再向检测单元发送该分组信息,其目标是为了指示各检测单元在检测自身对应的目标pod在业务网络的连接状态时,只需要检测目标pod与分组内的计算节点的连接状态。
在一个业务网络中,可能会存在大量的计算节点,如果检测单元检测自身对应的目标pod与所有计算节点的业务数据传输,将会导致检测工作量巨大,并且时延较长,检测单元无法及时上报检测结果,所有可以对一个业务网络上的所有计算节点进行分组,在组内相互检测业务数据传输情况即可,这样将会提高检测效率,便于主节点及时掌握业务网络的业务数据传输情况。
基于第一方面的第一种实施方式,本申请还提供了第一方面的第二种实施方式:
在主节点对一个业务网络上的多个计算节点进行分组时,一个优选的方案是将属于不同物理服务器的多个计算节点分在一个组内,使得每个组内的计算节点尽量分布在尽可能多的物理刀片上,这样每组计算节点对应的业务网络覆盖范围更广,检测结果也更能反映各pod之间的连接状态。
基于第一方面的第一种实施方式至第二种实施方式,本申请还提供了第一方面的第三种实施方式:
系统在运行过程中,可能发生pod重建或者pod/node实例信息改变可能的变化,即计算节点的增加、删除以及pod变更,主节点需要判断目标pod对应的业务网络上是否增加/删除计算节点的情况,如果有,则需要重新确定目标计算节点,对目标计算节点重新进行分组,再将新的分组信息发送至各检测单元,检测单元再按照更新后的分组信息进行检测。
基于第一方面至第一方面的第三种实施方式,本申请还提供了第一方面的第四种实施方式:
如果主节点接收到的检测结果显示所述目标pod在所述业务网络上发生连接故障时,即目标pod与其他计算节点上的pod都无法进行数据传输时,主节点就可以依次来确定目标pod的计算节点不能再使用,即需要触发目标pod的异地重建;如果主节点接收到的检测结果显示所述目标pod在所述业务网络上未发生连接故障时,即目标pod与其他计算节点上的pod可以进行数据传输,主节点就不触发目标pod的异地重建。
主节点根据检测单元上报的检测结果作为重建目标pod的判断调节,可以避免根据管理网络来确定计算节点是否发生故障而引起的误判,当目标pod与其他pod之间的业务数据传输正常时,即使目标pod对应的计算节点与主节点在管理网络上的连接发生故障,也无需进行目标pod的重建,大大减少了重建目标pod的工作量,提高了网络性能。
本申请的第二方面提供了一种基于容器集群服务的容器组pod重建方法,包括:
在k8s平台中,主节点与多个计算节点相连接,其中,每个计算节点上又包括有至少一个pod,每个pod包括多个容器,容器中封装有应用,对外提供相关业务,其中,pod与pod之间是通过业务网络进行业务数据传输的。主节点为每一个计算节点都部署一个检测单元,并向检测单元下发控制信息,检测单元可以根据控制信息确定自身对应的计算节点上的目标pod,以及目标pod对应的业务网络上的所有计算节点,检测单元需要去探测自身对应的计算节点上的pod与目标pod在业务网络上的连接状态,生成检测结果,并将检测结果通过管理网络上报给主节点,主节点再根据该检测结果来感知目标pod对应的计算节点是否出现故障,以及是否需要在异地重建该节点上的目标pod。
检测单元检测业务网络上的数据传输情况,并将数据传输情况反馈给主节点,使得主节点根据检测单元上报的检测结果作为重建目标pod的判断调节,这样可以避免主节点根据管理网络来确定计算节点是否发生故障而引起的误判,减少重建目标pod的工作量,提高网络性能。
基于第二方面,本申请还提供了第二方面的第一种实施方式:
具体的,检测单元需要检测自身的pod与目标pod之间的业务数据传输是否正常;若正常,则检测单元确定目标pod对应的业务网络未发生故障;若异常,则检测单元确定所述目标pod对应的业务网络发生故障。
检测单元检测自身对应的pod与其他计算节点上的目标pod能否进行业务数据传输,如果不能,则证明检测单元对应的计算节点与目标pod连接发生故障,然后将该故障通过管理网络发送给主节点,使得主节点感知目标pod的业务网络;一般的,当计算节点发生故障时,也无法向主节点汇报自身业务网络的情况,这样就可以通过其他的计算节点上报该故障,保证了主节点及时感知业务网络情况,并对故障的计算几点进行处理。
基于第二方面的第一种实施方式,本申请还提供了第二方面的第二种实施方式:
主节点还可以对目标pod对应的业务网络上的所有计算节点进行分组,确定分组信息;再向检测单元发送该分组信息,检测单元在检测自身对应的目标pod与目标pod在业务网络的连接状态时,只需要在分组内的计算节点之间相互检测。
在一个业务网络中,可能会存在大量的计算节点,如果检测单元相互检测与所有计算节点的业务数据传输时,将会导致检测工作量巨大,并且时延较长,检测单元无法及时上报检测结果,所有可以对一个业务网络上的所有计算节点进行分组,在组内相互检测业务数据传输情况即可,这样将会提高检测效率,便于主节点及时掌握业务网络的业务数据传输情况。
基于第二方面至第二方面的第二种实施方式,本申请还提供了第二方面的第三种实施方式:
检测单元在检测时,可以周期性的周期性的检测检测单元对应的pod与目标pod在所述业务网络上的连接状态,生成多个检测结果,这样可以实施掌握业务网络连接状态,更好的反应个计算节点的状态。
基于第二方面的第三种实施方式,本申请还提供了第二方面的第四种实施方式:
检测单元需要通过管理网络定期向主节点发送多个检测结果。
本申请的第三方面提供了一种基于容器集群服务的网元设备,其特征在于,所述网元设备包括:
执行单元,用于为多个计算节点中的每个计算节点部署检测单元;其中,所述网元设备与所述多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
接收单元,用于通过所述管理网络接收所述检测单元发送的检测结果,所述检测结果用于指示所述检测单元对应的pod与目标pod在业务网络上的连接状态;
确定单元,用于根据所述检测结果,确定是否异地重建所述目标pod。
基于第三方面,本申请还提供了第三方面的第一种实施方式:
所述网元设备还包括发送单元;
所述确定单元,还用于确定所述目标pod对应的业务网络上的所有计算节点为目标计算节点;
所述执行单元,还用于对所述目标计算节点进行分组,确定分组信息;
所述发送单元,用于向所述检测单元发送所述分组信息,以使得所述检测单元根据所述分组信息检测所述目标pod在所述业务网络上的连接状态。
基于第三方面的第一种实施方式,本申请还提供了第三方面的第二种实施方式:
所述执行单元,具体用于根据所述目标计算节点对应的物理服务器对所述目标计算节点进行分组;其中,每组包括的目标计算节点属于不同的物理服务器。
基于第三方面的第一种实施方式至第二种实施方式,本申请还提供了第三方面的第三种实施方式:
所述网元设备还包括判断单元;
所述判断单元用于判断所述目标pod对应的业务网络上是否增加/删除计算节点;
所述执行单元,还用于若所述判断单元的判断结果为是,则重新确定所述目标计算节点,对所述目标计算节点重新进行分组,以使得所述检测单元根据新的分组信息检测所述目标pod在所述业务网络上的连接状态。
基于第三方面至第三方面的第三种实施方式,本申请还提供了第三方面的第四种实施方式:
所述执行单元还用于当多个所述检测结果均为所述目标pod在所述业务网络上发生连接故障时,所述主节点触发所述目标pod的异地重建;当所述多个检测结果中的一个检测结果为所述目标pod在所述业务网络上未发生连接故障时,所述主节点不触发所述目标pod的异地重建。
本申请的第四方面提供了一种基于容器集群服务的检测单元,所述检测单元包括:
确定单元,用于确定所述检测单元对应的pod与目标pod之间的业务网络;其中,所述检测单元由主节点为计算节点部署,所述主节点与多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
处理单元,用于检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态,生成检测结果;
发送单元,用于通过管理网络向主节点发送所述检测结果,以使得所述主节点根据所述检测结果确定所述目标pod是否需要重建。
基于第四方面,本申请还提供了第四方面的第一种实施方式:
所述处理单元具体用于判断所述目标pod与所述检测单元对应的pod之间的业务数据传输是否正常;若正常,则所述检测单元确定所述目标pod对应的业务网络未发生故障;若异常,则所述检测单元确定所述目标pod对应的业务网络发生故障。
基于第四方面的第一种实施方式,本申请还提供了第四方面的第二种实施方式:
所述检测单元还包括接收单元;
所述接收单元,用于接收所述主节点发送的分组信息;
所述处理单元,具体用于根据所述分组信息判断是否检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态。
基于第四方面至第四方面的第二种实施方式,本申请还提供了第四方面的第三种实施方式:
所述处理单元具体同于周期性的检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态,生成多个检测结果。
基于第四方面的第三种实施方式,本申请还提供了第四方面的第四种实施方式:
所述发送单元,具体用于通过管理网络定期向主节点发送所述多个检测结果。
本申请第五方面提供一种网元设备,包括:至少一个处理器、存储器,存储器存储有可在处理器上运行的计算机执行指令,当所述计算机执行指令被所述处理器执行时,所述处理器执行如上述第一方面至第一方面任意一种可能的实现方式所述的方法。
本申请第六方面提供一种检测单元,包括:至少一个处理器、存储器,存储器存储有可在处理器上运行的计算机执行指令,当所述计算机执行指令被所述处理器执行时,所述处理器执行如上述第二方面至第二方面任意一种可能的实现方式所述的方法。
本申请第七方面提供了一种基于容器集群服务的容器组pod重建系统,其特征在于,包括:如上述第三方面至第三方面的第四种实施方式所述的任一项网元设备,如上述第四方面至第四方面的第一种实施方式所述的任一项检测单元,所述网元设备向所述检测单元发送分组信息,所述检测单元向所述网元设备发送检测结果。
本申请第八方面提供了一种计算机存储介质,该计算机存储介质用于储存为上述网元设备或检测单元所用的计算机软件指令,其包括用于执行为网元设备、或检测单元所设计的程序。
该网元设备可以如前述第三方面所描述的网元设备。
该检测单元可以如前述第四方面所描述的检测单元。
本申请第九方面提供了一种芯片或者芯片系统,该芯片或者芯片系统包括至少一个处理器和通信接口,通信接口和至少一个处理器通过线路互联,至少一个处理器用于运行计算机程序或指令,以进行第一方面至第一方面的任一种可能的实现方式中任一项所描述的基于容器集群服务的容器组pod重建方法;
其中,芯片中的通信接口可以为输入/输出接口、管脚或电路等。
在一种可能的实现中,本申请中上述描述的芯片或者芯片系统还包括至少一个存储器,该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元,例如,寄存器、缓存等,也可以是该芯片的存储单元(例如,只读存储器、随机存取存储器等)。
本申请第十方面提供了一种芯片或者芯片系统,该芯片或者芯片系统包括至少一个处理器和通信接口,通信接口和至少一个处理器通过线路互联,至少一个处理器用于运行计算机程序或指令,以进行第二方面至第二方面的任一种可能的实现方式中任一项所描述的基于容器集群服务的容器组pod重建方法;
其中,芯片中的通信接口可以为输入/输出接口、管脚或电路等。
在一种可能的实现中,本申请中上述描述的芯片或者芯片系统还包括至少一个存储器,该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元,例如,寄存器、缓存等,也可以是该芯片的存储单元(例如,只读存储器、随机存取存储器等)。
本申请第十一方面提供了一种计算机程序产品,该计算机程序产品包括计算机软件指令,该计算机软件指令可通过处理器进行加载来实现上述第一方面至第二方面中任意一项基于容器集群服务的容器组pod重建方法中的流程。
从以上技术方案可以看出,本申请具有以下优点:
在本发明实施例中,主节点通过为每个计算节点都部署检测单元,使得检测单元检测业务网络上目标pod的连接状态,然后主节点通过管理网络接收检测单元发送的检测结果,根据该检测结果确定是否异地重建所述目标pod,这样,可以减少因主节点只基于管理网络进行节点故障判断和pod修复而导致的误判问题,更加精准的确定需要异地重建的pod,减少了pod重建的工作量,提供了网络性能。
附图说明
图1为本申请实施例提供的一种NFV系统的系统架构图;
图2为本申请实施例提供的一种k8s管理系统的架构示意图;
图3为本申请实施例提供的另一种k8s管理系统的架构示意图;
图4为本申请实施例提供的一种基于容器集群服务的容器组pod重建方法的流程示意图;
图5为本申请实施例提供的一种邻居算法的结构示意图;
图6为本申请实施例提供的一种基于容器集群服务的网元设备的结构示意图;
图7为本申请实施例提供的一种基于容器集群服务的检测单元的结构示意图;
图8为本申请实施例提供的另一种基于容器集群服务的网元设备的结构示意图;
图9为本申请实施例提供的另一种基于容器集群服务的检测单元的结构示意图。
具体实施方式
本申请实施例提供了一种基于容器集群服务的容器组POD重建方法及相关设备,用于解决K8s平台不能准确获取pod的状态进入不能准确进行pod重建的问题。
NFV技术可以简单地理解为将电信网络中各个网元的功能从目前的专用硬件平台迁移至通用的商用货架产品(commercial-off-the-shelf,COTS)服务器上。通过NFV技术可以将各个网元转变成为独立的应用,灵活部署在基于标准的服务器、存储器以及交换机等设备构建的统一基础设施平台上;并且通过虚拟化技术,可以对作为基础设施的硬件设备资源池化及虚拟化,为上层应用提供虚拟资源,实现应用和硬件设备解耦,使得每一个应用能够快速增加/减少虚拟资源以实现快速扩展系统容量的目的,大大提升网络的弹性;同时,采用通用COTS服务器组成的共享资源池,新开发的业务就不需要单独部署硬件设备,大大缩短新业务上线时间。
NFV技术的基础包含云计算技术和虚拟化技术;其中,通用的COTS硬件设备可以通过虚拟化技术分解为多种虚拟资源,供上层各种应用使用。虚拟化技术实现了应用与硬件之间的解耦,使得虚拟资源供给速度大大增加;而云计算技术,可以实现应用的弹性伸缩,保证虚拟资源与业务负荷相匹配,这样既提升了虚拟资源的利用效率,也改善了系统的响应速率。
图1为本申请实施例提供的一种NFV系统的系统架构图,NFV系统100可以在各种网络中使用,例如在数据中心网络、运营商网络或局域网中来构建。如图1所示,NFV系统100包括:NFV管理和编排系统(NFV management and orchestration,NFV MANO)、NFV基础设施层(NFV infrastructure,NFVI)、多个虚拟网络功能(virtual network function,VNF)、多个网元管理(element management,EM);业务支持管理系统(operation-support system/business support system,OSS/BSS)。
NFV MANO中又包括NFV编排器(NFV orchestrator,NFVO),一个或多个VNF管理(VNF manager,VNFM)和虚拟化基础设施管理器(virtualized infrastructure manager,VIM)。其中,NFV MANO用于执行对VNF和NFVI的监视和管理,NFVO可以为NFVI提供的网络服务(如VPN服务),也可以执行来自一个或多个VNFM的资源相关请求,并且发送配置信息到VNFM,同时收集VNF的状态信息;NFVO与VIM通信,实现资源的分配和/或预留以及交换虚拟化硬件资源的配置和状态信息。其中,VNFM可以管理一个或多个VNF,包括实现实例化、更新、查询、缩放、终止VNF等功能。VIM可以执行资源管理的功能,例如管理基础设施资源的分配,例如增加资源到虚拟容器,或者执行操作功能,如收集NFVI故障信息等。同时,VNFM和VIM可以相互通信进行资源分配,以及交换虚拟化硬件资源的配置和状态信息。
而NFVI包括硬件资源层、虚拟化层、以及虚拟资源层。NFVI是利用硬件资源或软件资源来完成的虚拟化环境部署,即硬件资源层和虚拟资源层用于提供虚拟化的资源,例如作为虚拟机和其它形式的虚拟容器,用于VNF。其中,硬件资源层包括计算硬件、存储硬件和网络硬件。计算硬件用来提供处理和计算资源,存储硬件可以是网络内提供的存储容量或驻留在存储硬件本身的存储容量,网络硬件可以是交换机、路由器或配置成具有交换功能的任何网络设备。
虚拟化层用于从物理层抽象硬件资源和解耦VNF,向VNF提供虚拟化资源;而虚拟资源层包括虚拟计算,虚拟存储和虚拟网络。其中,虚拟计算和虚拟存储可以以虚拟机或其他虚拟容器的形式提供给VNF。例如,多个VNF可以部署在一个虚拟机上。虚拟化层抽象网络硬件就可以形成虚拟网络,虚拟网络可以包括虚拟交换机,用来提供多个虚拟机之间的连接。
其中,VNFM可以与VNF和EM交互来对VNF的生命周期进行管理以及交换配置和状态信息。VNF可以被配置为通过一个物理网络设备执行的至少一个网络功能的虚拟化。例如,在一个实现方案中,VNF可以经过配置以提供网络中的不同网元具备的功能。
虚拟化技术作为一种被广泛使用的服务器资源共享方式,也存在着很多问题;由于虚拟化技术依赖于完整的操作系统,即每个虚拟机在运行时,都需要运行一个完整的客户端操作系统以及该操作系统中安装好的大量应用程序,这样,针对于单个的应用来说,每开发一个应用,不仅需要部署应用,还需要为该应用部署一个完整操作系统,这样,由此产生的沉重负载将会影响开发应用程序的工作效率,为此,NFV架构中引入了容器技术。
容器技术是指,将单个操作系统的资源划分到孤立的容器中,在每个容器中部署应用,多个容器的资源相互独立,这样可以保证每个应用都是相互独立的,但是多个容器之间可以共享和复用底部多余的操作系统和环境,这样在应用程序开发时,由于只需要对每个容器内的应用进行操作,无需为每个应用都部署一个完整操作系统,因此大大减少负载,提升工作效率;NFV架构中引入容器技术后,即可以在多个虚拟机上建立多个容器,保证多个应用相互独立并且共享虚拟机的底部其他虚拟资源。
在虚拟机上部署容器,需要容器管理平台k8s来控制和管理多个容器,k8s为一种开源容器集群管理系统,用于部署、扩展和管理容器化应用程序;其中,集群指一组节点Node,具体的,这些node节点可以是物理服务器或者虚拟机,每个node节点中可以部署多个容器组pod,pod为k8s应用调度的最小部署单元,其中,一个pod里面可以包含一个或者多个容器。
图2为本申请实施例提供的一种k8s管理系统的架构示意图;如图2所示,k8s社区中包括主节点k8s master,和多个计算节点node,每个node中包括至少一个容器组pod;每个pod中包含至少一个容器,容器中部署有应用;基于电信业务的可靠性和安全要求,k8s社区会将管理网络和不同的业务网络进行网络平面隔离,避免不同类型的网络流量的相互影响。
其中,主节点k8s master和多个计算节点node之间通过管理网络进行连接,用于k8s master对计算节点node进行管理,包括建立node节点,在node上部署pod,为pod调度资源,配置pod等,因此管理网络上的数据传输一般为策略信息、资源配置信息等管理信息;而pod之间封装有应用程序,因此不同的node之间则通过业务网络进行业务数据的传输,示例性的,可以使用不同的网卡来区分两个网络这两个网络,主节点与计算节点的连接使用管理网卡,计算节点之间使用业务网卡,这样可以保证两个网络相互独立,网络流量互不影响。
在管理网络中,主节点会根据心跳探测机制来判断各个node的状态,具体的,当主节点检测到主节点与计算节点之间的连接发生故障时,就会认为该node发生故障,不能再使用,则会对该node上面的pod进行异地重建,即在另外的node上部署该pod;实际上,k8smaster基于该判断标准来判断节点的状态,将会出现大量误判。
例如,第一种情况,k8s master和node之间通信的管理网卡故障,但是node与node之间的业务网卡正常;此时pod可以正常对外提供业务,但是由于k8s根据管理网卡状态判断该节点故障,会对该节点上的pod做异地重建,这样将会导致业务中断;如果Pod使用了固定IP能力,重建后的pod就还会使用原来的IP地址,导致IP地址冲突问题。
第二种情况,k8s master和node之间的管理网卡正常,但是node与node之间的业务网卡异常;此时业务pod已经无法对外提供业务,但是k8s并不感知业务网络的连接状态,不会触发异地重建,这样导致业务持续不能恢复。
图3为本申请实施例提供的另一种k8s管理系统的架构示意图;如图3所示,在本申请实施例中,主节点k8s master为每一个计算节点node都部署了检测单元,检测单元与管理网络和业务网络都相互连接,用于通过业务网络对pod之间的业务数据传输状态进行检测,并将该检测结果通过管理网络汇报给主节点k8s master。
图4为本申请实施例提供的一种基于容器集群服务的容器组pod重建方法的流程示意图,如图4所示,该方法包括:
401、主节点为多个计算节点中的每个计算节点部署检测单元。
在本实施例中,主节点需要为计算节点部署一个新的结构单元,即检测单元,该检测单元作为管理网络和业务网络的桥梁,需要对业务网络中的连接状态进行检测,其目的是为了更准确的判断计算节点的状态,而不再将管理网络中计算节点与主节点之间的连接状态作为对计算节点工作状态的判断依据,减少因误判而导致的计算节点上的pod的重建,以便提升网络性能;可选的,主节点以计算节点为单位进行检测单元的部署,即一个计算节点对应一个检测单元,一个计算节点上的多个pod共用一个检测节点。
402、主节点为计算节点调度pod,并记录pod和计算节点的关联关系。
在新的网络架构下,主节点仍然管理计算节点,包括正常调度多个Pod到对应的计算节点上,同时还可以根据网络状态和相关策略删除旧的节点或者增加新的节点;当主节点调度好业务pod时,还需要记录pod和关联关系,以便后续根据该关联关系对每个pod进行管理,可以理解的,pod和计算节点的关联关系通常为一对多。
403、主节点根据目标Pod的业务网络,确定该业务管理平面中的所有相关计算节点。
可以理解的,若某一计算节点发生故障后,该计算节点上的pod就不能与其他pod进行业务数据传输;因此,主节点可以通过掌握pod在业务网络上的连接状态来确定计算节点是否发生故障;主节点可以先确定某一计算节点上的一个pod作为检测对象目标pod,然后根据目标pod所提供的业务,查找与目标pod需要进行业务传输的所有相关的计算节点,可选的,可以确定所有计算节点为目标计算节点;通过获取该目标pod与目标计算节点的业务数据传输情况,来判断目标pod能否正常进行数据传输,如果目标pod不能传输业务数据给所有相关的计算节点,则证明该目标pod对应的计算节点发生故障,这样就需要异地重建该计算节点上的所有pod,可以理解的,只要目标pod能与其中一个相关的计算节点正常传输业务数据,那么则说明该计算节点并未发生故障,无需对该计算节点上的pod进行重建。
404、主节点对所有计算节点进行分组,确定分组信息。
可以理解的,对于目标pod而言,如果检测业务网络上所有计算节点与其的连接状态,将会产生很大的工作量,同时也会产生很大的延迟导致检测结果上报不及时;因此,一个优先的方案,将所有的计算几点进行分组,各计算节点对应的pod只需要在分组内相互进行检测即可,即目标pod对应的检测单元无需检测目标pod与所有计算节点的业务数据传输状态,只需要检测一部分即可,这样减少网络负荷,提高检测效率。
可选的,为了提高检测的准确性,在分组时,需要根据各计算节点所对应的物理服务器进行分组,在选择每组的多个节点时,可以逐个从不同的物理服务器上选取计算节点,使得计算节点尽量分布在尽可能多的物理刀片上,这样每组计算节点对应的业务网络覆盖范围更广,检测结果也更能反映各pod之间的连接状态。
可以理解的,分组算法可以有多种,示例性的,目标pod对应的业务网络上有N个计算节点(包括目标pod所在的计算节点),主节点可以预设每组对应的计算节点的数目为M,若N小于等于M,则不进行划分,即把所有的计算节点分为一组;如果N大于M,那么就可以将计算节点分为i组,示例性的,i的值为N/M再取整数,每组包括M个计算节点;如果M不能整除N,那么可以将分组完剩下的节点随机分配给每个组,即每组所包含的计算节点的个数可以不同。例如,业务网络包括20个节点,预设的M为4,那么就将其划分为5组;若业务网络包括11个节点,预设的M为3,那么就先将其划分为3组,每组包括3个计算节点,然后对剩下的两个计算节点进行划分,比如可以第1组包含4个计算节点,第2组包含4个计算节点,第3组包含4个计算节点。
示例性的,还可以采用邻居算法建立节点间的相邻关系;即可以将集群社区初始化虚拟为坐标平面的矩形或正方形,然后向矩形或正方形添加新的节点,每增加一个节点,就需要对矩形或正方形进行平分面积的处理,并且在分好的面积中填入新节点;最后,根据边相邻原则在矩形或正方形确定邻居关系,即边界相邻的多个计算节点即为邻居节点,并将邻居节点划分为一组,检测邻居节点之间业务数据传输的情况;图5为本申请实施例提供的邻居算法的结构示意图,如图5所示在对矩形或正方形进行面积划分时,需要遵循平均切分位置(对边中心点切分)、平均切分方向(先纵向、后横向或者先横向、后纵向)、相邻限定原则(相邻节点的面积比例关系为1:1或者2:1)、反亲和性原则(节点及其所有相邻节点尽量不处于同一物理主机)、相邻切分原则(新加入节点选择面积切分的节点满足条件,其一选择节点面积最大,其二新加入节点与邻居节点的反亲和性比其他候选节点权重更大)、相邻合并原则(故障节点选择退出集群时,选择当前面积最小的节点替换,同时合并面积最小的节点)等原则。
可以理解的,系统在运行过程中,可能发生pod重建或者pod/node实例信息改变可能的变化,即计算节点的增加、删除以及pod变更;其中,计算节点增加是指系统中增加了新的计算节点,并且有pod调度到新计算节点上并且与业务网络关联起来;计算节点删除是指系统中删除了部分计算节点,并且该计算节点上面的pod也被重建到其他计算节点上;而pod位置变更是指pod从计算节点A重新调度到计算节点B上,计算节点A跟pod的业务网络关联取消,同时节点B和pod的业务网络关联。由此可见,当主节点判断目标pod对应的业务网络上有增加/删除计算节点的情况,或者有pod变更的情况,就需要确定目标计算节点,且对新的目标计算节点进行重新分组。
示例性的,当某个节点移出业务网络时,主节点从其所在的分组中删除该计算节点,并从之前分组时剩余的计算节点中取一个节点放到被删除节点的分组中;如果不存在多余的计算节点,则可以把被删除计算节点的分组拆散,相关计算节点均衡到其他分组中。
示例性的,如果新的计算节点添加某个业务网络时,则可以将该计算节点添加到剩余的计算节点中,组成新的分组;还可以全部重新进行分组,具体不做限定。
405、主节点向检测单元下发分组信息。
当主节点对业务网络中的计算节点分组完成后,就可以生成分组信息,并且通过管理网络下发至每一个检测单元中,使的检测单元根据该分组信息进行组内多个计算节点之间业务数据传输状态的网络探测。
406、检测单元根据分组信息对业务网络进行网络探测。
检测单元在接收到分组信息之后,当对目标pod进行检测时,首先查找目标pod对应计算节点所在的分组,根据该分组确定需要进行探测的目标计算节点,然后逐一探测目标pod与目标计算节点上的pod的数据传输情况。一个优选的方案中,检测单元需要周期性的检测目标pod与目标计算节点上的pod的数据传输情况,每检测一次就生成一个检测结果并向主节点汇报,使得主节点能够实时掌握业务网络数据传输情况。检测的方式具体不做限定,例如检测单元可以通过pin的方式看目标pod与目标计算节点上的pod能否pin通,若能pin通则说明目标pod与目标计算节点上的pod的业务数据传输正常;又或者是目标pod向目标计算节点上的pod发送访问请求,单独能否接收到目标计算节点上的pod返回的请求响应,若能则说明目标pod与目标计算节点上的pod的业务数据传输正常。
407、检测单元通过管理网络上报业务网络探测的检测结果。
当检测单元根据网络探测情况确定好检测结果后,就需要通过管理网络向主节点上报,可选的,检测单元可以定时上报检测结果,使得主节点掌握业务网络的连接情况。
408、主节点根据检测结果判断是否触发目标pod的异地重建。
可以理解的,如果主节点接收到的多个检测结果均显示目标pod在业务网络上与组内的所有计算节点都无法进行业务数据传输时,则说明目标pod在业务网络上发生连接故障,因此主节点就可以认定目标pod对应的计算节点已经不能使用,这样就需要触发目标pod的异地重建。
如果主节点接收到的检测结果中有一个检测结果显示目标pod在业务网络上与组内的某一计算节点可以进行业务数据传输时,那么就说明目标pod并未业务网络上发生连接故障时,所以主节点不触发目标pod的异地重建。
可选的,异地重建是指,将主节点判断为有故障的计算节点上的pod重新调度分配至其他节点上,即在该业务网络对应的其他计算节点上,重建目标pod。
本申请实施例提供的基于容器集群服务的容器组pod重建方法,主节点通过为每个计算节点都部署检测单元,使得检测单元检测业务网络上目标pod的连接状态,然后主节点通过管理网络接收检测单元发送的检测结果,根据该检测结果确定是否异地重建所述目标pod,这样,可以减少因主节点只基于管理网络进行节点故障判断和pod修复而导致的误判问题,更加精准的确定需要异地重建的pod,减少了pod重建的工作量,提供了网络性能。
请参阅图6,本申请实施例提供的一种基于容器集群服务的网元设备的结构示意图。如图6所示,该网元设备600包括:
执行单元601,用于为多个计算节点中的每个计算节点部署检测单元;其中,所述网元设备600与所述多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
接收单元602,用于通过所述管理网络接收所述检测单元发送的检测结果,所述检测结果用于指示所述检测单元对应的pod与目标pod在业务网络上的连接状态;
确定单元603,用于根据所述检测结果,确定是否异地重建所述目标pod。
在一种可能的实施方式中,所述网元设备600还包括发送单元604;
所述确定单元603,还用于确定所述目标pod对应的业务网络上的所有计算节点为目标计算节点;
所述执行单元601,还用于对所述目标计算节点进行分组,确定分组信息;
所述发送单元604,用于向所述检测单元发送所述分组信息,以使得所述检测单元根据所述分组信息检测所述目标pod在所述业务网络上的连接状态。
在一种可能的实施方式中,所述执行单元601,具体用于根据所述目标计算节点对应的物理服务器对所述目标计算节点进行分组;其中,每组包括的目标计算节点属于不同的物理服务器。
在一种可能的实施方式中,所述网元设备600还包括判断单元605;
所述判断单元605用于判断所述目标pod对应的业务网络上是否增加/删除计算节点;
所述执行单元601,还用于若所述判断单元605的判断结果为是,则重新确定所述目标计算节点;对所述目标计算节点重新进行分组,以使得所述检测单元根据新的分组信息检测所述目标pod在所述业务网络上的连接状态。
在一种可能的实施方式中,所述执行单元601还用于当多个所述检测结果均为所述目标pod在所述业务网络上发生连接故障时,触发所述目标pod的异地重建;当所述多个检测结果中的一个检测结果为所述目标pod在所述业务网络上未发生连接故障时,不触发所述目标pod的异地重建。
需要说明的是,上述网元设备600的各个单元的功能,具体可参见前述图4所示的方法实施例中的主节点的实现细节,此处不再赘述。
请参阅图7,本申请实施例提供的一种基于容器集群服务的检测单元700的结构示意图。如图7所示,该检测单元700包括:
确定单元701,用于确定所述检测单元700对应的pod与目标pod之间的业务网络;其中,所述检测单元700由主节点为计算节点部署,所述主节点与多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
处理单元702,用于检测所述检测单元700对应的pod与所述目标pod在所述业务网络上的连接状态,生成检测结果;
发送单元703,用于通过管理网络向主节点发送所述检测结果,以使得所述主节点根据所述检测结果确定所述目标pod是否需要重建。
在一种可能的实施方式中,所述处理单元702具体用于判断所述目标pod与所述检测单元700对应的pod之间的业务数据传输是否正常;若正常,则所述检测单元700确定所述目标pod对应的业务网络未发生故障;若异常,则所述检测单元700确定所述目标pod对应的业务网络发生故障。
在一种可能的实施方式中,所述检测单元700还包括接收单元704;
所述接收单元704,用于接收所述主节点发送的分组信息;
所述处理单元702,具体用于根据所述分组信息判断是否检测所述检测单元700对应的pod与所述目标pod在所述业务网络上的连接状态。
在一种可能的实施方式中,所述处理单元702具体同于周期性的检测所述检测单元700对应的pod与所述目标pod在所述业务网络上的连接状态,生成多个检测结果。
在一种可能的实施方式中,所述发送单元703,具体用于通过管理网络定期向主节点发送所述多个检测结果。
需要说明的是,上述检测单元700的各个单元的功能,具体可参见前述图4所示的方法实施例中的检测单元的实现细节,此处不再赘述。
请参阅图8,为本申请实施例提供的另一种网元设备的结构示意图,该网元设备800包括:处理器801,存储器802,通信接口803。
处理器801、存储器802、通信接口803通过总线相互连接;总线可以是外设部件互连标准(peripheral component interconnect,简称PCI)总线或扩展工业标准结构(extended industry standard architecture,简称EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图8中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
存储器802可以包括易失性存储器(volatile memory),例如随机存取存储器(random-access memory,RAM);存储器也可以包括非易失性存储器(non-volatilememory),例如快闪存储器(flash memory),硬盘(hard disk drive,HDD)或固态硬盘(solid-state drive,SSD);存储器802还可以包括上述种类的存储器的组合。
处理器801可以是中央处理器(central processing unit,CPU),网络处理器(英文:network processor,NP)或者CPU和NP的组合。处理器801还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit,ASIC),可编程逻辑器件(programmable logic device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device,CPLD),现场可编程逻辑门阵列(field-programmable gate array,FPGA),通用阵列逻辑(generic array logic,GAL)或其任意组合。
通信接口803可以为有线通信接口,无线通信接口或其组合,其中,有线通信接口例如可以为以太网接口。以太网接口可以是光接口,电接口或其组合。无线通信接口可以为WLAN接口,蜂窝网络通信接口或其组合等。
可选地,存储器802还可以用于存储程序指令,处理器801调用该存储器802中存储的程序指令,可以执行图4所示方法实施例中的一个或多个步骤,或其中可选的实施方式,使得所述网元设备800实现上述方法中主节点的功能,具体此处不再赘述。
请参阅图9,为本申请实施例提供的另一种检测单元的结构示意图,该检测单元900包括:处理器901,存储器902,通信接口903。
处理器901、存储器902、通信接口903通过总线相互连接;总线可以是外设部件互连标准(peripheral component interconnect,简称PCI)总线或扩展工业标准结构(extended industry standard architecture,简称EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图9中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
存储器902可以包括易失性存储器(volatile memory),例如随机存取存储器(random-access memory,RAM);存储器也可以包括非易失性存储器(non-volatilememory),例如快闪存储器(flash memory),硬盘(hard disk drive,HDD)或固态硬盘(solid-state drive,SSD);存储器902还可以包括上述种类的存储器的组合。
处理器901可以是中央处理器(central processing unit,CPU),网络处理器(英文:network processor,NP)或者CPU和NP的组合。处理器901还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit,ASIC),可编程逻辑器件(programmable logic device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device,CPLD),现场可编程逻辑门阵列(field-programmable gate array,FPGA),通用阵列逻辑(generic array logic,GAL)或其任意组合。
通信接口903可以为有线通信接口,无线通信接口或其组合,其中,有线通信接口例如可以为以太网接口。以太网接口可以是光接口,电接口或其组合。无线通信接口可以为WLAN接口,蜂窝网络通信接口或其组合等。
可选地,存储器902还可以用于存储程序指令,处理器901调用该存储器902中存储的程序指令,可以执行图4所示方法实施例中的一个或多个步骤,或其中可选的实施方式,使得所述检测单元900实现上述方法中检测单元的功能,具体此处不再赘述。
本申请实施例还提供了一种基于容器集群服务的容器组pod重建系统,包括:如图6或图8所示的网元设备,如图7或图9所示的检测单元,所述网元设备向所述检测单元发送分组信息,所述检测单元向所述网元设备发送检测结果。
本申请实施例还提供了一种芯片或者芯片系统,该芯片或者芯片系统包括至少一个处理器和通信接口,通信接口和至少一个处理器通过线路互联,至少一个处理器运行指令或计算机程序,执行图4所示方法实施例中的一个或多个步骤,或其中可选的实施方式,以实现上述方法中主节点的功能。
其中,芯片中的通信接口可以为输入/输出接口、管脚或电路等。
在一种可能的实现中,上述描述的芯片或者芯片系统还包括至少一个存储器,该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元,例如,寄存器、缓存等,也可以是该芯片的存储单元(例如,只读存储器、随机存取存储器等)。
本申请实施例还提供了一种芯片或者芯片系统,该芯片或者芯片系统包括至少一个处理器和通信接口,通信接口和至少一个处理器通过线路互联,至少一个处理器用于运行计算机程序或指令,以进行图4所示实施例的任一种可能的实现方式中任一项所描述的检测单元的执行方法;
其中,芯片中的通信接口可以为输入/输出接口、管脚或电路等。
在一种可能的实现中,本申请中上述描述的芯片或者芯片系统还包括至少一个存储器,该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元,例如,寄存器、缓存等,也可以是该芯片的存储单元(例如,只读存储器、随机存取存储器等)。
本申请实施例还提供了一种计算机存储介质,该计算机存储介质用于储存为上述网元设备或检测单元所用的计算机软件指令,其包括用于执行为网元设备、或检测单元所设计的程序。
该网元设备可以如前述图6或图8所描述的网元设备。
该检测单元可以如前述图7或图9所描述的检测单元。
本申请实施例还提供了一种计算机程序产品,该计算机程序产品包括计算机软件指令,该计算机软件指令可通过处理器进行加载来实现上述图4所示基于容器集群服务的容器组POD重建方法中的流程。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,read-onlymemory)、随机存取存储器(RAM,random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
Claims (24)
1.一种基于容器集群服务的容器组pod重建方法,其特征在于,所述方法包括:
主节点为多个计算节点中的每个计算节点部署检测单元;其中,所述主节点与所述多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
所述主节点通过所述管理网络接收所述检测单元发送的检测结果,所述检测结果用于指示所述检测单元对应的pod与目标pod在业务网络上的连接状态;
所述主节点根据所述检测结果,确定是否异地重建所述目标pod。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
所述主节点确定所述目标pod对应的业务网络上的所有计算节点为目标计算节点;
所述主节点对所述目标计算节点进行分组,确定分组信息;
所述主节点向所述检测单元发送所述分组信息,以使得所述检测单元根据所述分组信息检测所述目标pod在所述业务网络上的连接状态。
3.根据权利要求2所述的方法,其特征在于,所述主节点对所述目标计算节点进行分组,包括:
所述主节点根据所述目标计算节点对应的物理服务器对所述目标计算节点进行分组;其中,每组包括的目标计算节点属于不同的物理服务器。
4.根据权利要求2至3任一项所述的方法,其特征在于,所述方法还包括:
所述主节点判断所述目标pod对应的业务网络上是否增加/删除计算节点;
若增加/删除计算节点,则所述主节点重新确定所述目标计算节点;
所述主节点对所述目标计算节点重新进行分组,以使得所述检测单元根据新的分组信息检测所述目标pod在所述业务网络上的连接状态。
5.根据权利要求1至4任一项所述的方法,其特征在于,所述方法还包括:
当多个所述检测结果均为所述目标pod在所述业务网络上发生连接故障时,所述主节点触发所述目标pod的异地重建;
当多个所述检测结果中的一个检测结果为所述目标pod在所述业务网络上未发生连接故障时,所述主节点不触发所述目标pod的异地重建。
6.一种基于容器集群服务的容器组pod重建方法,其特征在于,所述方法包括:
检测单元确定所述检测单元对应的pod与目标pod之间的业务网络;其中,所述检测单元由主节点为计算节点部署,所述主节点与多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
所述检测单元检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态,生成检测结果;
所述检测单元通过管理网络向主节点发送所述检测结果,以使得所述主节点根据所述检测结果确定所述目标pod是否需要重建。
7.根据权利要求6所述的方法,其特征在于,所述检测单元检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态,生成检测结果,包括:
所述检测单元判断所述目标pod与所述检测单元对应的pod之间的业务数据传输是否正常;
若正常,则所述检测单元确定所述目标pod对应的业务网络未发生故障;
若异常,则所述检测单元确定所述目标pod对应的业务网络发生故障。
8.根据权利要求7所述的方法,其特征在于,所述方法还包括:
所述检测单元接收所述主节点发送的分组信息;
所述检测单元根据所述分组信息判断是否检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态。
9.根据权利要求6至8任一项所述的方法,其特征在于,所述检测单元检测所述目标pod在所述业务网络上的连接状态,生成检测结果,包括:
所述检测单元周期性的检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态,生成多个检测结果。
10.根据权利要求9所述的方法,其特征在于,所述检测单元通过管理网络向主节点发送所述检测结果,包括:
所述检测单元通过管理网络定期向主节点发送所述多个检测结果。
11.一种基于容器集群服务的网元设备,其特征在于,所述网元设备包括:
执行单元,用于为多个计算节点中的每个计算节点部署检测单元;其中,所述网元设备与所述多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
接收单元,用于通过所述管理网络接收所述检测单元发送的检测结果,所述检测结果用于指示所述检测单元对应的pod与目标pod在业务网络上的连接状态;
确定单元,用于根据所述检测结果,确定是否异地重建所述目标pod。
12.根据权利要求11所述的网元设备,其特征在于,所述网元设备还包括发送单元;
所述确定单元,还用于确定所述目标pod对应的业务网络上的所有计算节点为目标计算节点;
所述执行单元,还用于对所述目标计算节点进行分组,确定分组信息;
所述发送单元,用于向所述检测单元发送所述分组信息,以使得所述检测单元根据所述分组信息检测所述目标pod在所述业务网络上的连接状态。
13.根据权利要求12所述的网元设备,其特征在于,所述执行单元,具体用于根据所述目标计算节点对应的物理服务器对所述目标计算节点进行分组;其中,每组包括的目标计算节点属于不同的物理服务器。
14.根据权利要求12至13任一项所述的网元设备,其特征在于,所述网元设备还包括判断单元;
所述判断单元用于判断所述目标pod对应的业务网络上是否增加/删除计算节点;
所述执行单元,还用于若所述判断单元的判断结果为是,则重新确定所述目标计算节点,对所述目标计算节点重新进行分组,以使得所述检测单元根据新的分组信息检测所述目标pod在所述业务网络上的连接状态。
15.根据权利要求11至14任一项所述的网元设备,其特征在于,所述执行单元还用于当多个所述检测结果均为所述目标pod在所述业务网络上发生连接故障时,所述主节点触发所述目标pod的异地重建;当所述多个检测结果中的一个检测结果为所述目标pod在所述业务网络上未发生连接故障时,所述主节点不触发所述目标pod的异地重建。
16.一种基于容器集群服务的检测单元,其特征在于,所述检测单元包括:
确定单元,用于确定所述检测单元对应的pod与目标pod之间的业务网络;其中,所述检测单元由主节点为计算节点部署,所述主节点与多个计算节点通过管理网络相连接,所述每个计算节点都包括至少一个容器组pod,所述容器组pod之间通过业务网络进行业务数据传输;
处理单元,用于检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态,生成检测结果;
发送单元,用于通过管理网络向主节点发送所述检测结果,以使得所述主节点根据所述检测结果确定所述目标pod是否需要重建。
17.根据权利要求16所述的检测单元,其特征在于,所述处理单元具体用于判断所述目标pod与所述检测单元对应的pod之间的业务数据传输是否正常;若正常,则所述检测单元确定所述目标pod对应的业务网络未发生故障;若异常,则所述检测单元确定所述目标pod对应的业务网络发生故障。
18.根据权利要求17所述的检测单元,其特征在于,所述检测单元还包括接收单元;
所述接收单元,用于接收所述主节点发送的分组信息;
所述处理单元,具体用于根据所述分组信息判断是否检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态。
19.根据权利要求16至18任一项所述的检测单元,其特征在于,所述处理单元具体同于周期性的检测所述检测单元对应的pod与所述目标pod在所述业务网络上的连接状态,生成多个检测结果。
20.根据权利要求19所述的检测单元,其特征在于,所述发送单元,具体用于通过管理网络定期向主节点发送所述多个检测结果。
21.一种网元设备,包括:至少一个处理器和通信接口,所述处理器执行如上述权利要求1至权利要求5任意一种可能的实现方式所述的方法。
22.一种检测单元,包括:至少一个处理器、存储器,存储器存储有可在处理器上运行的计算机执行指令,当所述计算机执行指令被所述处理器执行时,所述处理器执行如上述权利要求6至权利要求10任意一种可能的实现方式所述的方法。
23.一种基于容器集群服务的容器组pod重建系统,其特征在于,包括:网元设备和检测单元,所述网元设备为上述权利要求11至15任一项所述的网元设备;所述检测单元为上述权利要求16至20任一项所述的检测单元。
24.一种存储一个或多个计算机执行指令的计算机可读存储介质,其特征在于,当所述计算机执行指令被处理器执行时,所述处理器执行如上述权利要求1至10任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010616265.XA CN113872997B (zh) | 2020-06-30 | 2020-06-30 | 基于容器集群服务的容器组pod重建方法及相关设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010616265.XA CN113872997B (zh) | 2020-06-30 | 2020-06-30 | 基于容器集群服务的容器组pod重建方法及相关设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113872997A true CN113872997A (zh) | 2021-12-31 |
CN113872997B CN113872997B (zh) | 2022-08-26 |
Family
ID=78981481
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010616265.XA Active CN113872997B (zh) | 2020-06-30 | 2020-06-30 | 基于容器集群服务的容器组pod重建方法及相关设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113872997B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115208895A (zh) * | 2022-07-19 | 2022-10-18 | 中软航科数据科技(珠海横琴)有限公司 | 一种用于区块链技术的自动化组网方法及系统 |
CN115277652A (zh) * | 2022-06-29 | 2022-11-01 | 北京百度网讯科技有限公司 | 基于推理服务的流媒体处理方法、装置、电子设备 |
CN115665036A (zh) * | 2022-10-14 | 2023-01-31 | 郑州浪潮数据技术有限公司 | 一种路由策略故障处理方法、装置及介质 |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020091805A1 (en) * | 2000-01-14 | 2002-07-11 | Microsoft Corporation | Method and system for dynamically purposing a computing device |
WO2012048092A2 (en) * | 2010-10-08 | 2012-04-12 | Salesforce.Com, Inc. | Structured data in a business networking feed |
CN108769100A (zh) * | 2018-04-03 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种基于kubernetes容器数量弹性伸缩的实现方法及其装置 |
CN109117265A (zh) * | 2018-07-12 | 2019-01-01 | 北京百度网讯科技有限公司 | 在集群中调度作业的方法、装置、设备及存储介质 |
US20190103993A1 (en) * | 2017-10-02 | 2019-04-04 | Nicira, Inc. | Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external saas provider |
CN109831500A (zh) * | 2019-01-30 | 2019-05-31 | 无锡华云数据技术服务有限公司 | Kubernetes集群中配置文件与Pod的同步方法 |
CN110287029A (zh) * | 2019-06-27 | 2019-09-27 | 中国—东盟信息港股份有限公司 | 一种基于kubernetes容器资源动态调整的方法 |
CN110377395A (zh) * | 2019-07-03 | 2019-10-25 | 无锡华云数据技术服务有限公司 | 一种Kubernetes集群中的Pod迁移方法 |
CN110531987A (zh) * | 2019-07-30 | 2019-12-03 | 平安科技(深圳)有限公司 | 基于Kubernetes集群的管理方法、装置及计算机可读存储介质 |
CN111045821A (zh) * | 2019-12-06 | 2020-04-21 | 北京浪潮数据技术有限公司 | 一种容器调度方法、装置、容器调度器及可读存储介质 |
CN111124604A (zh) * | 2019-12-05 | 2020-05-08 | 北京金山云网络技术有限公司 | 分配容器组pod IP地址的方法、装置、设备及存储介质 |
CN111258609A (zh) * | 2020-01-19 | 2020-06-09 | 北京百度网讯科技有限公司 | Kubernetes集群的升级方法、装置、电子设备和介质 |
CN111290767A (zh) * | 2020-01-20 | 2020-06-16 | 中国科学院计算技术研究所 | 具有业务快速恢复功能的容器组更新方法及系统 |
CN111324453A (zh) * | 2020-01-23 | 2020-06-23 | 天津大学 | 用于区块链平台资源调度的方法 |
-
2020
- 2020-06-30 CN CN202010616265.XA patent/CN113872997B/zh active Active
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020091805A1 (en) * | 2000-01-14 | 2002-07-11 | Microsoft Corporation | Method and system for dynamically purposing a computing device |
WO2012048092A2 (en) * | 2010-10-08 | 2012-04-12 | Salesforce.Com, Inc. | Structured data in a business networking feed |
US20190103993A1 (en) * | 2017-10-02 | 2019-04-04 | Nicira, Inc. | Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external saas provider |
CN108769100A (zh) * | 2018-04-03 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种基于kubernetes容器数量弹性伸缩的实现方法及其装置 |
CN109117265A (zh) * | 2018-07-12 | 2019-01-01 | 北京百度网讯科技有限公司 | 在集群中调度作业的方法、装置、设备及存储介质 |
CN109831500A (zh) * | 2019-01-30 | 2019-05-31 | 无锡华云数据技术服务有限公司 | Kubernetes集群中配置文件与Pod的同步方法 |
CN110287029A (zh) * | 2019-06-27 | 2019-09-27 | 中国—东盟信息港股份有限公司 | 一种基于kubernetes容器资源动态调整的方法 |
CN110377395A (zh) * | 2019-07-03 | 2019-10-25 | 无锡华云数据技术服务有限公司 | 一种Kubernetes集群中的Pod迁移方法 |
CN110531987A (zh) * | 2019-07-30 | 2019-12-03 | 平安科技(深圳)有限公司 | 基于Kubernetes集群的管理方法、装置及计算机可读存储介质 |
CN111124604A (zh) * | 2019-12-05 | 2020-05-08 | 北京金山云网络技术有限公司 | 分配容器组pod IP地址的方法、装置、设备及存储介质 |
CN111045821A (zh) * | 2019-12-06 | 2020-04-21 | 北京浪潮数据技术有限公司 | 一种容器调度方法、装置、容器调度器及可读存储介质 |
CN111258609A (zh) * | 2020-01-19 | 2020-06-09 | 北京百度网讯科技有限公司 | Kubernetes集群的升级方法、装置、电子设备和介质 |
CN111290767A (zh) * | 2020-01-20 | 2020-06-16 | 中国科学院计算技术研究所 | 具有业务快速恢复功能的容器组更新方法及系统 |
CN111324453A (zh) * | 2020-01-23 | 2020-06-23 | 天津大学 | 用于区块链平台资源调度的方法 |
Non-Patent Citations (2)
Title |
---|
ANDREY A. AKSENOV ET.AL: "Investigating the Problems of Ship Propulsion on a Supercomputer", 《2017 IVANNIKOV ISPRAS OPEN CONFERENCE (ISPRAS)》 * |
张庆海等: "面向网络化指挥控制系统的运维管理软件设计", 《指挥信息系统与技术》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115277652A (zh) * | 2022-06-29 | 2022-11-01 | 北京百度网讯科技有限公司 | 基于推理服务的流媒体处理方法、装置、电子设备 |
CN115277652B (zh) * | 2022-06-29 | 2024-03-22 | 北京百度网讯科技有限公司 | 基于推理服务的流媒体处理方法、装置、电子设备 |
CN115208895A (zh) * | 2022-07-19 | 2022-10-18 | 中软航科数据科技(珠海横琴)有限公司 | 一种用于区块链技术的自动化组网方法及系统 |
CN115665036A (zh) * | 2022-10-14 | 2023-01-31 | 郑州浪潮数据技术有限公司 | 一种路由策略故障处理方法、装置及介质 |
Also Published As
Publication number | Publication date |
---|---|
CN113872997B (zh) | 2022-08-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113872997B (zh) | 基于容器集群服务的容器组pod重建方法及相关设备 | |
US10558517B2 (en) | Proactive cloud orchestration | |
Herker et al. | Data-center architecture impacts on virtualized network functions service chain embedding with high availability requirements | |
JP5458308B2 (ja) | 仮想計算機システム、仮想計算機システムの監視方法及びネットワーク装置 | |
RU2640724C1 (ru) | Способ устранения неисправностей, устройство и система, основанные на виртуализации сетевых функций | |
KR100658913B1 (ko) | 광범위한 클러스터들에서의 노드 장애에 대비하여 원격액세스가능 자원들을 계속적으로 모니터링하는 확장 방법 | |
US8589919B2 (en) | Traffic forwarding for virtual machines | |
CN106664216B (zh) | 一种切换vnf的方法和装置 | |
CN107544839B (zh) | 虚拟机迁移系统、方法及装置 | |
US8615676B2 (en) | Providing first field data capture in a virtual input/output server (VIOS) cluster environment with cluster-aware vioses | |
US20210208922A1 (en) | Seamless virtual standard switch to virtual distributed switch migration for hyper-converged infrastructure | |
CA2808239C (en) | Determining equivalent subsets of agents to gather information for a fabric | |
CN110661647A (zh) | 一种生命周期管理方法及装置 | |
CN103368768A (zh) | 混合云环境中具有启发式监视的自动缩放网络覆盖 | |
CN108347339B (zh) | 一种业务恢复方法及装置 | |
JP2021530067A (ja) | データセンターハードウェアインスタンスネットワークのトレーニング | |
KR102036731B1 (ko) | 가상화 네트워크 기능 클러스터링 구성 시스템 및 방법 | |
CN110580198B (zh) | OpenStack计算节点自适应切换为控制节点的方法及装置 | |
Limrungsi et al. | Providing reliability as an elastic service in cloud computing | |
WO2016082078A1 (zh) | 路径管理的系统、装置和方法 | |
CN111935244B (zh) | 一种业务请求处理系统及超融合一体机 | |
CN108512753B (zh) | 一种集群文件系统中消息传输的方法及装置 | |
CN115705198A (zh) | 运行容器组的节点,容器组的管理系统和方法 | |
CN107360015B (zh) | 切换共享存储的方法和设备 | |
US10367711B2 (en) | Protecting virtual computing instances from network failures |
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 |