CN115328735A - 一种基于容器化应用管理系统的故障隔离方法和系统 - Google Patents
一种基于容器化应用管理系统的故障隔离方法和系统 Download PDFInfo
- Publication number
- CN115328735A CN115328735A CN202211012787.4A CN202211012787A CN115328735A CN 115328735 A CN115328735 A CN 115328735A CN 202211012787 A CN202211012787 A CN 202211012787A CN 115328735 A CN115328735 A CN 115328735A
- Authority
- CN
- China
- Prior art keywords
- node
- fault
- container
- container group
- isolation
- 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
Links
- 238000002955 isolation Methods 0.000 title claims abstract description 61
- 238000000034 method Methods 0.000 claims abstract description 37
- 238000012544 monitoring process Methods 0.000 claims abstract description 30
- 230000036541 health Effects 0.000 claims abstract description 24
- 230000008569 process Effects 0.000 claims abstract description 24
- 238000013024 troubleshooting Methods 0.000 claims description 18
- 238000001514 detection method Methods 0.000 claims description 15
- 238000007726 management method Methods 0.000 claims description 13
- 239000000523 sample Substances 0.000 claims description 9
- 241000322338 Loeseliastrum Species 0.000 claims description 5
- 230000002159 abnormal effect Effects 0.000 claims description 5
- 230000003862 health status Effects 0.000 claims description 4
- 230000007246 mechanism Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000032683 aging Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种基于容器化应用管理系统的故障隔离方法和系统，属于容器化应用管理的技术领域，所述故障隔离方法包括容器隔离的方法：对容器进行健康监测，获得一个或多个故障容器组；获取管理故障容器组的Deployment；判断所述Deployment是否具有多个故障容器组；若是，将Deployment的一个或多个第一故障容器组进行隔离，并终止第二故障容器组。容器隔离的过程中，保留故障应用POD，方便排查故障原因；同一Deployment下的多个故障容器组，仅隔离其中的部分故障容器组，而终止或杀死其余的故障容器组，减少隔离造成的资源消耗。
Description
技术领域
本发明涉及容器化应用管理的技术领域，具体涉及一种基于容器化应用管理系统的故障隔离方法。
背景技术
随着容器化应用上云的趋势，越来越多的企业选择容器化应用管理系统(Kubernetes)进行集群环境容器化部署业务应用。
基于Kubernetes的集群容器环境特性，应用容器组(pod)调度到某个节点后，由于主机本身原因或其他原因导致应用pod没法运行成功，Kubelet会不停的重启容器，但不会重启应用pod，导致应用pod没法重新调度到合适的节点上，业务pod只会在不合适的节点上不停重启。
当应用发生故障时，Kubelet会重启容器，删除故障容器，导致应用发生故障时的“现场”(故障发生时的应用容器)没有保留，不方便回溯排查应用报错原因。
当kubernetes集群内主机发生故障时，会影响故障主机上运行的业务pod。只能通过人工介入驱逐，故障主机导致的应用故障恢复较慢，无法实时隔离故障主机，实时驱逐业务，以减小对业务的影响。
因此为了更好地利用kubernetes集群，需要突破故障隔离的机制。
发明内容
针对现有技术中存在的上述技术问题，本发明提供一种基于容器化应用管理系统的故障隔离方法和系统，对故障容器或容器组进行隔离或终止，方便排查故障原因。
本发明公开了一种基于容器化应用管理系统的故障隔离方法，所述故障隔离方法包括容器隔离的方法：对容器进行健康监测，获得一个或多个故障容器组；获取管理故障容器组的Deployment；判断所述Deployment是否具有多个故障容器组；若是，将Deployment的一个或多个第一故障容器组进行隔离，并终止第二故障容器组。
优选的，利用隔离的第一故障容器组进行故障排查：
利用排查脚本对第一故障容器组进行故障排查，并保存排查结果。
优选的，监测容器健康的方法包括：
通过探针检测故障容器；
或者监测出以下任一情况或它们的组合时存在故障容器：容器的CPU或者内存的使用率持续超过第一域值；容器的线程池满；容器出现错误关键字。
优选的，通过第一标签进行隔离的方法：
为故障容器组设置第一标签；
将具有第一标签的容器组移出Deployment、移除该容器组在Endpoint列表中的IP和端口、并注销所述容器组。
优选的，容器组的调度方法：
判断第三容器组是否满足第一条件：为故障容器组、且启动时间超过第二域值；
若满足，删除所述第三容器组，并记录所在的节点信息；
获得新建第四容器组的调度列表；
判断所述调度列表是否包括所述节点；
若包括所述节点，从所述调度列表中删除所述节点；
若不包括，按照所述调度列表进行调度；
判断所述调度列表是否为空；
若为空，清除所记录的节点信息。
优选的，所述故障隔离方法还包括节点隔离的方法：
检查所述节点的健康状态，
其中，所述检查的包括以下任一项目或它们的组合：kubelet健康检查、磁盘压力、内存压力、PID压力、网络、docker组件、containerd组件和Calico组件；
若节点的健康存在故障，隔离所述节点。
优选的，若节点的健康存在故障，查看所述节点的全局锁是否有效；
若无效，隔离所述节点、注销相应的容器组，并为所述节点打上第二标签。
优选的，部署在节点中的节点监测模块定期将自身的心跳上报到全局锁的节点对象中；
节点控制器监听节点对象、并判断所述节点对象的心跳数据是否存在异常；
若存在异常，通过节点控制器为所述节点打上第二标签，并隔离所述节点。
优选的，docker组件的检测指标包括：Dockerd进程存在、且不为僵尸进程，每一秒检测一次，连续失败三次，则认为节点故障；
Calico组件的检测指标包括：Kubelet进程存在、且不为僵尸进程，每一秒检测一次，连续失败三次，则认为节点故障；
containerd组件的检测指标包括：docker-containerd进程存在、且不为僵尸进程，Confd/Felix/Bird进程存在、且不为僵尸进程，每一秒检测一次，连续失败三次，则认为节点故障。
本发明还提供一种用于实现上述故障隔离方法的系统，包括容器监测模块和容器隔离模块，所述容器监测模块用于对容器进行健康监测，获得一个或多个故障容器组；所述容器隔离模块用于获取管理故障容器组的Deployment，若所述Deployment是否具有多个故障容器组，将Deployment的一个或多个第一故障容器组进行隔离，并终止第二故障容器组。
与现有技术相比，本发明的有益效果为：容器隔离的过程中，保留故障应用POD，方便排查故障原因；同一Deployment下的多个故障容器组，仅隔离其中的部分故障容器组，而终止或杀死其余的故障容器组，减少隔离造成的资源消耗。
附图说明
图1是本发明的基于容器化应用管理系统的故障隔离方法的流程图；
图2是容器隔离的方法流程图；
图3是容器隔离的架构图；
图4是新建容器组的调度方法流程图；
图5是节点隔离的架构图；
图6是本发明的系统逻辑框图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
下面结合附图对本发明做进一步的详细描述：
本发明的提供一种基于容器化应用管理系统的故障隔离方法，如图1所示，包括：
步骤S1：容器隔离。
通过对容器进行健康检测，及时对故障容器组进行隔离或终止，便于故障排查、防止不停重启。
步骤S2：容器组的调度。
终止容器组后，对新建容器组进行调度。
步骤S3：节点隔离。对节点/主机进行健康检测，及时隔离故障节点。
如图2所示，容器隔离的方法：
步骤101：对容器进行健康监测，获得一个或多个故障容器组(Pod)。
其中，健康监测或隔离触发机制包括：探针机制和监控机制。
探针机制：Kubelet拨测就绪探针(Readiness Probe)失败时，存在故障容器组。就绪探针可以感知到容器发生Crash、OOM、业务拨测等。但不限于就绪探针，也可以使用在线探针，但开销将加大。
监控机制：即基于现有的容器监控平台(Prometheus)监控告警、运维监控、决策系统发现故障容器组，可以调用相关的API触发隔离。例如监测出以下任一情况或它们的组合时，存在故障容器组：容器的CPU或者内存的使用率持续很高，例如超过第一域值；容器的线程池满；容器出现错误关键字。
步骤102：获取管理所述故障容器组的Deployment。
步骤103：判断所述Deployment是否具有多个故障容器组。
若是，执行步骤104：将Deployment的一个或多个第一故障容器组进行隔离，并终止第二故障容器组。
其中，第二故障容器组和第一故障容器组为同一Deployment管理的故障容器组。Deployment是用于部署和管理多个POD实例的控制器，可以实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。
若否，执行步骤105：隔离所述故障容器组。
步骤106：利用隔离的故障容器组或第一故障容器组进行故障排查：利用排查脚本对第一故障容器组进行故障排查，并保存排查结果。
容器隔离的过程中，保留故障应用POD，方便排查故障原因；同一Deployment下的多个故障容器组，仅隔离其中的部分故障容器组，而终止或杀死其余的故障容器组，减少隔离造成的资源消耗。
实施例1
如图3所示，通过第一标签进行隔离。
步骤111：分别通过容器监控平台(Prometheus)和就绪控针进行容器组的健康进行监控。其中，容器组包括一个或多个容器，可以在容器中部署进程管理工具，用于管理应用子进程，防止应用程序主进程意外退出导致容器销毁，无法保留故障现场。可以在通过容器的基础镜像进行部署。
步骤112：就绪控针失败时，判断为故障容器组，为故障容器组添加第一标签，例如Pod状态为：NoReady；或者容器监控平台在运维监控和决策系统中发现故障，则调用API为故障容器添加第一标签。
步骤113：通过故障隔离控制器(Controller)执行隔离，将具有第一标签的容器组移出所在的Deployment、移除该容器组在Endpoint列表中的IP和端口、并在注册中心注销所述容器组。
具体实施例中，Controller以List/Watch的形式监听集群内所有(有隔离需求的)Pod状态变化，一旦发现Pod状态由Ready转变为Not Ready，则执行隔离Pod的动作：修改该Pod的Label(例如，删除标签Labels：app：nginx)，并在该pod的Label中增加一条用来识别故障Pod的特殊label(例如，status:problem)修改Label后的故障pod，会被移出Deploy，原来Endpoint列表中会移除该pod ip，该故障Pod的流量会被切断。
在Controller进行隔离故障pod的同时，针对不使用Kubenetes集群内服务发现机制的Pod，如微服务，使用其他注册中心来实现服务注册与发现，但是这个Pod应用进程销毁，未从注册中心注销，则该Pod的流量仍在，Controller会获取该Pod在对应注册中心的信息，将pod信息(pod ip等)从注册中心中移除。如Zookeeper注册中心的Provider叶子节点Path并将Pod IP对应的Provider叶子节点Path从Zookeeper注册中心删除。
Controller执行Pod隔离时，对多个属于同一Deployment的故障Pod，只隔离且保留其中一个或多个第一故障Pod(保留个数可以通过配置传入Controller)，其余的第二故障Pod直接终止重启。
步骤114：同时Kubelet将重新为deployment拉起一个新的pod来维护现有的流量，重新拉起新pod的耗时与常规pod容器重启时间相近，既保留的故障现场，也不影响现有的流量。
步骤115：Controller执行故障Pod隔离时，可以使用JVM排查脚本，生成jmap文件、jstack文件等，保留在容器内，方便后续排查pod故障原因。进入隔离的故障应用Pod排查原因结束之后，可以手动删除。
实施例2
如图4，步骤S2中，容器组的调度方法包括：
步骤201：判断第三容器组是否满足第一条件：为故障容器组、且启动时间超过第二域值。如3分钟，但不限于此。
在一个具体实施例中，为故障容器组建立第一标签：Pod状态为：NoReady；启动时间可以根据容器组的创建时间(时间字段，metadata.creationTimestamp)和当前时间来计算。
若满足，执行步骤202：删除所述第三容器组，并记录所在的节点信息。可以通过调用apiserver接口去删除该故障Pod。可以将删除的pod的所在节点信息，写入pod对应的deployment的annotation(注解)中进行记录。
若不满足，持续监测第三容器组。
步骤203：获取新建的第四容器组的调度列表。通过kubelet为Deployment新建第四容器组。重新拉起新pod的耗时与常规pod容器重启时间相近。
步骤204：判断所述调度列表是否包括所述节点。
若包括所述节点，步骤205：从所述调度列表中删除所述节点，执行步骤206或208。
若不包括，执行步骤206：按照所述调度列表进行调度。
步骤207：判断所述调度列表是否为空。
若为空，执行步骤208：清除所记录的节点信息，并按原始调度列表进行调度。
若不为空，执行步骤206。
可以通过部署pod-problem-controller组件来步骤201-202。通过自定义拓展调度器执行步骤203-207。
通过本实施例的容器组调度方法，可以有效避免由于节点/主机本身原因或其他原因导致应用pod没法在当前节点上运行成功的问题，可以及时发现长时间未运行成功的pod。
实施例3
步骤S3中，节点隔离的方法包括：
步骤301：检查所述节点的健康状态，其中，所述检查的包括以下任一项目或它们的组合：kubelet健康检查、磁盘压力、内存压力、PID压力、网络、docker组件、containerd组件和Calico组件。
可以通过node-agent+node-controller组件对主机进行检测，检测指标如表1所示：
步骤302：若节点的健康存在故障，隔离所述节点。
当kubernetes集群内主机发生故障时，会影响故障主机上的运行的pod，通隔离故障主机，实时驱逐业务，以减小对业务的影响。
在具体实施例中，采用如图5所示的架构，在节点中部署有检测模块(node-agent)。
如图5虚线所示，一个具体的隔离机制中，步骤302包括：
步骤312：若节点的健康存在故障，查看所述节点的全局锁(etcd)是否有效。
若无效，执行步骤312：隔离所述节点、注销所述节点中部署的容器组，并为所述节点打上第二标签。例如，可以通过调用kube-apiserver接口将故障节点打上NoExecute污点。
若有效，持续监测所述节点，而不执行隔离。全局锁用于节点保护，例如30-60分钟内不进行节点隔离。
图5实线示出了另一个具体的隔离机制，步骤302包括：
步骤321：部署在节点中的节点监测模块(node-agent)定期将自身的心跳上报到全局锁(etcd)的节点对象中。所述节点对象可以是定义的轻量级CRD对象，包含node-agent所在节点的节点健康状态。
步骤323：节点控制器(node-controller)监听所述节点对象、并判断所述节点对象的心跳数据是否存在异常，例如连接3次获取不到节点对象的变化。
若存在异常，执行步骤324：通过节点控制器执行隔离：隔离所述节点、注销相应的容器组，并为所述节点打上第二标签。
通过节点控制器监听心跳数据，防止在node-agent故障或节点的情况下，不能及时发现节点异常。例如节点硬件故障导致宕机、节点网卡故障、节点系统Crash、节点系统Hang住(网络不佳)等。
实施例4
如图6所示，本实施例提供一种用于实现上述故障隔离方法的系统，包括容器监测模块1和容器隔离模块2，
容器监测模块1用于对容器进行健康监测，获得一个或多个故障容器组；
容器隔离模块2用于获取管理故障容器组的Deployment，若所述Deployment是否具有多个故障容器组，将Deployment的一个或多个第一故障容器组进行隔离，并终止第二故障容器组。
本发明的系统还包括容器调度模块3、节点监测模块4和节点控制器5。
容器调度模块3用于容器组的调度；节点监测模块4用于检测节点的健康状态和节点隔离，还可以用于上传自身的心跳；节点控制器5用于根据节点对象中的心跳数据，执行节点隔离。
本发明通过容器隔离，完整保留故障应用pod容器现场,方便后续排查应用报错原因；通过容器组的调试，调度应用pod，避免主机因素对应用pod的影响，同时及时发现长时间未运行成功的业务pod；在节点隔离中，新增多种主机故障隔离的检测和触发机制，同时优化健康检测的时效。
以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (10)
1.一种基于容器化应用管理系统的故障隔离方法，其特征在于，所述故障隔离方法包括容器隔离的方法：
对容器进行健康监测，获得一个或多个故障容器组；
获取管理所述故障容器组的Deployment；
判断所述Deployment是否具有多个故障容器组；
若是，将Deployment的一个或多个第一故障容器组进行隔离，并终止Deployment的第二故障容器组。
2.根据权利要求1所述的隔离方法，其特征在于，利用隔离的第一故障容器组进行故障排查：
利用排查脚本对第一故障容器组进行故障排查，并保存排查结果。
3.根据权利要求1所述的隔离方法，其特征在于，监测容器健康的方法包括：
通过探针检测故障容器；
或者监测出以下任一情况或它们的组合时存在故障容器：容器的CPU或者内存的使用率持续超过第一域值；容器的线程池满；容器出现错误关键字。
4.根据权利要求1所述的隔离方法，其特征在于，还包括通过第一标签进行隔离的方法：
为故障容器组设置第一标签；
将具有第一标签的容器组移出Deployment、移除该容器组在Endpoint列表中的IP和端口、并注销所述容器组。
5.根据权利要求1-4任一项所述的隔离方法，其特征在于，还包括容器组的调度方法：
判断第三容器组是否满足第一条件：为故障容器组、且启动时间超过第二域值；
若满足，删除所述第三容器组，并记录所在的节点信息；
获得新建第四容器组的调度列表；
判断所述调度列表是否包括所述节点；
若包括所述节点，从所述调度列表中删除所述节点；
若不包括，按照所述调度列表进行调度；
判断所述调度列表是否为空；
若为空，清除所记录的节点信息。
6.根据权利要求1-4任一项所述的隔离方法，其特征在于，所述故障隔离方法还包括节点隔离的方法：
检查所述节点的健康状态，
其中，所述检查的包括以下任一项目或它们的组合：kubelet健康检查、磁盘压力、内存压力、PID压力、网络、docker组件、containerd组件和Calico组件；
若节点的健康存在故障，隔离所述节点。
7.根据权利要求6所述的隔离方法，其特征在于，
若节点的健康存在故障，查看所述节点的全局锁是否有效；
若无效，隔离所述节点、注销相应的容器组，并为所述节点打上第二标签。
8.根据权利要求7所述的隔离方法，其特征在于，
部署在节点中的节点监测模块定期将自身的心跳上报到全局锁的节点对象中；
节点控制器监听节点对象、并判断所述节点对象的心跳数据是否存在异常；
若存在异常，通过节点控制器为所述节点打上第二标签，并隔离所述节点。
9.根据权利要求8所述的隔离方法，其特征在于，docker组件的检测指标包括：Dockerd进程存在、且不为僵尸进程，每一秒检测一次，连续失败三次，则认为节点故障；
Calico组件的检测指标包括：Kubelet进程存在、且不为僵尸进程，每一秒检测一次，连续失败三次，则认为节点故障；
containerd组件的检测指标包括：docker-containerd进程存在、且不为僵尸进程，Confd/Felix/Bird进程存在、且不为僵尸进程，每一秒检测一次，连续失败三次，则认为节点故障。
10.一种用于实现如权利要求1-9任一项所述隔离方法的系统，其特征在于，包括容器监测模块和容器隔离模块，
所述容器监测模块用于对容器进行健康监测，获得一个或多个故障容器组；
所述容器隔离模块用于获取管理所述故障容器组的Deployment，若所述Deployment是否具有多个故障容器组，将Deployment的一个或多个第一故障容器组进行隔离，并终止第二故障容器组。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211012787.4A CN115328735A (zh) | 2022-08-23 | 2022-08-23 | 一种基于容器化应用管理系统的故障隔离方法和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211012787.4A CN115328735A (zh) | 2022-08-23 | 2022-08-23 | 一种基于容器化应用管理系统的故障隔离方法和系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115328735A true CN115328735A (zh) | 2022-11-11 |
Family
ID=83926920
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211012787.4A Pending CN115328735A (zh) | 2022-08-23 | 2022-08-23 | 一种基于容器化应用管理系统的故障隔离方法和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115328735A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117331650A (zh) * | 2023-10-31 | 2024-01-02 | 中科驭数（北京）科技有限公司 | 容器集的调度方法、装置、设备及存储介质 |
-
2022
- 2022-08-23 CN CN202211012787.4A patent/CN115328735A/zh active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117331650A (zh) * | 2023-10-31 | 2024-01-02 | 中科驭数（北京）科技有限公司 | 容器集的调度方法、装置、设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110798375B (zh) | 一种增强容器集群高可用性的监控方法、系统及终端设备 | |
| CN109286529B (zh) | 一种恢复RabbitMQ网络分区的方法及系统 | |
| US7328376B2 (en) | Error reporting to diagnostic engines based on their diagnostic capabilities | |
| CN106789306B (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
| CN109634716B (zh) | 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 | |
| CN107147540A (zh) | 高可用性系统中的故障处理方法和故障处理集群 | |
| CN109684032B (zh) | 防脑裂的OpenStack虚拟机高可用计算节点装置及管理方法 | |
| US7757124B1 (en) | Method and system for automatic correlation of asynchronous errors and stimuli | |
| CN109614201B (zh) | 防脑裂的OpenStack虚拟机高可用系统 | |
| CN105607973B (zh) | 一种虚拟机系统中设备故障处理的方法、装置及系统 | |
| US7373542B2 (en) | Automatic startup of a cluster system after occurrence of a recoverable error | |
| CN108776579A (zh) | 一种分布式存储集群扩容方法、装置、设备及存储介质 | |
| CN115328735A (zh) | 一种基于容器化应用管理系统的故障隔离方法和系统 | |
| US20150195167A1 (en) | Availability device, storage area network system with availability device and methods for operation thereof | |
| CN111342986B (zh) | 分布式节点管理方法及装置、分布式系统、存储介质 | |
| US7664980B2 (en) | Method and system for automatic attempted recovery of equipment from transient faults | |
| CN104158843B (zh) | 分布式文件存储系统的存储单元失效检测方法及装置 | |
| CN109117317A (zh) | 一种集群故障恢复方法和相关装置 | |
| CN113055203B (zh) | Sdn控制平面的异常恢复方法及装置 | |
| CN115712521A (zh) | 一种集群节点故障处理方法、系统及介质 | |
| CN106528276A (zh) | 一种基于任务调度的故障处理方法 | |
| Heegaard et al. | Survivability as a generalization of recovery | |
| CN112000442A (zh) | 一种基于kubernetes平台的集群状态自动获取方法及装置 | |
| KR101864126B1 (ko) | 지속적인 서비스 제공을 위한 정상상태 모델 기반의 침입감내 시스템 및 그 제어방법 | |
| CN115277006A (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 | ||
| CB03 | Change of inventor or designer information |
Inventor after: Xu Yunyuan Inventor after: Ye Jin Inventor after: Shen Hongjie Inventor after: Chen Weishun Inventor after: Wang Aoyu Inventor before: Xu Yunyuan Inventor before: Ye Jin Inventor before: Shen Hongjie Inventor before: Chen Weishun Inventor before: Wang Aoyu |
|
| CB03 | Change of inventor or designer information |