CN114185558A - 基于K8s的原生应用选主方法、装置及存储介质 - Google Patents

Abstract

本发明提供一种基于K8s的原生应用选主方法、装置及存储介质，方法包括根据获取到的针对目标应用的部署信息，基于Kubernetes平台将目标应用部署在目标数量的Pod中；部署信息包括目标应用部署的Pod数量、可同时运行的Pod的数量，Pod包括一个对应的应用容器，应用容器中存储有目标应用的代码；基于预设回调准入机制，在针对目标应用部署的每个Pod中注入选主容器信息；接收每个Pod发送的目标数据，将目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；将接收到写入成功信息的Pod确定为原生应用的主Pod。本方案有效解决了云原生选主侵入性的问题。

Description

基于K8s的原生应用选主方法、装置及存储介质

技术领域

本发明涉及集群部署技术领域，尤涉及一种基于K8s的原生应用选主方法、装置及存储介质。

背景技术

Kubernetes，简称K8s，Kubernetes是一个跨主机集群的开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作，提供以容器为中心的基础架构。综合了平台即服务(PAAS)的简单性以及基础架构即服务(IAAS)的灵活性，并促进跨基础设施供应商的可移植性。云原生(Cloud Native)是一种构建和运行应用程序的方法。随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。

Kubernetes是容器编排系统，用于容器管理，容器间的负载均衡。云原生分布式应用系统为了保证其可靠性，一般都会多节点提供服务，各别节点的故障不会影响系统的可用性。目前通用的方案是使用多副本存储，这就会引入一个新的问题——多个副本间的数据一致性保障。所以就有了各种数据一致性协议。例如：Zookeeper的Zab、Etcd使用的Raft和无比复杂的Paxos等等。这些一致性协议都有一个共同的特点，那就是都有一个主节点(Leader)负责数据的同步。然而因业务需求，如一些有状态应用在某一时刻只能有一个应用实例使用，其他实例作为备份实例，因此针对以上这种使用场景需要对应用进行选主，确定对应的主应用实例。

在上述场景中，而现有的选主方式一般为基于中间件(Etcd)或第三方系统(如HAProxy)实现云原生分布式应用选主。例如，Etcd作为KV存储，会为每个key都保留历史版本，比如用于发布回滚、配置历史等，历史版本越多，存储空间越大，性能越差，直到Etcd到达空间配额限制的时候，Etcd的写入将会被禁止变为只读，影响线上服务。现有的基于中间件或第三方系统实现云原生分布式应用选主的方式，不能与云原生领域进行很好的结合；需要硬编码实现，对现有应用逻辑具有侵入性；运维成本较高，选主效率相对较低。

发明内容

有鉴于此，本发明提供了一种基于K8s的原生应用选主方法、装置及存储介质，以解决现有技术中对云原生应用选主侵入性较高的技术问题。

第一方面，根据本发明实施例提供的一种基于K8s的原生应用选主方法，所述方法包括，

根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中；其中所述部署信息包括目标应用部署的Pod的数量，以及可同时运行的Pod的数量，每个Pod包括一个对应的应用容器，所述应用容器中存储有目标应用的代码；

基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息；

接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；

将接收到写入成功信息的Pod确定为原生应用的主Pod。

在一个实施方式中，所述基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息，包括：

接收到任一个Pod发送的选主容器需求信息后，将所述选主容器需求信息发送至每一个Pod，并通过预设插件在每个Pod中注册选主容器信息配置并注入选主容器。

在一个实施方式中，所述接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod，包括：

将Lease资源反馈的针对一个Pod的写入成功信息反馈至对应的Pod，并将反馈的写入失败信息反馈给其他Pod；

其中，同一时刻向Lease资源写入目标数据成功的Pod最多为一个。

在一个实施方式中，所述方法还包括：

若任意一个Pod写入的目标数据时，若确定目标数据是否已经存在在Lease资源中、目标数据的数据状态为有效且写入目标数据的为其他Pod，则向本次写入目标数据的Pod反馈写入失败信息；

否则，则向写入成功的Pod反馈写入成功信息。

在一个实施方式中，所述方法还包括：

创建所述预先创建的Lease资源，若创建成功，则反馈创建成功消息；

否则，反馈创建失败消息。

在一个实施方式中，所述方法还包括：

当主Pod的应用容器发生异常时，则控制主Pod中的选主容器不再对对应的Lease资源续期，以从其他Pod中再次选取主Pod。

第二方面，根据本发明实施例提供的一种基于K8s的原生应用选主装置，所述装置包括：

部署模块，用于根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中；其中所述部署信息包括目标应用部署的Pod的数量，以及可同时运行的Pod的数量，每个Pod包括一个对应的应用容器，所述应用容器中存储有目标应用的代码；

注入模块，用于基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息；

选主模块，用于接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；

确认模块，用于将接收到写入成功信息的Pod确定为原生应用的主Pod。

在一个实施方式中，所述基于K8s的原生应用选主装置还包括：

断续模块，用于当主Pod的应用容器发生异常时，则控制主Pod中的选主容器不再对对应的Lease资源续期，以从其他Pod中再次选取主Pod。

第三方面，根据本发明实施例提供的一种基于K8s的原生应用选主装置，包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而实现第一方面中任一项所述的基于K8s的原生应用选主方法。

第四方面，根据本发明实施例提供的一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储有计算机指令，所述计算机指令被处理器执行时实现第一方面中任一项所述的基于K8s的原生应用选主方法。

本发明实施例提供的基于Kubernetes的原生应用选主方法、装置及存储介质，至少具有如下有益效果：

本发明实施例提供的基于K8s的原生应用选主方法、装置及存储介质，可以在上述方式中，具体地，通过根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中，通过将每个Pod均对应部署一个应用容器，用于存储有目标应用的代码。通过基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息；通过接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；将接收到写入成功信息的Pod确定为原生应用的主Pod。本方案，通过选主容器发送对应的目标数据，选主容器发送的目标数据包括对应Pod的标识信息，并尝试将含有对应Pod的标识信息的目标数据写入Lease资源，成功写入Lease资源对应的Pod为主Pod。通过Pod中的对应的选主容器进行选主，从而确定对应的主Pod，确定对应的主应用实例，避免使用中间件Etcd或第三方系统实现云原生分布式应用选主。从而在Kubernetes中，当对应应用进行高可用多副本部署时，可无侵入地完成应用选主，减少了中间件或是第三方系统对云原生分布式应用的干涉，减少了侵入性，保证了应用的正常运行和高可用。通过变更准入回调机制在Pod实例中注入选主容器信息，利用注入的选主容器进行参与选主，使得选主原理和应用实例结合更充分，便于对云原生分布式系统的选主监控和运维，减少了运行成本；且进一步地提高了云原生分布式应用的适用性、提高了选主效率。

附图说明

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

图1为本发明实施例提供的一种基于K8s的原生应用选主方法流程图；

图2为本发明实施例提供的一种基于K8s的原生应用的部署结构示意图；

图3为基于图2的注入选主容器信息的示意图；

图4为本发明实施例提供的一种基于K8s的原生应用选主架构示意图；

图5为本发明实施例提供的一种基于K8s的原生应用选主方法的部分流程图；

图6为本发明实施例提供的一种基于K8s的原生应用选主装置的框图；

图7为本发明实施例提供的一种基于K8s的原生应用选主装置的结构示意图。

具体实施方式

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

此外，下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

实施例1

图1为本发明实施例提供的一种基于K8s的原生应用选主方法的流程，虽然下文描述的过程包括以特定的顺序出现的多个操作，但是应该清楚地了解到，这些过程也可以包括更多或者更少的操作，这些操作可以顺序执行或者并行执行。

本实施例提供了一种基于K8s的原生应用选主方法，参见图2所示，所述方法包括如下步骤：

步骤S101、根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中；其中所述部署信息包括目标应用部署的Pod的数量，以及可同时运行的Pod的数量，每个Pod包括一个对应的应用容器，所述应用容器中存储有目标应用的代码。

在上述实施方式中，具体地，基于Kubernetes平台，将目标应用部署在目标数量的Pod中。在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod。Pod是管理、创建、计划的最小单元。一个Pod相当于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用可能是在同一个物理主机或虚拟机上。举例来说，参见图2所示，获取到的针对目标应用的部署信息为：在Kubernetes平台中，对目标应用APP1部署4个Pod，同时运行的Pod的数量为一个。则基于Kubernetes平台将目标应用APP1部署在4个Pod中，每个Pod包括一个对应的应用容器，所述应用容器中存储有目标应用的代码；进一步地，还应对目标应用APP1部署相应的Service服务，具体参见图2所示。

步骤S102、基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息。

在上述实施方式中，具体地，Kubernetes的回调准入机制是一种用于接收准入请求并对其进行处理的HTTP回调机制。目前有两种类型：验证准入机制和变更准入机制。变更准入控制器指执行可用于变更操作的准入控制器，是指在请求通过认证和授权之后，可用于对其进行变更的一些代码或功能。变更准入控制器，它可以修改被它接受的对象，这就引出了它的另一个作用，将相关资源作为请求处理的一部分进行变更。示例性地，参见图3所示，结合图2所示，对图2所示的在Kubernetes部署后的APP1，变更准入控制器通过对Server发送变更准入请求来实现对APP1资源的更改。变更准入控制器是一种插件形式的准入控制器,对应预设的选主插件可以从变更准入控制器配置中获取所有感兴趣的准入机制。然后变更准入控制器监听对应接口服务器的请求，拦截满足条件的请求，并通知对应选主插件，进而获得插件反馈的注册选主容器信息，并执行变更操作，进而针对每个Pod注入选主容器信息。

步骤S103、接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod。

在上述实施方式中，具体地，接收每个Pod通过其选主容器发送的目标数据，其中，所述目标数据包括对应的Pod的标识信息。示例性地，目标数据为“app-lease：Podn”，其中app-lease表示目标数据名称，Podn表示目标数据实际对应的值，Podn对应Pod的标识信息。将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod。其中，同一时刻向Lease资源写入目标数据成功的Pod最多为一个。将预先创建的Lease资源反馈的写入成功信息发送至写入目标数据成功的Pod，将预先创建的Lease资源反馈的写入失败信息发送至写入目标数据失败的Pod。示例性地，写入成功信息为200，写入失败信息为400，则将200返回给写入目标数据成功的Pod，则将400返回给写入目标数据失败的Pod。

步骤S104、将接收到写入成功信息的Pod确定为原生应用的主Pod。

在上述实施方式中，具体地，将接收到写入成功信息的Pod确定为原生应用的主Pod。换句话说，即就是当当前Pod接收到写入成功信息，则确定当前Pod确定为原生应用的主Pod。利用Kubernetes特性，配置就绪探针，就绪探针用于探测Pod写入目标数据是否成功，如果写入成功，对应readinessProbe为就绪，当前Pod则为Ready状态；如果写入失败，readinessProbe为不就绪，Pod状态则为Ready。Service对应的Endpoint后端，是根据Pod是否Ready状态确定的。如果写入失败，Service中会将该Pod从Service的后端Endpoints中去掉。因此应用流量并不会转发到该Pod实例中，只有当写入成功，就绪探针探测就绪了，才能访问到该Pod的实例。示例性地，判断当前Pod接收到的向Lease资源写入目标数据反馈的写入成败信息；若接收到的信息为400，则确定当前Pod不是原生应用的主Pod；若接收到的信息为200，则确定当前Pod为原生应用的主Pod。示例性地，参见图4所示，Pod1向Lease资源写入目标数据“app-lease：Pod1”写入成功，readinessProbe为就绪，当前Pod1则为Ready状态；则对应Pod2向Lease资源写入目标数据“app-lease：Pod2”写入失败，readinessProbe为不就绪，当前Pod2则状态为UnReady，图中对应以“Watch”表示状态，则对应Pod3向Lease资源写入目标数据“app-lease：Pod3”写入失败，readinessProbe为不就绪，当前Pod3则状态为UnReady，图中对应以“Watch”表示状态。此时并确定Service服务器对应的Endpoint：Pod1，并将Pod2、Pod3从Service的后端Endpoints中去掉，确定Pod1为原生应用的主Pod，Pod1对应Ready就绪运行状态，Pod2、Pod3对应Backup备份状态。

在上述方式中，具体地，通过根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中，通过将每个Pod均对应部署一个应用容器，用于存储有目标应用的代码。通过基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息；通过接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；将接收到写入成功信息的Pod确定为原生应用的主Pod。通过选主容器发送对应的目标数据，选主容器发送的目标数据包括对应Pod的标识信息，并尝试将含有对应Pod的标识信息的目标数据写入Lease资源，成功写入Lease资源对应的Pod为主Pod。通过Pod中的对应的选主容器进行选主，从而确定对应的主Pod，确定对应的主应用实例。避免使用中间件Etcd或第三方系统实现云原生分布式应用选主。从而在Kubernetes中，当对应应用进行高可用多副本部署时，可无侵入地完成应用选主，减少了中间件或是第三方系统对云原生分布式应用的干涉，减少了侵入性，保证了应用的正常运行和高可用。通过变更准入回调机制在Pod实例中注入选主容器信息，利用注入的选主容器进行参与选主，使得选主原理和应用实例结合更充分，便于对云原生分布式系统的选主监控和运维，减少了运行成本；且进一步地提高了云原生分布式应用的适用性、提高了选主效率。

进一步地，可以提高在Kubernetes集群中部署的镜像的可靠性，避免收到侵入攻击。且在Pod内尽量不使用root用户，或者尽量不开启特权容器等，通过选主服务器可以减少特选区分，提高应用部署效率。例如可以通过选主容器校验服务是否已经有对应的信息存在，减少了资源的占用，避免资源配额限制，进一步提高了选主的效率。

在一个实施方式中，所述基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息，包括：

接收到任一个Pod发送的选主容器需求信息后，将所述选主容器需求信息发送至每一个Pod，并通过预设插件在每个Pod中注册选主容器信息配置并注入选主容器。

在上述实施方式中，具体地，在部署Pod，在Pod定义对应的label，用于指定该应用需要选主。示例性地，定义编码部分如下所示：

metadata:

labels:

leader-election:true

其中，通过布尔值“true”指定该应用需要选主。同理，对应leader-election:false，指定该应用不需要选主。

具体地，通过定义label的方式，确定对应应用的选主需求，便于依据label对应的信息，生成对应的选主容器需求信息。进而提高了对每个Pod注入选主容器信息的效率。通过定义的label信息，确定每个Pod注入选主容器信息，对应定义的信息较少，进而减少了侵入性。

在一个实施方式中，所述接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod，包括：

将Lease资源反馈的针对一个Pod的写入成功信息反馈至对应的Pod，并将反馈的写入失败信息反馈给其他Pod；

其中，同一时刻向Lease资源写入目标数据成功的Pod最多为一个。

在一个实施方式中，所述方法还包括：

若任意一个Pod写入的目标数据时，若确定目标数据是否已经存在在Lease资源中、目标数据的数据状态为有效且写入目标数据的为其他Pod，则向本次写入目标数据的Pod反馈写入失败信息；

否则，则向写入成功的Pod反馈写入成功信息。

在一个实施方式中，所述方法还包括：

当主Pod的应用容器发生异常时，则控制主Pod中的选主容器不再对对应的Lease资源续期，以从其他Pod中再次选取主Pod。

在上述实施方式中，示例性地，参见图5所示，图中，200表示反馈的写入成功信息，400表示反馈的写入失败信息。

首先判断应用容器是否已成功启动，若为否，则返回400；

若应用容器已成功启动，则获取Lease资源中的对应的目标数据，具体地，可以依据对应的名称标识获取对应的目标数据，例如，通过查询名称“app-lease”以获取对应的目标数据；

判断目标数据是否存在，如果目标数据不存在，则向Lease资源中写入所述目标数据，如果写入目标数据成功，则返回200，否则返回400；

如果目标数据存在，则判断该存在的数据的拥有者是否为其他Pod且该存在的数据还未过期，如果是，则返回400；

如果目标数据存在，且判断该存在的数据的拥有者不是其他Pod或者该存在的数据已过期，则更新该存在的数据，即重新写入对应的目标数据，若写入成功，则返回200，否则返回400。

在一个实施方式中，所述方法还包括：

创建所述预先创建的Lease资源，若创建成功，则反馈创建成功消息；

否则，反馈创建失败消息。

实施例2

图6是本发明实施例提供的一种基于Kubernetes的原生应用选主装置框图，本实施例以该装置应用于图1所示的基于Kubernetes的原生应用选主方法进行说明。所述基于Kubernetes的原生应用选主装置至少包括以下几个模块：

部署模块61，用于根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中；其中所述部署信息包括目标应用部署的Pod的数量，以及可同时运行的Pod的数量，每个Pod包括一个对应的应用容器，所述应用容器中存储有目标应用的代码；

注入模块62，用于基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息；

选主模块63，用于接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；

确认模块64，用于将接收到写入成功信息的Pod确定为原生应用的主Pod。

在一个实施方式中，所述基于Kubernetes的原生应用选主装置还包括：

断续模块，用于当主Pod的应用容器发生异常时，则控制主Pod中的选主容器不再对对应的Lease资源续期，以从其他Pod中再次选取主Pod。

本申请实施例提供的基于Kubernetes的原生应用选主装置，可用于如上实施例1中执行的方法，相关细节参考上述方法实施例，其实现原理和技术效果类似，在此不再赘述。

需要说明的是：上述实施例中提供的基于Kubernetes的原生应用选主装置在进行动态处理虚拟化资源时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将基于Kubernetes的原生应用选主装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的基于Kubernetes的原生应用选主装置与基于Kubernetes的原生应用选主方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

实施例3

本发明实施例提供的一种基于Kubernetes的原生应用选主装置，用于基于Kubernetes的原生应用选主，如图7所示，该电子设备包括处理器701和存储器702，其中处理器701和存储器702可以通过总线或者其他方式连接，图示中以通过总线连接为例。

处理器701可以为中央处理器(Central Processing Unit，CPU)也可以为其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、图形处理器(GraphicsProcessing Unit，GPU)、嵌入式神经网络处理器(Neural-network Processing Unit，NPU)或者其他专用的深度学习协处理器、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。

存储器702作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本发明实施例中基于Kubernetes的原生应用选主方法对应的程序指令/模块。处理器701通过运行存储在存储器702中的非暂态软件程序、指令以及模块，从而执行处理器的各种功能应用以及数据处理，即实现上述方法实施例1中的基于Kubernetes的原生应用选主方法。

存储器702可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储处理器701所创建的数据等。此外，存储器702可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器702可选包括相对于处理器701远程设置的存储器，这些远程存储器可以通过网络连接至处理器701。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述一个或者多个模块存储在所述存储器702中，当被所述处理器701执行时，执行如图1所示基于K8的原生应用选主方法。

本发明实施例还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的基于K8s的原生应用选主方法。其中，所述非暂态计算机可读存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)、随机存储记忆体(Random Access Memory，RAM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，缩写：HDD)或固态硬盘(Solid-StateDrive，SSD)等；所述非暂态计算机可读存储介质还可以包括上述种类的存储器的组合。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置或非暂态计算机可读存储介质均可涉及或包含计算机程序产品。

因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

显然，以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。而由此所引伸出的显而易见的变化或变动仍处于本发明创造的保护范围之中。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于K8s的原生应用选主方法，其特征在于，所述方法包括：

根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中；其中所述部署信息包括目标应用部署的Pod的数量，以及可同时运行的Pod的数量，每个Pod包括一个对应的应用容器，所述应用容器中存储有目标应用的代码；

基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息；

接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；

将接收到写入成功信息的Pod确定为原生应用的主Pod。

2.根据权利要求1所述的基于K8s的原生应用选主方法，其特征在于，所述基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息，包括：

接收到任一个Pod发送的选主容器需求信息后，将所述选主容器需求信息发送至每一个Pod，并通过预设插件在每个Pod中注册选主容器信息配置并注入选主容器。

3.根据权利要求2所述的基于K8s的原生应用选主方法，其特征在于，所述接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod，包括：

将Lease资源反馈的针对一个Pod的写入成功信息反馈至对应的Pod，并将反馈的写入失败信息反馈给其他Pod；

其中，同一时刻向Lease资源写入目标数据成功的Pod最多为一个。

4.根据权利要求3所述的基于K8s的原生应用选主方法，其特征在于，所述方法还包括：

若任意一个Pod写入的目标数据时，若确定目标数据是否已经存在在Lease资源中、目标数据的数据状态为有效且写入目标数据的为其他Pod，则向本次写入目标数据的Pod反馈写入失败信息；

否则，则向写入成功的Pod反馈写入成功信息。

5.根据权利要求4所述的基于K8s的原生应用选主方法，其特征在于，所述方法还包括：

创建所述预先创建的Lease资源，若创建成功，则反馈创建成功消息；

否则，反馈创建失败消息。

6.根据权利要求5所述的基于K8s的原生应用选主方法，其特征在于，所述方法还包括：

当主Pod的应用容器发生异常时，则控制主Pod中的选主容器不再对对应的Lease资源续期，以从其他Pod中再次选取主Pod。

7.一种基于K8s的原生应用选主装置，其特征在于，所述装置包括：

部署模块，用于根据获取到的针对目标应用的部署信息，基于Kubernetes平台将所述目标应用部署在目标数量的Pod中；其中所述部署信息包括目标应用部署的Pod的数量，以及可同时运行的Pod的数量，每个Pod包括一个对应的应用容器，所述应用容器中存储有目标应用的代码；

注入模块，用于基于预设回调准入机制，在针对目标应用部署的每个Pod中均注入选主容器信息；

选主模块，用于接收每个Pod通过其选主容器发送的目标数据，将所述目标数据写入预先创建的Lease资源，并将预先创建的Lease资源反馈的写入成败信息发送至对应的Pod；

确认模块，用于将接收到写入成功信息的Pod确定为原生应用的主Pod。

8.根据权利要求7所述的基于K8s的原生应用选主装置，其特征在于，所述装置还包括：

断续模块，用于当主Pod的应用容器发生异常时，则控制主Pod中的选主容器不再对对应的Lease资源续期，以从其他Pod中再次选取主Pod。

9.一种基于K8s的原生应用选主装置，其特征在于，包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行权利要求1-6中任一项所述的基于K8s的原生应用选主方法。

10.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储有计算机指令，所述计算机指令被处理器执行时实现如权利要求1-6中任一项所述的基于K8s的原生应用选主方法。

Images