CN111818188B - 一种Kubernetes集群的负载均衡可用性提升方法和装置 - Google Patents

Abstract

本发明提供了一种Kubernetes集群的负载均衡可用性提升方法及装置，该方法包括：用户向Kubernetes集群提交负载均衡的资源声明；提供负载均衡自愈逻辑的组件lb‑operator watch到所述资源声明，并定期同步负载均衡的状态信息到Kubernetes集群中；若云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，则组件lb‑operator执行自愈逻辑。本发明中的方法，通过对比云端和集群中负载均衡的资源声明，当用户集群的slb故障时，根据status中负载均衡的不同状态执行不同的自愈逻辑，可实现部分错误场景下的自愈能力。

Description

一种Kubernetes集群的负载均衡可用性提升方法和装置

技术领域

本发明书一个或多个实施例涉及计算机软件技术领域，具体涉及云原生领域，尤其涉及一种 Kubernetes集群的负载均衡可用性提升方法和装置。

背景技术

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

1．名词解释：

Kubernetes，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效。

负载均衡（server load balance，slb）是一种服务器或网络设备的集群技术。负载均衡将特定的业务分担给多个服务器或网络设备，从而提高了业务能力，保证了业务的高可用性。

watch：Kubernetes中的通用术语，即当声明的资源状态发生变化时，能够监听到资源变化的事件，这么一种操作。

master：Kubernetes中的通用术语，即集群的主节点/控制节点。

lb-operator：自己定义的用于提供slb自愈逻辑的组件。

CustomResourceDefinition，简称CRD，是无需改变代码就可以扩展 KubernetesAPI 的机制，用来管理自定义对象。

2.现有技术：

随着云计算及大数据快速发展，新的技术框架层出不穷，Kubernetes应运而生。它是一个全新的基于容器技术的分布式架构，建立在docker技术之上，为容器化的应用提供了资源调度、部署运行、服务发现和扩容缩容等丰富多样的功能。同时Kubernetes是一个开放的平台，供社区用户直接参与应用和开发的框架。Kubernetes的重要的特点是自动化，自动化是指能够实现自动部署，自动重启，自动复制，自动伸缩/扩展。

图1为现有技术中高可用k8s集群的实现示意图，如图1所示，现有高可用k8s集群的实现方式为：通过1个slb+3个master的形式，实现用户集群控制面的高可用；当其中一个master节点故障时，slb能够自动将故障节点排除，从而将流量分摊到可用的master节点上；当master节点恢复时，又能够重新接收流量，据此实现master节点的高可用。但当slb出现故障时，则会直接导致整个集群不可用，此时需要人为修复slb的故障，导致用户集群一段时间内的不可用。

综上所述可以看出，如何在Kubernetes集群的用户集群的slb故障时，实现部分错误场景下的自愈能力。

发明内容

本说明书一个或多个实施例描述了Kubernetes集群的负载均衡可用性提升方法及装置，解决一定场景下负载均衡故障的问题，提高用户集群的可用性。

本说明书一个或多个实施例提供的技术方案如下：

为解决上述问题，第一方面，本发明提供了一种Kubernetes集群的负载均衡可用性提升方法，包括：

用户向Kubernetes集群提交负载均衡的资源声明。

提供负载均衡自愈逻辑的组件lb-operator watch到所述资源声明，并定期同步云端的负载均衡的资源声明的状态信息到Kubernetes集群中；

若云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，则组件lb-operator执行自愈逻辑。

在一个示例中，所述云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，具体为：

Kubernetes集群中的负载均衡仍存在，但云端的负载均衡被误删。

在一个示例中，所述云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，具体为：

Kubernetes集群中的负载均衡仍存在，但云端服务组或监听端口被误修改。

在一个示例中，创建新的负载均衡。

在一个示例中，所述新的负载均衡，根据状态中上一个负载均衡的配置数据完成配置。

在一个示例中，按照负载均衡的初始配置重新配置负载均衡的云端服务组及端口。

第二方面，本发明提供了一种Kubernetes集群的负载均衡可用性提升装置，所述装置包括：

提交模块，配置为用户向Kubernetes集群提交负载均衡的资源声明。

更新模块，配置为提供负载均衡自愈逻辑的组件lb-operator watch到所述资源声明，并定期同步云端的负载均衡的资源声明的状态信息到Kubernetes集群中；

自愈模块，配置为若云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，则组件lb-operator执行自愈逻辑。

第三方面，本发明提供了一种Kubernetes集群的负载均衡可用性提升系统，所述系统包括至少一个处理器和存储器；

所述存储器，用于存储一个或多个程序指令；

所述处理器，用于运行一个或多个程序指令，用以执行如第一方面中一个或多个所述的方法。

第四方面，本发明提供了一种芯片，所述芯片与系统中的存储器耦合，使得所述芯片在运行时调用所述存储器中存储的程序指令，实现如第一方面中一个或多个所述的方法。

第五方面，本发明提供了一种计算机可读存储介质，所述计算机可读存储介质包括一个或多个程序指令，所述一个或多个程序指令可被如第三方面所述的系统执行，以实现如第一方面中一个或多个所述的方法。

本发明实施例提供的方法中，用户可以向集群中提交slb的资源声明：创建/修改/删除，提交的资源会被lb-operator watch到，进而触发云端slb资源的创建/修改/删除。此外lb-operator将会定期同步最新的slb状态到集群中，当云端的slb与集群中资源的声明不符合时，还会触发自愈逻辑，保证用户集群的可用性，即应用本发明实施例提供的方法，当用户集群的slb故障时，可实现部分错误场景下的自愈能力。

附图说明

图1为现有技术中高可用Kubernetes集群的实现示意图；

图2为本发明实施例提供的一种Kubernetes集群的负载均衡可用性提升方法流程示意图；

图3为本发明实施例提供的lb-operator架构图；

图4为本发明实施例提供的一种Kubernetes集群的负载均衡可用性提升装置结构示意图；

图5为本发明实施例提供的一种Kubernetes集群的负载均衡可用性提升方法系统结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图2为本发明实施例提供的一种Kubernetes集群的负载均衡可用性提升方法流程示意图，所述方法的执行主体可以为任何具有计算、处理能力的装置、设备、平台、设备集群。如图2所示，所述方法包括以下步骤：

步骤10，用户向Kubernetes集群提交负载均衡的资源声明。

具体的，所述资源声明包括创建、修改/删除。

步骤20，提供负载均衡自愈逻辑的组件lb-operator watch到所述资源声明，并定期同步云端的负载均衡的资源声明的状态信息到Kubernetes集群中。

步骤30，若云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，则组件lb-operator执行自愈逻辑。

具体地，Kubernetes集群中的负载均衡仍存在，但云端的负载均衡被误删，则创建新的负载均衡，并根据状态中上一个负载均衡的配置数据完成配置。

而Kubernetes集群中的负载均衡仍存在，但云端服务组或监听端口被误修改，按照负载均衡的初始配置重新配置负载均衡的云端服务组及端口。

图3为本发明实施例提供的lb-operator架构图，如图3所示，用户可以向集群中提交负载均衡的资源声明：创建/修改/删除。 图中部分1中的Loadbalancer资源采用CRD机制注册到Kubernetes中。部分1中的内容，提交的资源声明会被提供自愈逻辑的组件lb-operator watch到，进而触发云端负载均衡的资源声明的创建/修改/删除。此外，lb-operator将会定期同步最新的负载均衡的状态到集群中，当云端的负载均衡的资源声明与集群中的资源声明不符合时，会触发组件lb-operator根据slb的资源声明yaml，执行自愈逻辑，保证用户集群的可用性。

以阿里云为例，下面详细介绍组件lb-operator的主要逻辑描述：

1、同步阿里云上的负载均衡的相关信息到集群中的负载均衡的资源声明中。

定期请求阿里云的开放平台，将slb的状态信息同步到slb资源声明中，并更新资源声明的status状态。根据slb指向的资源声明类型，如status.refResourceType字段，实现不同策略的周期同步策略。

2、watch slb资源，根据特定错误信息，执行自愈逻辑。

通过watch slb资源，根据status中slb的不同状态执行不同的自愈逻辑。以下以2个例子来说明slb自愈的逻辑。

实施例1

阿里云上的slb被误删除，从而导致用户集群不可用。

当集群中的slb的资源声明仍存在，但请求阿里云时却发现资源声明不存在，此时lb-operator会将错误信息如“couldn’t find specified slb instance”同步到slb资源声明的状态status中，即当前slb的状态errorMsg为“couldn’t find specified slbinstance”。当slb资源声明的状态被修改后， lb-operator又watch到该资源中的错误，根据配置的spec.slbRecoverPolicy自动申请了一个新的slb，并根据状态status中的上个slb的配置数据完成配置。即当集群中的slb的资源声明仍存在，但请求阿里云时却发现资源声明不存在时，lb-operator会根据slb资源声明中的autoCreateSlbWhileSlbInstanceNotFound，执行自愈逻辑，表示当找不到该slb时将自动创建一个新的slb。

实施例2：

当集群中的slb仍然存在，但后端服务组或是监听端口被误修改，可能为人为误操作slb，或者有其它操作，如：在集群中创建了一个loadbalancer类型的service资源时，并且使用了该slb，这将导致slb的监听的端口被修改，而错误的修改slb配置也将导致集群不可用。

此时组件lb-operator提供一种自愈策略为resetSlbConfigWhileError，即当发现slb的配置与初始配置不同时，将按照初始配置重新配置slb的后端服务组及端口，此时集群可恢复为可用状态。

本发明中的方法，通过对比云端和集群中负载均衡的资源声明，当用户集群的slb故障时，根据status中负载均衡的不同状态执行不同的自愈逻辑，可实现部分错误场景下的自愈能力。

与上述实施例对应的，本发明还提供了一种Kubernetes集群的负载均衡可用性提升装置，如图4，所述装置包括提交模块410、更新模块420和自愈模块430。

提交模块410，配置为用户向Kubernetes集群提交负载均衡的资源声明。

更新模块420，配置为提供负载均衡自愈逻辑的组件lb-operator watch到所述资源声明，并定期同步云端的负载均衡的资源声明的状态信息到Kubernetes集群中。

自愈模块430，配置为若云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，则组件lb-operator执行自愈逻辑。

本发明实施例提供的装置中各部件所执行的功能均已在上述方法中做了详细介绍，因此这里不做过多赘述。

与上述实施例相对应的，本发明实施例、还提供了一种系统，具体如图5所示，该系统包括至少一个处理器510和存储器520；

存储器520，用于存储一个或多个程序指令；

处理器510，用于运行一个或多个程序指令，执行如上述实施例所介绍的方法中的任一方法步骤。

与上述实施例相对应的，本发明实施例还提供了一种芯片，该芯片与上述系统中的存储器耦合，使得所述芯片在运行时调用所述存储器中存储的程序指令，实现如上述实施例所介绍的方法。

与上述实施例相对应的，本发明实施例还提供了一种计算机存储介质，该计算机存储介质中包括一个或多个程序，其中，一个或多个程序指令用于被一种语音识别系统执行如上介绍的方法。

本发明实施例提供的方法中，用户可以向集群中提交slb的资源声明：创建/修改/删除，提交的资源会被lb-operator watch到，进而触发云端slb资源的创建/修改/删除。此外lb-operator将会定期同步最新的slb状态到集群中，当云端的slb与集群中资源的声明不符合时，还会触发自愈逻辑，保证用户集群的可用性，即应用本发明实施例提供的方法，当用户集群的slb故障时，可实现部分错误场景下的自愈能力。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种Kubernetes集群的负载均衡可用性提升方法，其特征在于，包括：

用户向Kubernetes集群提交负载均衡的资源声明；

提供负载均衡自愈逻辑的组件lb-operator watch到所述资源声明，并定期同步云端的负载均衡的资源声明的状态信息到Kubernetes集群中；

若云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，则组件lb-operator执行自愈逻辑；

其中，所述云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合包括以下两种中至少一种情况：当集群中的slb的资源声明仍存在，但请求云端时云端的资源声明不存在；和，当集群中的slb的资源声明仍存在，但云端服务组或是监听端口被误修改。

2.根据权利要求1所述的方法，其特征在于，所述组件lb-operator执行自愈逻辑包括：创建新的负载均衡。

3.根据权利要求2所述的方法，其特征在于，所述新的负载均衡，根据状态中上一个负载均衡的配置数据完成配置。

4.根据权利要求1所述的方法，其特征在于，所述组件lb-operator执行自愈逻辑包括：按照负载均衡的初始配置重新配置负载均衡的云端服务组及端口。

5.一种Kubernetes集群的负载均衡可用性提升装置，其特征在于，所述装置包括：

提交模块，配置为用户向Kubernetes集群提交负载均衡的资源声明；

更新模块，配置为提供负载均衡自愈逻辑的组件lb-operator watch到所述资源声明，并定期同步云端的负载均衡的资源声明的状态信息到Kubernetes集群中；

自愈模块，配置为若云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合，则组件lb-operator执行自愈逻辑；

其中，所述云端的负载均衡的资源声明与Kubernetes集群中的资源声明不符合包括以下两种中至少一种情况：当集群中的slb的资源声明仍存在，但请求云端时云端的资源声明不存在；和，当集群中的slb的资源声明仍存在，但云端服务组或是监听端口被误修改。

6.一种Kubernetes集群的负载均衡可用性提升系统，其特征在于，所述系统包括至少一个处理器和存储器；

所述存储器，用于存储一个或多个程序指令；

所述处理器，用于运行一个或多个程序指令，用以执行如权利要求1至4中任一项所述的方法。

7.一种芯片，其特征在于，所述芯片与系统中的存储器耦合，使得所述芯片在运行时调用所述存储器中存储的程序指令，实现如权利要求1至4中任一项所述的方法。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储程序指令，所述程序指令可被如权利要求6所述的系统执行，以实现如权利要求1至4中任一项所述的方法。

Images