CN115952019A - 一种容器集群保护方法、装置及存储介质 - Google Patents

Abstract

本发明涉及一种容器集群保护方法、装置及存储介质。当Kubernetes集群中Node节点出现宕机时，将宕机Node节点上的全部容器实例名称记录到容器实例和宕机节点对应表中，并在运行容器实例名称所对应容器实例的Node节点宕机时，将Node节点记录到容器实例和宕机节点对应表中相应的容器实例名称下，且当前宕机的Node节点与在前宕机的Node节点时序排列形成宕机Node节点列表；若容器实例和宕机节点对应表中一容器实例名称对应的宕机Node节点列表长度超过设定长度阈值，则判断该容器实例名称对应的容器实例存在异常，将异常容器实例熔断，使异常容器实例无法在Node节点重建，避免异常容器实例重建执行导致Kubernetes集群中更多Node节点的宕机。

Description

一种容器集群保护方法、装置及存储介质

技术领域

本发明涉及集群保护技术领域，尤其涉及一种容器集群保护方法、装置及存储介质。

背景技术

容器技术在轻量和弹性等方面展示的明显的优势，但容器存在隔离性弱的问题。隔离性弱的问题给容器也带来了隐藏的风险，比如由于容器资源使用限制配置不当、内部应用本身异常或者病毒漏洞等导致单个容器异常，而该异常容器可能会将整个节点资源耗尽进而导致整个节点异常，从而导致节点上所有容器异常。

Kubernetes是容器编排引擎中的实时标准，通过Kubernetes可以构建容器集群，其中一个核心特性就是副本保持，即在当前节点异常后，当前节点上的容器会在其他节点上重新建立新的容器实例。Kubernetes集群由两类节点组成，Master和Node。在Master上运行etcd、API Server、Controller Manager和Scheduler四个组件，其中API Server、Controller Manager和Scheduler构成Kubernetes的总控中心，负责对集群中所有资源进行管控和调度。在每个Node上运行Kubelet、Proxy和Docker Deamon三个组件，负责对本节点上的Pod的生命周期进行管理，并实现服务代理的功能。在Master和Node节点上都可运行Kubectl命令行工具，Kubectl提供了Kubernetes的集群管理工具集。etcd是高可用的key/value存储***，用于持久化存储集群中所有的资源对象，API Server则提供了操作etcd的封装接口API，以REST方式提供服务，用于集群资源对象的增删改查及监听资源变化的接口。Controller Manager作为集群内部的管理控制中心，负责集群内Node、Pod副本、服务端点、命名空间、服务账号、资源定额等的管理，确保集群处于预期的工作状态。比如在某个Node意外宕机时，Controller Manager会在集群中的其他节点上自动补齐Pod副本。Controller Manager内部包含了副本控制器(Replication Controller)，副本控制器的核心作用时确保在任何时候，集群中一个资源对象所关联的Pod保持一定数量的Pod副本。这一机制能够提高容灾能力，减少因节点崩溃造成的损失，但也带来一个问题，如果由于异常容器导致的节点宕机，该容器在其他节点重建时，会继续导致其他节点变为异常或者宕机，如果异常容器在不同节点间反复重建，就会导致整个集群处于瘫痪状态。传统的运维模式，是通过人为发现后，进行日志分析得哪个容器实例有问题，该流程从发现现象到解决问题时间周期一般很长，在解决问题前，集群有可能已经瘫痪无法继续运行。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本发明提供一种容器集群保护方法、装置及存储介质。能够在集群因异常容器陷入瘫痪之前，自动地将异常容器检测出来，并对异常容器进行熔断，避免整个集群进一步故障。

第一方面，本发明提供一种容器集群保护方法，包括：当Kubernetes集群中Node节点出现宕机时，将宕机Node节点上的全部容器实例名称记录到容器实例和宕机节点对应表中，并在运行容器实例名称所对应容器实例的Node节点宕机时，将Node节点记录到容器实例和宕机节点对应表中相应的容器实例名称下，且当前宕机的Node节点与在前宕机的Node节点时序排列形成宕机Node节点列表；

若容器实例和宕机节点对应表中一容器实例名称对应的宕机Node节点列表长度超过设定长度阈值，则判断该容器实例名称对应的容器实例存在异常，将异常容器实例熔断，使异常容器实例无法在Node节点重建。

更进一步地，预设时间窗口，对于任一实例容器名称对应的宕机Node节点列表，若在预设的时间窗口内连续的出现宕机Node节点列表变动，则保留该实例容器宕机Node节点列表，若在预设的时间窗口内无连续的出现宕机Node节点列表变动，则清空宕机Node节点列表中的内容。

更进一步地，预设的时间窗口参考单Node节点宕机发现时间最大值和Node节点中最多容器实例重建完成的重建时间的和配置。

更进一步地，宕机Node节点中的容器实例进行重建时，如果给指定节点名称标签，且亲和性为强制，会根据节点名称标签匹配相应的Node节点，在所匹配到的Node节点中重建宕机Node节点中的容器实例，对于异常容器实例，给异常容器实例配置为Kubernetes集群中不存在的节点名称标签，使根据节点名称标签在相应Node节点进行异常实例容器调度重建时失败，实现异常容器实例的熔断。

更进一步地，异常容器实例熔断时，删除容器实例和宕机节点对应表中相应的异常容器实例名称及其宕机Node节点列表；将容器实例和宕机节点对应表中被删除的异常容器实例名称及宕机Node节点列表的新增到异常容器实例列表中；基于异常容器实例列表中的各个异常容器实例名称及宕机Node节点列表进行日志生成或宕机Node节点分析或宕机Node节点恢复和容器实例恢复。

更进一步地，宕机Node节点恢复和容器实例恢复包括：针对容器实例，周期性地定期建立相应的副本作为恢复副本，若容器实例名称对应的容器实例异常导致Node节点崩溃前留下崩溃印记时，重启Node节点，Node节点在启动容器实例前若先检测到崩溃印记，则获取异常容器实例的恢复副本取代原异常容器实例运行。

更进一步地，保留设定数量的恢复副本，从离异常容器实例导致宕机时间最近的恢复副本开始，逆时序遍历全部恢复副本尝试恢复宕机Node节点，若被遍历到的恢复副本仍导致Node节点崩溃，继续尝试以更久远的恢复副本尝试恢复，若全部恢复副本无法恢复，则生成相应日志并给出相应提示。

更进一步地，在进行Kubernetes集群运维时，向Kubernetes集群输入运维开始信息，Kubernetes集群基于运维开始信息自动禁止容器集群保护，运维结束时，向Kubernetes集群输入运维结束信息自动开启容器集群保护。

第二方面，本发明提供一种容器集群保护装置，包括：处理单元，总线单元和存储单元，其中，所述总线单元连接存储单元、处理单元，所述存储单元存储计算机程序，计算机程序被处理单元执行时实现所述的容器集群保护方法。

第三方面，本发明提供一种实现容器集群保护方法的存储介质，所述存储介质存储计算机程序，所述计算机程序被处理器执行时实现所述的容器集群保护方法。

本发明实施例提供的上述技术方案与现有技术相比具有如下优点：

本发明当Kubernetes集群中Node节点出现宕机时，将宕机Node节点上的全部容器实例名称记录到容器实例和宕机节点对应表中，并在运行容器实例名称所对应容器实例的Node节点宕机时，将Node节点记录到容器实例和宕机节点对应表中相应的容器实例名称下，且当前宕机的Node节点与在前宕机的Node节点时序排列形成宕机Node节点列表；若容器实例和宕机节点对应表中一容器实例名称对应的宕机Node节点列表长度超过设定长度阈值，则判断该容器实例名称对应的容器实例存在异常，将异常容器实例熔断，使异常容器实例无法在Node节点重建，避免异常容器实例重建执行导致Kubernetes集群中更多Node节点的宕机。

本发明通过预设时间窗口，将预设的时间窗口内宕机Node节点列表发生变动时则保留宕机Node节点列表的变动，否则清空宕机Node节点列表，从而利用异常容器实例导致宕机Node节点列表的连续性变动特点，删除非连续性变动，避免非异常容器实例因素宕机Node节点列表长度的累积，进而因累积造成误报的情况。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种容器集群保护方法的流程图；

图2为本发明实施例提供的根据宕机Node节点列表长度和设定长度阈值比较确定宕机Node节点列表对应的容器实例是否为异常容器实例的流程图；

图3为本发明实施例提供的宕机Node节点恢复和容器实例恢复的流程图；

图4为发明实施例提供的一种容器集群保护装置的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

实施例1

参阅图1所示，本发明提供一种容器集群保护方法，包括：

S100，当Kubernetes集群中Node节点出现宕机时，将宕机Node节点上的全部容器实例名称记录到容器实例和宕机节点对应表中。

具体实施过程中，当Kubernetes集群中Node节点出现宕机时，通过Master节点的Controller Manager获取宕机的Node节点。Kubernetes集群由两类节点组成，Master和Node。在Master上运行etcd、API Server、Controller Manager和Scheduler四个组件，其中API Server、Controller Manager和Scheduler构成Kubernetes的总控中心，负责对集群中所有资源进行管控和调度。在每个Node上运行Kubelet、Proxy和Docker Deamon三个组件，负责对本节点上的Pod的生命周期进行管理，并实现服务代理的功能。在Master和Node节点上都可运行Kubectl命令行工具，Kubectl提供了Kubernetes的集群管理工具集。etcd是高可用的key/value存储***，用于持久化存储集群中所有的资源对象，API Server则提供了操作etcd的封装接口API，以REST方式提供服务，用于集群资源对象的增删改查及监听资源变化的接口。Controller Manager作为集群内部的管理控制中心，负责集群内Node、Pod副本、服务端点、命名空间、服务账号、资源定额等的管理并执行自动化修复流程，确保集群处于与其的工作状态。比如在某个Node意外宕机时，Controller Manager会在集群中的其他节点上自动补齐Pod副本。Controller Manager内部包含了Node Controller，NodeController负责发现、管理和监控集群中的各个Node节点，Kubelet在启动时通过APIServer注册节点信息，并定时相API Server发送节点信息。API Server接收到节点信息后，将节点信息写入etcd。存入etcd的节点信息包括节点健康状况、节点资源、节点名称、节点地址信息、操作***版本、Docker版本、Kubelet版本等。节点健康状况包含“就绪”(True)、“未就绪”(False)和“未知”(Unknown)三种。Controller Manager在启动时如果设置了--cluster-cidr参数，那么为每个没有设置Spec.PodCIDR的Node节点生成一个CIDR地址，并用该CIDR地址设置节点的Spec.PodCIDR，以防止不同的Node节点的CIDR地址发生冲突。逐个读取节点信息，多次尝试修改nodeStatusMap中的节点状态信息，将该节点信息和nodeStatusMap中保存的节点状态信息做比较。如果判断出没有收到Kubelet发送的节点信息、第一次收到Node节点Kubelet发送的节点信息或在该处理过程中节点健康状态变成非健康状态，则在nodeStatusMap中保存该节点的状态信息，并用当事时的Node Controller所在节点的***时间作为探测时间和节点健康状态变化时间。如果判断出在指定时间内收到新的节点信息，且节点健康状态发生变化，用当事时的Node Controller所在节点的***时间作为探测时间和节点健康状态变化时间。如果判断出在指定时间内收到新的节点信息，但节点健康状态没发生变化，则用当事时的Node Controller所在节点的***时间作为探测时间，用上次节点信息中的节点健康状态变化时间作为该节点的节点健康状态变化时间。如果判断出在指定时间内没有收到节点信息，则设置节点健康状态为未知，并通过APIServer保存节点状态。

如：Node1中运行C1、C2和C3三个容器实例，当Node1发生宕机时，按C1：[Node1,]，C2：[Node1,]，C3：[Node1,]的格式形成容器实例和宕机节点对应表。

S200，在运行容器实例名称所对应容器实例的Node节点宕机时，将Node节点记录到容器实例和宕机节点对应表中相应的容器实例名称下，且当前宕机的Node节点与在前宕机的Node节点时序排列形成宕机Node节点列表。具体的，若后续Node2节点发生宕机，Node2节点中运行C1、C2、C4和C5的容器实例，则形成的容器实例和宕机节点对应表如下C1：[Node1,Node2，]，C2：[Node1,Node2，]，C3：[Node1,]，C4：[Node2，]，C5：[Node2，]。

S300，根据宕机Node节点列表长度和设定长度阈值比较确定宕机Node节点列表对应的容器实例是否为异常容器实例。具体实施过程中，参阅图2所示，根据宕机Node节点列表长度和设定长度阈值比较确定宕机Node节点列表对应的容器实例是否为异常容器实例包括：

S301，预设长度阈值和预设时间窗口；其中，预设的时间窗口参考单Node节点宕机发现时间最大值和Node节点中最多容器实例重建完成的重建时间的和配置。

S302，检测宕机Node节点列表相邻变动的时间间隔是否大于预设时间窗口，是则执行S303，否则，执行S304。

S303，清空宕机Node节点列表中的内容。

S304，保留该实例容器宕机Node节点列表的内容。

S305，遍历容器实例和宕机节点对应表中全部容器实例名称对应的宕机Node节点列表长度。宕机Node节点列表长度指宕机节点列表存储的运行其所对应容器实例的宕机Node节点的数量。

S306，比较容器实例名称对应的宕机Node节点列表长度是否超过设定长度阈值，是则执行S307，否则，执行S308。

S307，判断相应容器实例名称对应的容器实例存在异常。

S308，判断相应容器实例名称对应的容器实例无异常。

对于任一实例容器名称对应的宕机Node节点列表，若在预设的时间窗口内连续的出现宕机Node节点列表变动，则保留该实例容器宕机Node节点列表，若在预设的时间窗口内无连续的出现宕机Node节点列表变动，则清空宕机Node节点列表中的内容。异常容器实例导致Node节点宕机后，异常容器实例在其他Node节点重建运行导致其他Node节点宕机的情况，往往形成连续的链式宕机。而非异常容器实例造成的Node节点宕机往往非连续的链式宕机，通过预设的时间窗口筛选记录于实例容器宕机Node节点列表的宕机节点，能够有效的避免非异常容器实例导致Node节点宕机累积对结果分析的影响。

S400，将异常容器实例熔断，使异常容器实例无法在Node节点重建。具体的，宕机Node节点中的容器实例进行重建时，如果给指定节点名称标签，且亲和性配置为强制，会根据节点名称标签匹配相应的Node节点，在所匹配到的Node节点中重建宕机Node节点中的容器实例，对于异常容器实例，给异常容器实例配置为Kubernetes集群中不存在的节点名称标签，使根据节点名称标签在相应Node节点进行异常实例容器调度重建时失败，实现异常容器实例的熔断。异常容器实例熔断时，删除容器实例和宕机节点对应表中相应的异常容器实例名称及其宕机Node节点列表；将容器实例和宕机节点对应表中被删除的异常容器实例名称及宕机Node节点列表的新增到异常容器实例列表中；基于异常容器实例列表中的各个异常容器实例名称及宕机Node节点列表进行日志生成或宕机Node节点分析或宕机Node节点恢复和容器实例恢复。

具体实施过程中，参阅图3所示，一种可行的宕机Node节点恢复和容器实例恢复包括：针对Node节点内的容器实例，周期性地定期建立相应的副本作为恢复副本，且保留设定数量的恢复副本。

容器实例名称对应的容器实例异常导致Node节点崩溃前留下崩溃印记。

重启Node节点，Node节点在启动容器实例前若先检测到崩溃印记，则获取异常容器实例的恢复副本取代原异常容器实例运行，若未检测到崩溃印记则Node节点运行原容器实例。具体的，从离异常容器实例导致宕机时间最近的恢复副本开始，逆时序遍历全部恢复副本，利用恢复副本尝试恢复宕机Node节点，具体的，改变恢复副本的亲和性，使其对宕机Node节点亲和性为宕机Node节点，使恢复副本在宕机Node节点尝试恢复，若被遍历到的恢复副本仍导致Node节点崩溃，继续尝试以更久远的恢复副本尝试恢复，若全部恢复副本无法恢复，则生成相应日志并给出相应提示。尝试恢复的机制能够有效地避免误判带来严重的损失。

具体实施过程中，为避免运维导致的连续性宕机对结果的影响，导致将正常容器实例识别为异常容器实例，在运维过程中，终止容器集群保护方法。具体的，在进行Kubernetes集群运维时，向Kubernetes集群的Master节点输入运维开始信息，Kubernetes集群基于运维开始信息自动禁止容器集群保护，运维结束时，向Kubernetes集群输入运维结束信息，Kubernetes集群基于运维结束信息自动开启容器集群保护。

实施例2

参阅图4所示，本发明实施例提供一种容器集群保护装置，包括：处理单元，总线单元和存储单元，其中，所述总线单元连接存储单元、处理单元，所述存储单元存储计算机程序，计算机程序被处理单元执行时实现所述的容器集群保护方法。

实施例3

本发明实施例提供一种实现容器集群保护方法的存储介质，所述存储介质存储计算机程序，所述计算机程序被处理器执行时实现所述的容器集群保护方法。

本发明当Kubernetes集群中Node节点出现宕机时，将宕机Node节点上的全部容器实例名称记录到容器实例和宕机节点对应表中，并在运行容器实例名称所对应容器实例的Node节点宕机时，将Node节点记录到容器实例和宕机节点对应表中相应的容器实例名称下，且当前宕机的Node节点与在前宕机的Node节点时序排列形成宕机Node节点列表；若容器实例和宕机节点对应表中一容器实例名称对应的宕机Node节点列表长度超过设定长度阈值，则判断该容器实例名称对应的容器实例存在异常，将异常容器实例熔断，使异常容器实例无法在Node节点重建，避免异常容器实例重建执行导致Kubernetes集群中更多Node节点的宕机。

本发明通过预设时间窗口，将预设的时间窗口内宕机Node节点列表发生变动时则保留宕机Node节点列表的变动，否则清空宕机Node节点列表，从而利用异常容器实例导致宕机Node节点列表的连续性变动特点，删除非连续性变动，避免非异常容器实例因素宕机Node节点列表长度的累积，进而因累积造成误报的情况。

在本发明所提供的实施例中，应该理解到，所揭露的结构和方法，可以通过其它的方式实现。例如，以上所描述的结构实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，结构或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种容器集群保护方法，其特征在于，包括：当Kubernetes集群中Node节点出现宕机时，将宕机Node节点上的全部容器实例名称记录到容器实例和宕机节点对应表中，并在运行容器实例名称所对应容器实例的Node节点宕机时，将Node节点记录到容器实例和宕机节点对应表中相应的容器实例名称下，且当前宕机的Node节点与在前宕机的Node节点时序排列形成宕机Node节点列表；

若容器实例和宕机节点对应表中一容器实例名称对应的宕机Node节点列表长度超过设定长度阈值，则判断该容器实例名称对应的容器实例存在异常，将异常容器实例熔断，使异常容器实例无法在Node节点重建。

2.根据权利要求1所述的容器集群保护方法，其特征在于，预设时间窗口，对于任一实例容器名称对应的宕机Node节点列表，若在预设的时间窗口内连续的出现宕机Node节点列表变动，则保留该实例容器宕机Node节点列表，若在预设的时间窗口内无连续的出现宕机Node节点列表变动，则清空宕机Node节点列表中的内容。

3.根据权利要求2所述的容器集群保护方法，其特征在于，预设的时间窗口参考单Node节点宕机发现时间最大值和Node节点中最多容器实例重建完成的重建时间的和配置。

4.根据权利要求1所述的容器集群保护方法，其特征在于，宕机Node节点中的容器实例进行重建时，如果给指定节点名称标签，且亲和性为强制，会根据节点名称标签匹配相应的Node节点，在所匹配到的Node节点中重建宕机Node节点中的容器实例，对于异常容器实例，给异常容器实例配置为Kubernetes集群中不存在的节点名称标签，使根据节点名称标签在相应Node节点进行异常实例容器调度重建时失败，实现异常容器实例的熔断。

5.根据权利要求1所述的容器集群保护方法，其特征在于，异常容器实例熔断时，删除容器实例和宕机节点对应表中相应的异常容器实例名称及其宕机Node节点列表；将容器实例和宕机节点对应表中被删除的异常容器实例名称及宕机Node节点列表的新增到异常容器实例列表中；基于异常容器实例列表中的各个异常容器实例名称及宕机Node节点列表进行日志生成或宕机Node节点分析或宕机Node节点恢复和容器实例恢复。

6.根据权利要求5所述的容器集群保护方法，其特征在于，宕机Node节点恢复和容器实例恢复包括：针对容器实例，周期性地定期建立相应的副本作为恢复副本，若容器实例名称对应的容器实例异常导致Node节点崩溃前留下崩溃印记时，重启Node节点，Node节点在启动容器实例前若先检测到崩溃印记，则获取异常容器实例的恢复副本取代原异常容器实例运行。

7.根据权利要求6所述的容器集群保护方法，其特征在于，保留设定数量的恢复副本，从离异常容器实例导致宕机时间最近的恢复副本开始，逆时序遍历全部恢复副本尝试恢复宕机Node节点，若被遍历到的恢复副本仍导致Node节点崩溃，继续尝试以更久远的恢复副本尝试恢复，若全部恢复副本无法恢复，则生成相应日志并给出相应提示。

8.根据权利要求1所述的容器集群保护方法，其特征在于，在进行Kubernetes集群运维时，向Kubernetes集群输入运维开始信息，Kubernetes集群基于运维开始信息自动禁止容器集群保护，运维结束时，向Kubernetes集群输入运维结束信息自动开启容器集群保护。

9.一种容器集群保护装置，其特征在于，包括：处理单元，总线单元和存储单元，其中，所述总线单元连接存储单元、处理单元，所述存储单元存储计算机程序，计算机程序被处理单元执行时实现如权利要求1-8任一所述的容器集群保护方法。

10.一种实现容器集群保护方法的存储介质，所述存储介质存储计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-8任一所述的容器集群保护方法。

Images