CN115640096A - 基于kubernetes的应用管理方法、装置和存储介质 - Google Patents

Abstract

本公开提出一种基于kubernetes的应用管理方法、装置和存储介质，涉及云计算技术领域。本公开的一种基于kubernetes的应用管理方法，包括：通过主用状态的应用容器的伴生单元监控对应的应用容器，获取主用状态的应用容器的流量状态信息；在根据流量状态信息确定处于主用状态的应用容器故障的情况下，停止故障的应用容器提供应用服务，将处于备用状态的应用容器切换为主用状态；和通过切换为主用状态的应用容器提供应用服务。通过这样的方法，解决了主备节点切换过程中的故障节点恢复和可能存在的分歧问题，降低主、备类型应用的运维复杂度，降低人力成本，提高效率。

Description

基于kubernetes的应用管理方法、装置和存储介质

技术领域

本公开涉及云计算技术领域，特别是一种基于kubernetes的应用管理方法、装置和存储介质。

背景技术

Kubernetes(又称K8s)提供一种称为工作负载(workload)的应用管理框架用于部署和管理容器应用，它由workload的定义、描述性模板和控制器组成。K8s实现了多种类型的workload来为应用提供不同的管理功能，比如副本管理、滚动升级/回滚、周期性任务执行、有状态应用管理等。

当前主备类型应用的开发和运维都有较强的复杂性，需要较高的人力成本，包括：开发人员需编写选主(leader)选举逻辑，并依赖外部组件(如zookeeper)实现；客户端需基于zookeeper间接获取主节点信息，增加客户端应用的复杂度；开发人员需解决主备切换过程中异常节点恢复及可能出现的“双脑”问题(主备同时为“主”)；运维人员需同时部署主、备两套组件及其生命周期的运维。

发明内容

本公开的一个目的在于降低运维的复杂度，提高运维效率。

根据本公开的一些实施例的一个方面，提出一种基于kubernetes的应用管理方法，包括：通过主用状态的应用容器的伴生单元监控对应的应用容器，获取主用状态的应用容器的流量状态信息；在根据流量状态信息确定处于主用状态的应用容器故障的情况下，停止故障的应用容器提供应用服务，将处于备用状态的应用容器切换为主用状态；和通过切换为主用状态的应用容器提供应用服务。

在一些实施例中，停止故障的应用容器提供应用服务包括：故障的应用容器的伴生单元拦截并拒绝用户的应用服务请求；删除故障的应用容器并重建应用容器；和，将重建的应用容器设置为备用状态。

在一些实施例中，应用管理方法还包括：通过备用状态的应用容器的伴生单元拦截并拒绝用户的应用服务请求。

在一些实施例中，应用管理方法还包括：在收到的应用服务请求的目标地址为备用状态的应用容器的地址的情况下，将应用服务请求转发至当前的主用状态的应用容器。

在一些实施例中，通过主用状态的应用容器的伴生单元监控对应的应用容器包括：截获用户向应用容器发送的应用服务请求；将应用服务请求转发给对应的应用容器；截获对应的应用容器向用户反馈的流量数据；根据流量数据获取流量状态信息，并将流量数据发送给用户。

在一些实施例中，在流量状态信息中包括超时信息或预定错误信息的情况下，确定处于主用状态的应用容器故障。

在一些实施例中，应用管理方法还包括：接收应用创建请求；根据应用创建请求创建分别提供应用服务的第一应用容器和第二应用容器；设置第一应用容器和第二应用容器的标签，其中，第一应用容器和第二应用容器中，一个的标签为主用状态标签，另一个的标签为备用状态标签；将具备主用状态标签的应用容器的地址确定为访问地址。

根据本公开的一些实施例的一个方面，提出一种基于kubernetes的应用管理装置，包括：多个伴生单元，与应用容器一一对应，被配置为在对应的容器为主用状态的情况下，监控对应的应用容器，获取流量状态信息；控制单元，被配置为在根据流量状态信息确定处于主用状态的应用容器故障的情况下，确定停止故障的应用容器提供应用服务，并控制处于备用状态的应用容器切换为主用状态，通过切换为主用状态的应用容器提供应用服务。

在一些实施例中，伴生单元还被配置为在控制单元确定对应的应用容器停止应用服务的情况下：拦截并拒绝用户的应用服务请求；删除故障的应用容器并重建对应的应用容器；将重建的应用容器设置为备用状态。

在一些实施例中，伴生单元还被配置为：在对应的应用容器为备用状态的情况下，拦截并拒绝用户的应用服务请求。

在一些实施例中，控制单元还被配置为：在收到的应用服务请求的目标地址为备用状态的应用容器的地址的情况下，将应用服务请求转发至当前的主用状态的应用容器。

在一些实施例中，伴生单元被配置为在对应的容器为主用状态的情况下，截获用户向应用容器发送的应用服务请求；将应用服务请求转发给对应的应用容器；截获对应的应用容器向用户反馈的流量数据；根据流量数据获取流量状态信息，并将流量数据发送给用户。

在一些实施例中，控制单元还被配置为：接收应用创建请求；根据应用创建请求创建分别提供应用服务的第一应用容器和第二应用容器；设置第一应用容器和第二应用容器的标签，其中，第一应用容器和第二应用容器中，一个的标签为主用状态标签，另一个的标签为备用状态标签；将具备主用状态标签的应用容器的地址确定为访问地址。

根据本公开的一些实施例的一个方面，提出一种基于kubernetes的应用管理装置，包括：存储器；以及耦接至存储器的处理器，处理器被配置为基于存储在存储器的指令执行上文中任意一种基于kubernetes的应用管理方法。

根据本公开的一些实施例的一个方面，提出一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现上文中任意一种基于kubernetes的应用管理方法的步骤。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本公开的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：

图1为本公开的基于kubernetes的应用管理方法的一些实施例的流程图。

图2为本公开的基于kubernetes的应用管理方法的另一些实施例的流程图。

图3为本公开的基于kubernetes的应用管理装置的一些实施例的示意图。

图4为本公开的基于kubernetes的应用管理装置的一些实施例的运行示意图。

图5为本公开的基于kubernetes的应用管理装置的另一些实施例的示意图。

图6为本公开的基于kubernetes的应用管理装置的又一些实施例的示意图。

具体实施方式

下面通过附图和实施例，对本公开的技术方案做进一步的详细描述。

本公开的基于kubernetes的应用管理方法的一些实施例的流程图如图1所示。

在步骤120中，通过主用状态的应用容器的伴生单元监控对应的应用容器，获取主用状态的应用容器的流量状态信息。在一些实施例中，伴生单元与应用容器一一对应，在一些实施例中，伴生单元可以为独立的容器。

在一些实施例中，伴生单元对于处于主用状态的应用容器可以执行双向流量监控。在上行方向上，伴生单元截获用户向应用容器发送的应用服务请求，并将应用服务请求转发给对应的应用容器。在下行方向上，伴生单元截获对应的应用容器向用户反馈的流量数据，根据流量数据获取流量状态信息，并将流量数据发送给用户。伴生单元基于截取的数据生成流量状态信息。

在步骤130中，根据流量状态信息确定处于主用状态的应用容器是否发生故障。在一些实施例中，若流量状态信息中包括超时信息或预定错误信息，则确定处于主用状态的应用容器故障。

若确定处于主用状态的应用容器发生故障，则执行步骤140。否则，保持当前的主备状态。

在步骤140中，停止故障的应用容器提供应用服务，并将处于备用状态的应用容器切换为主用状态。在一些实施例中，可以修改应用容器的状态标签，将故障的应用容器修改为备用状态标签(如standby标签)，将原作为备用的应用容器的标签修改为主用状态标签(如active标签)，从而实现主、备容器切换。

在步骤150中，通过切换为主用状态的应用容器提供应用服务。在一些实施例中，可以通过将目的地址为故障的应用容器的用户请求转发至新切换为主用状态的应用容器的方式，实现通过切换为主用状态的应用容器提供应用服务，从而实现用户侧无感知的主备切换，降低对客户端的干扰，提高用户友好度。

通过这样的方法，解决了主备节点切换过程中的故障节点恢复和可能存在的“双脑”问题。通过该新型工作负载，可极大降低主、备类型应用的运维复杂度，降低人力成本，提高效率。

在一些实施例中，可以通过生成基于kubernetes的工作负载的方式实现本公开的基于kubernetes的应用管理方法，通过ActivelySet控制器的运行过程，以本公开的基于kubernetes的应用管理方法作为控制逻辑运行。通过这样的方法，能够提高本公开的基于kubernetes的应用管理方法的生成效率和使用的便捷度，便于与基于kubernetes的应用服务的兼容使用，有利于推广应用。

本公开的基于kubernetes的应用管理方法的另一些实施例的流程图如图2所示。

在步骤211中，控制单元接收应用创建请求。

在步骤212中，根据应用创建请求创建分别提供应用服务的第一应用容器和第二应用容器，两者互为主备。在一些实施例中，第一应用容器和第二应用容器预设有相同的服务。在一些实施例中，每个应用容器会绑定一个伴生单元，用以监控该应用容器的状态。

在步骤213中，设置第一应用容器和第二应用容器的标签，其中，第一应用容器和第二应用容器中，一个的标签为主用状态标签，另一个的标签为备用状态标签。在应用运行中，带有主用状态标签的应用容器提供服务，带有备用状态标签的应用容器静默。

在步骤214中，将具备主用状态标签的应用容器的地址确定为访问地址。访问地址可以提供给用户(如发送给客户端)，供用户向访问地址发起请求。

通过这样的方法，在应用生成时，控制单元即启动自动部署和维护主、备两套组件，提高了应用开发效率；继而通过如图1所示实施例中的方式进行应用管理，提高了运维管理效率，降低人力成本。

在一些实施例中，伴生单元除了自身对应的应用容器处于主用状态的情况下执行监控操作外，还在自身对应的应用容器处于备用状态的情况下拦截并拒绝用户的应用服务请求。通过这样的方法，能够避免由于各部分处理不同步，造成的用户请求导引至故障的应用容器的情况，避免无法提供有效服务同时又影响容器恢复，提高应用服务的可靠性。

在一些实施例中，伴生单元在自身对应的应用容器处于备用状态的情况下拦截，还删除故障的应用容器并重建应用容器，将重建的应用容器设置为备用状态。通过这样的方法，故障的应用容器能够及时删除和重建，从而提高恢复效率，避免新切换为主用状态的容器故障时影响切换使用，进一步提高了应用服务的可靠性。

本公开的基于kubernetes的应用管理装置300的一些实施例的示意图如图3所示。

基于kubernetes的应用管理装置300中包括多个伴生单元，如图中所示的伴生单元321和322。伴生单元与应用容器一一对应，每个伴生容器能够在其对应的容器为主用状态的情况下，监控该应用容器，获取流量状态信息。在一些实施例中，每个伴生单元还能够在对应的应用容器为备用状态的情况下，拦截并拒绝用户的应用服务请求，从而避免接收用户请求但难以反馈有效信息，降低对于备用状态的应用容器的消耗，提高备用状态的应用容器的稳定性。

控制单元31能够在根据流量状态信息确定当前处于主用状态的应用容器故障的情况下，确定停止故障的应用容器提供应用服务，并控制处于备用状态的应用容器切换为主用状态，通过切换为主用状态的应用容器提供应用服务。

这样的装置解决了主备节点切换过程中的故障节点恢复和可能存在的“双脑”问题，能够降低主、备类型应用的运维复杂度，降低人力成本，提高效率。

在一些实施例中，伴生单元还能够在控制单元确定对应的应用容器停止应用服务的情况下，拦截并拒绝用户的应用服务请求，从而避免由于各部分处理不同步，造成的用户请求导引至故障的应用容器的情况，提高应用服务的可靠性。

在一些实施例中，伴生单元还能够在控制单元确定对应的应用容器停止应用服务的情况下，删除故障的应用容器并重建对应的应用容器，且将重建的应用容器设置为备用状态。这样的装置中故障的应用容器能够及时删除和重建，从而提高恢复效率，避免新切换为主用状态的容器故障影响切换使用，进一步提高了应用服务的可靠性。

在一些实施例中，控制单元31还能够在收到的应用服务请求的目标地址为备用状态的应用容器的地址的情况下，将应用服务请求转发至当前的主用状态的应用容器，通过切换为主用状态的应用容器提供应用服务，从而实现用户侧无感知的主备切换，降低对客户端的干扰，提高用户友好度。

在一些实施例中，伴生单元对于主用状态的应用容器的监测可以为双向流量监测。在上行方向上，伴生单元截获用户向应用容器发送的应用服务请求，并将应用服务请求转发给对应的应用容器。在下行方向上，伴生单元截获对应的应用容器向用户反馈的流量数据，根据流量数据获取流量状态信息，并将流量数据发送给用户。伴生单元基于截取的数据生成流量状态信息，并将流量信息发送给控制单元31。

这样的装置能够通过双向监测提高对于容器故障的敏感度，进而及时进行主备切换，提高应用服务的可靠度。

在一些实施例中，控制单元31还能够在接收到应用创建请求后，根据应用创建请求创建分别提供应用服务的第一应用容器和第二应用容器，两者互为主备。在一些实施例中，第一应用容器和第二应用容器预设有相同的服务。在一些实施例中，每个应用容器会绑定一个伴生单元，用以监控该应用容器的状态。控制单元31设置第一应用容器和第二应用容器的标签，其中，一个的标签为主用状态标签，另一个的标签为备用状态标签。进一步的，控制单元31将具备主用状态标签的应用容器的地址确定为访问地址。访问地址提供给用户(如发送给客户端)，供用户向访问地址发起请求。

这样的装置能够在应用生成时，控制单元即启动自动部署和维护主、备两套组件，提高了应用开发效率；继而通过如图1所示实施例中的方式进行应用管理，提高了运维管理效率，降低人力成本。

本公开的基于kubernetes的应用管理装置的一些实施例的运行示意图如图4所示。

k8s API Server(kubernetes应用程序接口服务器)上方的部分为配置信息，下方的部分为支持应用服务的构成组件，包括本公开的基于kubernetes的应用管理装置和针对应用服务生成的应用容器：容器A、B。以横向的切换箭头为界，左右分别为以容器A为主用状态和以容器B为主用状态的情况下的示意图，左右可以根据当前主用状态的应用容器的故障情况来回切换。

控制单元可以为ActivelySet控制器41，在得到用户的应用创建请求(如图中所示，需要建立名称为测试test的应用)时，通过创建service作为唯一访问入口，如图4中所示的Service test配置信息，设置有应用的类型和名称等信息，并绑定有容器的主、备状态标签。针对该应用的应用容器包括A、B两个，容器A在建立之初具备主用状态标签active，容器B在建立之初具备备用状态标签standby。

此时，对应的应用服务中，用户向应用容器A对应的Service IP(服务地址)发起访问请求，该请求仅会转发至应用容器A，由其对应的Sidecar(伴生单元)421拦截。Sidecar421监控应用容器A的应用可用状态，并在ActivelySet控制器41的驱动下控制应用容器A的可访问性。Sidecar 421将获得的流量状态信息发送给ActivelySet控制器41进行识别。ActivelySet控制器41在根据流量状态信息确定容器A故障时，执行图4中从左到右的切换过程。ActivelySet控制器41控制修改容器的配置信息，将容器A的标签修改为备用状态标签standby，将容器B的标签修改为主用状态标签active，从而向容器A发起的请求会被转发至容器B。ActivelySet控制器41控制Sidecar 421拦截并拒绝向容器A发送的应用服务请求，触发Sidecar 421删除当前的容器A，并新建容器A。新建的容器A沿用之前的标签standby。

ActivelySet控制器41控制容器B的伴生单元Sidecar 422执行对容器B的流量监控操作，Sidecar 422将生成的流量状态信息反馈给ActivelySet控制器41，以便ActivelySet控制器41确认容器B是否发生故障，进而在容器B发生故障的情况下，实现图4中从右向左的切换过程。

这样的基于kubernetes的应用管理装置通过控制service与主备应用的标签绑定关系实现选主，基于通信代理组件sidecar监控应用可用状态并控制应用的可访问性，控制器基于监控信息自主实现主备切换，提高应用生成和管控效率；能够控制应用访问流量有效防止“脑裂”现象，提高运维效率和可靠度；客户能够保持原始目标访问地址不变，客户端无需感知主备切换过程，提高用户体验。

本公开基于kubernetes的应用管理装置的一个实施例的结构示意图如图5所示。基于kubernetes的应用管理装置包括存储器501和处理器502。其中：存储器501可以是磁盘、闪存或其它任何非易失性存储介质。存储器用于存储上文中基于kubernetes的应用管理方法的对应实施例中的指令。处理器502耦接至存储器501，可以作为一个或多个集成电路来实施，例如微处理器或微控制器。该处理器502用于执行存储器中存储的指令，能够降低主、备类型应用的开发和运维复杂度，降低人力成本，提高运维效率。

在一个实施例中，还可以如图6所示，基于kubernetes的应用管理装置600包括存储器601和处理器602。处理器602通过BUS总线603耦合至存储器601。该基于kubernetes的应用管理装置600还可以通过存储接口604连接至外部存储装置605以便调用外部数据，还可以通过网络接口606连接至网络或者另外一台计算机系统(未标出)。此处不再进行详细介绍。

在该实施例中，通过存储器存储数据指令，再通过处理器处理上述指令，能够降低主、备类型应用的运维复杂度，降低人力成本，提高构建和运维效率。

在另一个实施例中，一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现基于kubernetes的应用管理方法对应实施例中的方法的步骤。本领域内的技术人员应明白，本公开的实施例可提供为方法、装置、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本公开是参照根据本公开实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

至此，已经详细描述了本公开。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。

可能以许多方式来实现本公开的方法以及装置。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法以及装置。用于所述方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于执行根据本公开的方法的程序的记录介质。

最后应当说明的是：以上实施例仅用以说明本公开的技术方案而非对其限制；尽管参照较佳实施例对本公开进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本公开的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本公开技术方案的精神，其均应涵盖在本公开请求保护的技术方案范围当中。

Claims (15)

1.一种基于kubernetes的应用管理方法，包括：

通过主用状态的应用容器的伴生单元监控对应的应用容器，获取主用状态的应用容器的流量状态信息；

在根据所述流量状态信息确定处于主用状态的应用容器故障的情况下，停止故障的应用容器提供应用服务，将处于备用状态的应用容器切换为主用状态；和

通过切换为主用状态的应用容器提供应用服务。

2.根据权利要求1所述的方法，其中，所述停止故障的应用容器提供应用服务包括：

故障的应用容器的伴生单元拦截并拒绝用户的应用服务请求；

删除故障的应用容器并重建应用容器；和

将重建的应用容器设置为备用状态。

3.根据权利要求1所述的方法，还包括：

通过备用状态的应用容器的伴生单元拦截并拒绝用户的应用服务请求。

4.根据权利要求1所述的方法，还包括：

在收到的应用服务请求的目标地址为备用状态的应用容器的地址的情况下，将所述应用服务请求转发至当前的主用状态的应用容器。

5.根据权利要求1所述的方法，其中，通过主用状态的应用容器的伴生单元监控对应的应用容器包括：

截获用户向所述应用容器发送的应用服务请求；

将所述应用服务请求转发给对应的应用容器；

截获对应的应用容器向用户反馈的流量数据；和

根据所述流量数据获取所述流量状态信息，并将所述流量数据发送给用户。

6.根据权利要求1所述的方法，其中，

在所述流量状态信息中包括超时信息，或预定错误信息的情况下，确定处于主用状态的应用容器故障。

7.根据权利要求1所述的方法，还包括：

接收应用创建请求；

根据所述应用创建请求创建分别提供应用服务的第一应用容器和第二应用容器；

设置所述第一应用容器和所述第二应用容器的标签，其中，所述第一应用容器和所述第二应用容器中，一个的标签为主用状态标签，另一个的标签为备用状态标签；

将具备主用状态标签的应用容器的地址确定为访问地址。

8.一种基于kubernetes的应用管理装置，包括：

多个伴生单元，与应用容器一一对应，被配置为在对应的容器为主用状态的情况下，监控对应的应用容器，获取流量状态信息；

控制单元，被配置为在根据所述流量状态信息确定处于主用状态的应用容器故障的情况下，确定停止故障的应用容器提供应用服务，并控制处于备用状态的应用容器切换为主用状态，通过切换为主用状态的应用容器提供应用服务。

9.根据权利要求8所述的装置，其中，所述伴生单元还被配置为在所述控制单元确定对应的应用容器停止应用服务的情况下：

拦截并拒绝用户的应用服务请求；

删除故障的应用容器并重建对应的应用容器；和

将重建的应用容器设置为备用状态。

10.根据权利要求8所述的装置，其中，所述伴生单元还被配置为：在对应的应用容器为备用状态的情况下，拦截并拒绝用户的应用服务请求。

11.根据权利要求8所述的装置，其中，所述控制单元还被配置为：在收到的应用服务请求的目标地址为备用状态的应用容器的地址的情况下，将所述应用服务请求转发至当前的主用状态的应用容器。

12.根据权利要求8所述的装置，其中，伴生单元被配置为在对应的容器为主用状态的情况下，

截获用户向所述应用容器发送的应用服务请求；

将所述应用服务请求转发给对应的应用容器；

截获对应的应用容器向用户反馈的流量数据；和

根据所述流量数据获取所述流量状态信息，并将所述流量数据发送给用户。

13.根据权利要求8所述的装置，其中，所述控制单元还被配置为：

接收应用创建请求；

根据所述应用创建请求创建分别提供应用服务的第一应用容器和第二应用容器；

设置所述第一应用容器和所述第二应用容器的标签，其中，所述第一应用容器和所述第二应用容器中，一个的标签为主用状态标签，另一个的标签为备用状态标签；

将具备主用状态标签的应用容器的地址确定为访问地址。

14.一种基于kubernetes的应用管理装置，包括：

存储器；以及

耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器的指令执行如权利要求1至7任一项所述的方法。

15.一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现权利要求1至7任意一项所述的方法的步骤。

Images