CN115665036A - 一种路由策略故障处理方法、装置及介质 - Google Patents

一种路由策略故障处理方法、装置及介质 Download PDF

Info

Publication number
CN115665036A
CN115665036A CN202211259615.7A CN202211259615A CN115665036A CN 115665036 A CN115665036 A CN 115665036A CN 202211259615 A CN202211259615 A CN 202211259615A CN 115665036 A CN115665036 A CN 115665036A
Authority
CN
China
Prior art keywords
routing
service
target information
routing policy
routing strategy
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.)
Pending
Application number
CN202211259615.7A
Other languages
English (en)
Inventor
丁凯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhengzhou Inspur Data Technology Co Ltd
Original Assignee
Zhengzhou Inspur Data Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Zhengzhou Inspur Data Technology Co Ltd filed Critical Zhengzhou Inspur Data Technology Co Ltd
Priority to CN202211259615.7A priority Critical patent/CN115665036A/zh
Publication of CN115665036A publication Critical patent/CN115665036A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种路由策略故障处理方法、装置及介质,涉及云计算领域。该方法包括:获取容器云平台服务以及对应的服务类型;根据服务类型确定服务的地址以及端口;根据地址以及端口判断服务对应的路由策略是否存在;若否,则根据预设的路由规则对路由策略进行重建。由此可见,该方法中根据服务类型、服务地址以及端口信息来检测路由策略是否存在,在路由策略不存在的情况下,根据预设的路由规则实现了对路由策略的重建,使得容器云平台能够正常运行。此外,本申请还提供一种路由策略故障处理装置以及计算机可读存储介质,与上述提到的路由策略故障处理方法具有相同或相对应的技术特征,效果同上。

Description

一种路由策略故障处理方法、装置及介质
技术领域
本申请涉及云计算领域,特别是涉及一种路由策略故障处理方法、装置及介质。
背景技术
容器云平台K8S(K8S是Kubernetes的简称)系统可运行各种场景下的业务应用,如web应用,大数据计算任务等。K8S容器平台的正常运行依赖各组件之间的稳定运行,稳定的计算平台可以保障业务应用正常提供服务。基于K8S的容器应用工作负载主要分为有状态和无状态负载,无论哪种工作负载,pod之间都需要进行通信,pod对外提供服务后,外部也需要访问容器服务。其中pod之间通信一般通过ClusterIP类型的Service进行通信,如果需要集群外访问容器服务,则通过Node IP加端口的方式访问。不论是pod之间通信还是集群外访问服务,都需要依赖路由策略,保证流量能够正常转发。
但在实际场景中,经常因为宕机或etcd脑裂等问题的发生导致路由策略丢失或无法及时更新,表现为pod之间无法正常通信,或者集群外无法正常访问容器服务。
由此可见,如何对路由策略进行故障检查以及恢复是本领域人员亟需解决的技术问题。
发明内容
本申请的目的是提供一种路由策略故障处理方法、装置及介质,用于对路由策略进行故障检查以及恢复。
为解决上述技术问题,本申请提供一种路由策略故障处理方法,包括:
获取容器云平台服务以及对应的服务类型;
根据所述服务类型确定所述服务的地址以及端口;
根据所述地址以及所述端口判断所述服务对应的路由策略是否存在;
若否,则根据预设的路由规则对所述路由策略进行重建。
优选地,所述预设的路由规则根据实际的业务场景进行确定。
优选地,所述获取容器云平台服务以及对应的服务类型包括:
获取所有所述容器云平台的运行状态;
在出现pod间无法通信或者集群外无法正常访问所述容器云平台服务的情况下,确定故障的pod;
根据所述故障的pod获取所述容器云平台服务以及对应的所述服务类型。
优选地,在根据所述地址以及所述端口确定所述服务对应的所述路由策略存在的情况下,所述方法包括:
获取当前pod的第一目标信息以及所述路由策略中的第二目标信息;
判断所述第一目标信息与所述第二目标信息是否相同;
若否,则根据所述第一目标信息对所述第二目标信息进行更新。
优选地,在所述根据预设的路由规则对所述路由策略进行重建之后,所述方法还包括:
获取当前pod的第三目标信息以及所述路由策略中的第四目标信息;
判断所述第三目标信息与所述第四目标信息是否相同;
若否,则根据所述第三目标信息对所述第四目标信息进行更新。
优选地,在所述根据所述第一目标信息对所述第二目标信息进行更新或所述根据所述第三目标信息对所述第四目标信息进行更新之后,所述方法还包括:
自完成更新所述第二目标信息或所述第四目标信息开始,在第一预设时间内返回所述获取所有所述容器云平台的运行状态的步骤。
优选地,在根据所述地址以及所述端口确定所述服务对应的所述路由策略不存在的情况下,所述方法还包括:
自判断出所述路由策略不存在的情况下,在第二预设时间内输出用于表征所述路由策略不存在的第一提示信息;
对应地,在根据所述预设的路由规则对所述路由策略完成重建之后,所述方法还包括:
自完成对所述路由策略重建开始,在第三预设时间内输出用于表征所述路由策略完成重建的第二提示信息。
为了解决上述技术问题,本申请还提供一种路由策略故障处理装置,包括:
获取模块,用于获取容器云平台服务以及对应的服务类型;
确定模块,用于根据所述服务类型确定所述服务的地址以及端口;
判断模块,用于根据所述地址以及所述端口判断所述服务对应的路由策略是否存在;若是,则触发重建模块;
重建模块,用于根据预设的路由规则对所述路由策略进行重建。
为了解决上述技术问题,本申请还提供一种路由策略故障处理装置,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现上述的路由策略故障处理方法的步骤。
为了解决上述技术问题,本申请还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述的路由策略故障处理方法的步骤。
本申请所提供的一种路由策略故障处理方法,包括:获取容器云平台服务以及对应的服务类型;根据服务类型确定服务的地址以及端口;根据地址以及端口判断服务对应的路由策略是否存在;若否,则根据预设的路由规则对路由策略进行重建。由此可见,该方法中根据服务类型、服务地址以及端口信息来检测路由策略是否存在,在路由策略不存在的情况下,根据预设的路由规则实现了对路由策略的重建,使得容器云平台能够正常运行。
此外,本申请还提供一种路由策略故障装置以及计算机可读存储介质,与上述提到的路由策略故障处理方法具有相同或相对应的技术特征,效果同上。
附图说明
为了更清楚地说明本申请实施例,下面将对实施例中所需要使用的附图做简单的介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种路由策略故障处理方法的流程图;
图2为本申请的一实施例提供的路由策略故障处理装置的结构图;
图3为本申请另一实施例提供的路由策略故障处理装置的结构图;
图4为本申请实施例提供的一种基于K8S的容器应用路由策略故障检查与恢复的方法的流程图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下,所获得的所有其他实施例,都属于本申请保护范围。
本申请的核心是提供一种路由策略故障处理方法、装置及介质,用于对路由策略进行故障检查以及恢复。
K8S是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。在Kubernetes中,最小的管理元素是Pod,Pod是最小的管理、创建应用的最小调度单元,一个Pod中可以包含多个容器。Service是一种可以访问Pod逻辑分组的策略,Service通常是通过Label Selector访问Pod组。Service类型可以是ClusterIP、NodePort等。ClusterIP是Service的网际互连协议(Internet Protocol,IP)地址,此为虚拟IP地址。外部网络无法ping通,只有kubernetes集群内部访问使用,NodePort:可以是物理机的IP,也可能是虚拟机IP,每个Service都会在Node节点上开通一个端口,外部可以通过NodePort:NodePort即可访问Service里的Pod。
基于K8S的容器应用工作负载主要分为有状态和无状态负载,无论哪种工作负载,pod之间都需要进行通信,pod对外提供服务后,外部也需要访问容器服务。其中pod之间通信一般通过ClusterIP类型的Service进行通信,如果需要集群外访问容器服务,则通过Node IP加端口的方式访问。不论是pod之间通信还是集群外访问服务,都需要依赖路由策略,保证流量能够正常转发路由策略是一种比基于目标网络进行路由更加灵活的数据包路由转发机制。应用了路由策略,路由器将通过路由图决定如何对需要路由的数据包进行处理,路由图决定了一个数据包的下一跳转发路由器。在实际中,可能会出现路由策略丢失的情况,导致业务中断,影响用户体验。故而,本申请中根据服务器类型、地址以及端口实现对路由策略故障的诊断以及故障的恢复,尽可能地保障容器云平台能够正常运行。需要说明的是,本申请的路由策略检测和恢复的方法除了适用于ClusterIP和NodePort两种类型外,还适用于更多Service类型的路由策略检查及恢复。
为了使本技术领域的人员更好地理解本申请方案,下面结合附图和具体实施方式对本申请作进一步的详细说明。图1为本申请实施例提供的一种路由策略故障处理方法的流程图,如图1所示,该方法包括:
S10:获取容器云平台服务以及对应的服务类型。
S11:根据服务类型确定服务的地址以及端口。
容器云平台服务包含多种服务类型,如ClusterIP、NodePort等。当容器服务Service类型为ClusterIP时,根据故障pod的命名空间及名字,执行K8S命令获取到该pod对应的Service,通过shell脚本获取到该Service的IP及容器服务端口。当容器服务Service类型为NodePort时,根据故障pod的命名空间及名字,执行K8S命令获取到该pod对应的Service,通过shell脚本获取的对应的NodeIP及映射到宿主机的端口。
S12:根据地址以及端口判断服务对应的路由策略是否存在;若否,则进入步骤S13。
S13:根据预设的路由规则对路由策略进行重建。
在根据地址以及端口判断服务对应的路由策略时,具体是根据iptables命令查询是否有该Service的IP对应的路由策略。由于路由策略是实现pod之间通信或者集群外访问服务的关键,故而,在判断出没有该Service的IP对应的路由策略的情况下,需要对路由策略进行恢复。
在对路由策略进行恢复时,根据预设的路由规则对路由策略进行重建。对于预设的路由规则不作限定,通常情况下,预设的路由规则根据实际的业务场景进行确定。如,iptables是运行在用户空间的应用软件,通过控制Linux内核netfilter模块,来管理网络数据包的处理和转发,查询非容器管理组件添加的IPtables规则:如果查询出数据,需要进行具体的分析,避免对容器正常通信造成影响;Calico生成的IPtables规则都带有cali;Calico生成的路由规则都带有cali和proto bird。
本实施例所提供的路由策略故障处理方法,包括:获取容器云平台服务以及对应的服务类型;根据服务类型确定服务的地址以及端口;根据地址以及端口判断服务对应的路由策略是否存在;若否,则根据预设的路由规则对路由策略进行重建。由此可见,该方法中根据服务类型、服务地址以及端口信息来检测路由策略是否存在,在路由策略不存在的情况下,根据预设的路由规则实现了对路由策略的重建,使得容器云平台能够正常运行。
在实施中,若在pod正常或异常的情况下,均对路由策略是否故障进行检测,则可能会影响系统的性能。因此,优选的实施方式是,获取容器云平台服务以及对应的服务类型包括:
获取所有容器云平台的运行状态;
在出现pod间无法通信或者集群外无法正常访问容器云平台服务的情况下,确定故障的pod;
根据故障的pod获取容器云平台服务以及对应的服务类型。
调用K8S接口获取所有容器运行状态,当出现pod无法正常通信或者集群外无法正常访问服务时,及时发现故障pod,根据故障pod的基本信息判断Service类型及相关IP和端口,以便路由策略的检查。
本实施例所提供的在出现pod间无法通信或者集群外无法正常访问容器云平台服务的情况下,才开始获取容器云平台服务以及对应的服务类型,相比于在pod正常的情况下,依然对路由策略进行检测的方法,本实施例仅在pod故障的情况下对路由策略进行检查的方法能够减少系统在pod正常的情况下对路由策略检测的耗时以及提高系统的性能。
实际中,根据地址以及端口确定出存在路由策略的情况下,可能会存在pod中的目标信息与路由策略中目标信息不一致的情况,导致不能根据正确的路由策略进行通信,因此,优选的实施方式是,在根据地址以及端口确定服务对应的路由策略存在的情况下,路由策略故障处理方法包括:
获取当前pod的第一目标信息以及路由策略中的第二目标信息;
判断第一目标信息与第二目标信息是否相同;
若否,则根据第一目标信息对第二目标信息进行更新。
本实施例所提供的在根据地址以及端口确定服务存在对应的路由策略的情况下,若当前pod的目标信息与路由策略中的目标信息不相同,则对路由策略中的信息进行更新,使得路由策略中的目标信息与当前pod的目标信息相同,从而使得pod之间或者集群外访问服务能够根据最新的路由策略进行通信。
上述实施例中,是在根据地址以及端口确定出存在路由策略的情况下,对当前pod中的目标信息与路由策略中的目标信息进行一致性的判断,并且对路由策略进行更新。实际中,在对路由策略进行重建之后,也可能会存在当前pod中的目标信息与路由策略中的目标信息不一致的情况,因此,优选的实施方式是,在根据预设的路由规则对路由策略进行重建之后,路由策略故障处理方法还包括:
获取当前pod的第三目标信息以及路由策略中的第四目标信息;
判断第三目标信息与第四目标信息是否相同;
若否,则根据第三目标信息对第四目标信息进行更新。
本实施例所提供的在对路由策略进行重建之后,根据当前pod中的目标信息与路由策略中的目标信息进行一致性判断,使得能够尽可能地保证路由策略中的目标信息是最新的,使pod之间或集群外访问服务能够正常进行。
实际中,在对路由策略中的信息进行更新之后,可能会受到干扰,导致路由策略中的信息发生变化,因此,优选的实施方式是,在根据第一目标信息对第二目标信息进行更新或根据第三目标信息对第四目标信息进行更新之后,路由策略故障处理方法还包括:
自完成更新第二目标信息或第四目标信息开始,在第一预设时间内返回获取所有容器云平台的运行状态的步骤。
对于第一预设时间的值不作限定,根据实际情况确定。本实施例所提供的在对路由策略进行更新之后,继续对路由策略进行检测以及恢复,使得pod之间或集群外访问服务能够正常进行。
为了方便用户了解到对路由策略的处理情况,优选的实施方式是,在根据地址以及端口确定服务对应的路由策略不存在的情况下,路由策略故障处理方法还包括:
自判断出路由策略不存在的情况下,在第二预设时间内输出用于表征路由策略不存在的第一提示信息;
对应地,在根据预设的路由规则对路由策略完成重建之后,路由策略故障处理方法还包括:
自完成对路由策略重建开始,第三预设时间内输出用于表征路由策略完成重建的第二提示信息。
本实施例中列出了两种情况下,包含在检测到路由策略不存在的情况下以及在对路由策略完成重建的情况下,分别输出对应的提示信息。对于第二时间以及第三预设时间的值不作限定,根据实际情况确定。但是,为了能够及时在路由策略出现故障的情况下,及时对路由策略进行恢复以及方便用户即时了解到路由策略的检测及恢复情况,选取的第二预设时间的值、第三预设时间的值通常自判断出路由策略不存在的情况下,在较短的时间内输出用于表征路由策略不存在的提示信息;自完成对路由策略的重建开始,在较短的时间内输出用于表征路由策略完成重建的提示信息。
对于第一提示信息以及第二提示信息的提示方式以及提示的内容等不作限定。由于第一提示信息与第二提示信息提示不同的内容,因此,对于第一提示信息以及第二提示信息采用不同的提示方式、提示内容等,以便将第一提示信息与第二提示信息区分开。
本实施例所提供的在对路由策略检测和恢复的过程中,通过提示信息使得用户能够及时了解到路由策略的检测和恢复的情况,提高用户体验感。
在上述实施例中,对于路由策略故障处理方法进行了详细描述,本申请还提供路由策略故障处理装置对应的实施例。需要说明的是,本申请从两个角度对装置部分的实施例进行描述,一种是基于功能模块的角度,另一种是基于硬件的角度。
图2为本申请的一实施例提供的路由策略故障处理装置的结构图。本实施例基于功能模块的角度,包括:
获取模块10,用于获取容器云平台服务以及对应的服务类型;
确定模块11,用于根据所述服务类型确定所述服务的地址以及端口;
判断模块12,用于根据所述地址以及所述端口判断所述服务对应的路由策略是否存在;若是,则触发重建模块13;
重建模块13,用于根据预设的路由规则对所述路由策略进行重建。
由于装置部分的实施例与方法部分的实施例相互对应,因此装置部分的实施例请参见方法部分的实施例的描述,这里暂不赘述。
本实施例所提供的路由策略故障处理装置,通过获取模块获取容器云平台服务以及对应的服务类型;通过确定模块根据所述服务类型确定所述服务的地址以及端口;通过判断模块根据所述地址以及所述端口判断所述服务对应的路由策略是否存在;若是,则触发重建模块根据预设的路由规则对所述路由策略进行重建。由此可见,该装置中根据服务类型、服务地址以及端口信息来检测路由策略是否存在,在路由策略不存在的情况下,根据预设的路由规则实现了对路由策略的重建,使得容器云平台能够正常运行。
图3为本申请另一实施例提供的路由策略故障处理装置的结构图。本实施例基于硬件角度,如图3所示,路由策略故障处理装置包括:
存储器20,用于存储计算机程序;
处理器21,用于执行计算机程序时实现如上述实施例中所提到的路由策略故障处理的方法的步骤。
本实施例提供的路由策略故障处理装置可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。
其中,处理器21可以包括一个或多个处理核心,比如4核心处理器、8核心处理器等。处理器21可以采用数字信号处理器(Digital Signal Processor,DSP)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)、可编程逻辑阵列(Programmable LogicArray,PLA)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器,主处理器是用于对在唤醒状态下的数据进行处理的处理器,也称中央处理器(CentralProcessing Unit,CPU);协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中,处理器21可以集成有图形处理器(Graphics Processing Unit,GPU),GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中,处理器21还可以包括人工智能(Artificial Intelligence,AI)处理器,该AI处理器用于处理有关机器学习的计算操作。
存储器20可以包括一个或多个计算机可读存储介质,该计算机可读存储介质可以是非暂态的。存储器20还可包括高速随机存取存储器,以及非易失性存储器,比如一个或多个磁盘存储设备、闪存存储设备。本实施例中,存储器20至少用于存储以下计算机程序201,其中,该计算机程序被处理器21加载并执行之后,能够实现前述任一实施例公开的路由策略故障处理方法的相关步骤。另外,存储器20所存储的资源还可以包括操作系统202和数据203等,存储方式可以是短暂存储或者永久存储。其中,操作系统202可以包括Windows、Unix、Linux等。数据203可以包括但不限于上述所提到的路由策略故障处理方法所涉及到的数据等。
在一些实施例中,路由策略故障处理装置还可包括有显示屏22、输入输出接口23、通信接口24、电源25以及通信总线26。
本领域技术人员可以理解,图3中示出的结构并不构成对路由策略故障处理装置的限定,可以包括比图示更多或更少的组件。
本申请实施例提供的路由策略故障处理装置,包括存储器和处理器,处理器在执行存储器存储的程序时,能够实现如下方法:路由策略故障处理方法,效果同上。
最后,本申请还提供一种计算机可读存储介质对应的实施例。计算机可读存储介质上存储有计算机程序,计算机程序被处理器执行时实现如上述方法实施例中记载的步骤。
可以理解的是,如果上述实施例中的方法以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请提供的计算机可读存储介质包括上述提到的路由策略故障处理方法,效果同上。
为了使本技术领域的人员更好地理解本申请方案,下面结合附图和具体实施方式对本申请作进一步的详细说明。图4为本申请实施例提供的一种基于K8S的容器应用路由策略故障检查与恢复的方法的流程图。如图4所示,该方法包括:
S14:任务开始执行;
S15:组件服务安装、启动;
S16:检测到故障pod;
S17:获取Service类型;
S18:进行路由策略检查;
S19:判断路由策略是否存在,若是,则进入步骤S20;若否,则进入步骤S21;
S20:路由策略更新;
S21:路由策略重建。
在基于K8S的容器应用路由策略故障检查与恢复的方法被应用时,前提是有一套K8S容器平台,可以提供创建容器应用需要的容器云平台环境,另外需要一台物理服务器或者虚拟机,服务器能够进行路由策略故障检查与恢复。基础环境完成部署配置以后,用户将该方法部署在服务器后,当出现pod间无法通信或者集群外无法正常访问容器服务时,自动进行Service类型判断,并获取到Service的相关参数,进行路由策略的重建或者更新。具体地,通过调用K8S接口获取所有容器运行状态,当出现pod无法正常通信或者集群外无法正常访问服务时,及时发现故障pod;根据故障pod的基本信息判断Service类型及相关IP和端口,以便路由策略的检查;根据获取的Service信息,自动检查路由策略并进行重建或者更新操作。
由此可见,该基于K8S的容器应用路由策略故障检查与恢复的方法实现了对实现了容器应用的路由策略故障发现与恢复功能,提高了容器应用故障时的恢复效率,减小了运维人员的时间成本,保障了业务的稳定性。
以上对本申请所提供的一种路由策略故障处理方法、装置及介质进行了详细介绍。说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以对本申请进行若干改进和修饰,这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是,在本说明书中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种路由策略故障处理方法,其特征在于,包括:
获取容器云平台服务以及对应的服务类型;
根据所述服务类型确定所述服务的地址以及端口;
根据所述地址以及所述端口判断所述服务对应的路由策略是否存在;
若否,则根据预设的路由规则对所述路由策略进行重建。
2.根据权利要求1所述的路由策略故障处理方法,其特征在于,所述预设的路由规则根据实际的业务场景进行确定。
3.根据权利要求1所述的路由策略故障处理方法,其特征在于,所述获取容器云平台服务以及对应的服务类型包括:
获取所有所述容器云平台的运行状态;
在出现pod间无法通信或者集群外无法正常访问所述容器云平台服务的情况下,确定故障的pod;
根据所述故障的pod获取所述容器云平台服务以及对应的所述服务类型。
4.根据权利要求3所述的路由策略故障处理方法,其特征在于,在根据所述地址以及所述端口确定所述服务对应的所述路由策略存在的情况下,所述方法包括:
获取当前pod的第一目标信息以及所述路由策略中的第二目标信息;
判断所述第一目标信息与所述第二目标信息是否相同;
若否,则根据所述第一目标信息对所述第二目标信息进行更新。
5.根据权利要求4所述的路由策略故障处理方法,其特征在于,在所述根据预设的路由规则对所述路由策略进行重建之后,所述方法还包括:
获取当前pod的第三目标信息以及所述路由策略中的第四目标信息;
判断所述第三目标信息与所述第四目标信息是否相同;
若否,则根据所述第三目标信息对所述第四目标信息进行更新。
6.根据权利要求5所述的路由策略故障处理方法,其特征在于,在所述根据所述第一目标信息对所述第二目标信息进行更新或所述根据所述第三目标信息对所述第四目标信息进行更新之后,所述方法还包括:
自完成更新所述第二目标信息或所述第四目标信息开始,在第一预设时间内返回所述获取所有所述容器云平台的运行状态的步骤。
7.根据权利要求1至6任意一项所述的路由策略故障处理方法,其特征在于,在根据所述地址以及所述端口确定所述服务对应的所述路由策略不存在的情况下,所述方法还包括:
自判断出所述路由策略不存在的情况下,在第二预设时间内输出用于表征所述路由策略不存在的第一提示信息;
对应地,在根据所述预设的路由规则对所述路由策略完成重建之后,所述方法还包括:
自完成对所述路由策略重建开始,在第三预设时间内输出用于表征所述路由策略完成重建的第二提示信息。
8.一种路由策略故障处理装置,其特征在于,包括:
获取模块,用于获取容器云平台服务以及对应的服务类型;
确定模块,用于根据所述服务类型确定所述服务的地址以及端口;
判断模块,用于根据所述地址以及所述端口判断所述服务对应的路由策略是否存在;若是,则触发重建模块;
重建模块,用于根据预设的路由规则对所述路由策略进行重建。
9.一种路由策略故障处理装置,其特征在于,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如权利要求1至7任一项所述的路由策略故障处理方法的步骤。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的路由策略故障处理方法的步骤。
CN202211259615.7A 2022-10-14 2022-10-14 一种路由策略故障处理方法、装置及介质 Pending CN115665036A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211259615.7A CN115665036A (zh) 2022-10-14 2022-10-14 一种路由策略故障处理方法、装置及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211259615.7A CN115665036A (zh) 2022-10-14 2022-10-14 一种路由策略故障处理方法、装置及介质

Publications (1)

Publication Number Publication Date
CN115665036A true CN115665036A (zh) 2023-01-31

Family

ID=84987669

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211259615.7A Pending CN115665036A (zh) 2022-10-14 2022-10-14 一种路由策略故障处理方法、装置及介质

Country Status (1)

Country Link
CN (1) CN115665036A (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632057A (zh) * 2017-03-17 2018-10-09 华为技术有限公司 一种云计算服务器的故障恢复方法、装置及管理系统
CN111786886A (zh) * 2020-06-30 2020-10-16 京东数字科技控股有限公司 一种消息处理方法、装置、系统、电子设备及存储介质
CN111885005A (zh) * 2020-06-29 2020-11-03 济南浪潮数据技术有限公司 一种容器云平台服务通信方法、装置、设备及介质
CN113872997A (zh) * 2020-06-30 2021-12-31 华为技术有限公司 基于容器集群服务的容器组pod重建方法及相关设备
CN114416284A (zh) * 2021-12-24 2022-04-29 北京百度网讯科技有限公司 分布式作业系统控制方法、装置、设备、介质及程序产品
CN114691395A (zh) * 2020-12-25 2022-07-01 国信君和(北京)科技有限公司 一种故障处理方法、装置、电子设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632057A (zh) * 2017-03-17 2018-10-09 华为技术有限公司 一种云计算服务器的故障恢复方法、装置及管理系统
CN111885005A (zh) * 2020-06-29 2020-11-03 济南浪潮数据技术有限公司 一种容器云平台服务通信方法、装置、设备及介质
CN111786886A (zh) * 2020-06-30 2020-10-16 京东数字科技控股有限公司 一种消息处理方法、装置、系统、电子设备及存储介质
CN113872997A (zh) * 2020-06-30 2021-12-31 华为技术有限公司 基于容器集群服务的容器组pod重建方法及相关设备
CN114691395A (zh) * 2020-12-25 2022-07-01 国信君和(北京)科技有限公司 一种故障处理方法、装置、电子设备及存储介质
CN114416284A (zh) * 2021-12-24 2022-04-29 北京百度网讯科技有限公司 分布式作业系统控制方法、装置、设备、介质及程序产品

Similar Documents

Publication Publication Date Title
US10402293B2 (en) System for virtual machine risk monitoring
US10356214B2 (en) Composing monolithic applications based on multi-container applications
US9454392B2 (en) Routing data packets between virtual machines using shared memory without copying the data packet
CN108255497B (zh) 一种应用的部署方法及装置
CN112130965A (zh) 部署分布式容器编排管理集群的方法、设备及存储介质
US11805004B2 (en) Techniques and interfaces for troubleshooting datacenter networks
WO2018121334A1 (zh) 一种提供网页应用服务的方法、装置、电子设备及系统
CN113204353B (zh) 一种大数据平台组件部署方法及装置
US10860375B1 (en) Singleton coordination in an actor-based system
CN113961312A (zh) 目标服务的部署方法、装置和电子设备
CN104468150A (zh) 一种虚拟主机实现故障迁移的方法及虚拟主机业务装置
US9183092B1 (en) Avoidance of dependency issues in network-based service startup workflows
CN114679380A (zh) 边缘集群的创建方法和相关装置
CN114900430A (zh) 容器网络优化方法、装置、计算机设备和存储介质
US10180914B2 (en) Dynamic domain name service caching
CN110049081A (zh) 用于搭建及使用高可用性Docker私库的方法和系统
CN116192885A (zh) 高可用集群架构人工智能实验云平台数据处理方法及系统
CN115665036A (zh) 一种路由策略故障处理方法、装置及介质
US20220261327A1 (en) Identification of Log Events for Computing Systems
US11513833B1 (en) Event listener interface for container-based execution of serverless functions
CN115333993A (zh) 容器环境下自定义容器组路由的方法、设备及存储介质
US9348672B1 (en) Singleton coordination in an actor-based system
CN116954810A (zh) 容器应用实例的创建方法、系统、存储介质及程序产品
CN113867890A (zh) 一种日志采集方法、装置、介质
US9405605B1 (en) Correction of dependency issues in network-based service remedial workflows

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