CN114816662A - 应用于Kubernetes的容器编排方法和系统 - Google Patents

Abstract

一种应用于Kubernetes的容器编排方法和系统，该方法包括：Webhook组件拦截并扫描Pod创建请求，以确定目标容器中是否包括第一环境变量，第一环境变量用于指示目标容器为sidecar容器；在目标容器包括第一环境变量的情况下，对目标容器进行DownwardAPI形式化改造；API服务器在Downward API形式化改造完成后，向分布式数据库写入目标Pod的Pod配置信息，对sidecar容器进行Downward API形式化改造，以便于后续通过Downward API修改容器的启动命令，实现sidecar容器的退出机制，实现了容器退出方案的普适性。

Description

应用于Kubernetes的容器编排方法和系统

技术领域

本申请涉及信息技术领域，尤其涉及一种应用于Kubernetes的容器编排方法和系统。

背景技术

Kubernetes是一种用于自动部署、扩展和管理容器化目标应用程序的开源系统。目前，Kubernetes已经成为全世界容器编排领域的通用标准，越来越多的类似人工智能(artificial intelligence，AI)计算的短任务也逐渐开始流行采用Kubernetes进行作业编排。

但是当用户将Kubernetes短任务编排用于生产环境，发现作为Kubernetes最小编排单元的Pod，在面对长短任务容器混合编排时会出现无法使用的情况。这是因为，当作为短任务容器的主容器结束计算退出后，作为长任务容器的sidecar容器还在继续运行，这不仅会导致Pod所占用的资源一直在空转，造成大量的计算、存储、网络等资源浪费，而且还会使得Kubernetes的短任务控制器认为任务未完成，对任务状态产生超时误判。

针对这一问题，现有的解决方案都只能针对特定的场景进行制定化处理，无法适应多变的容器编排场景。因此，亟需一种更灵活的容器退出的控制方案，以提高容器退出机制的普适性。

发明内容

本申请提供一种应用于Kubernetes的容器编排方法和系统，用以解决K8S系统中容器编排中容器退出机制普适性较低的问题。

第一方面，提供了一种应用于Kubernetes的容器编排方法，包括：API服务器获取短任务控制器发送的目标Pod的Pod创建请求；Webhook组件拦截所述Pod的创建请求，并扫描所述Pod创建请求中的目标容器的容器配置信息，以确定所述目标容器中是否包括预先定义的第一环境变量，所述第一环境变量用于指示所述目标容器为sidecar容器，所述目标容器为所述目标Pod中包括的任一容器；Webhook组件在所述目标容器包括所述第一环境变量的情况下，对所述目标容器进行Downward API形式化改造，所述Downward API形式化改造包括：将所述目标容器的启动命令中的内容复制到Pod annotations字段中，并将所述Pod annotations字段以Downward API的方式挂载到第二环境变量中；所述API服务器在所述Downward API形式化改造完成后，向分布式数据库写入所述目标Pod的Pod配置信息。

在一种可能的实现方式中，该方法还包括：sidecar控制器确定需要对所述目标容器执行容器退出机制；在所述目标Pod位于真实节点的情况下，所述sidecar控制器通过调用容器进行时接口CRI，将所述目标容器停止；或者，在所述目标Pod位于虚拟节点的情况下，所述sidecar控制器对所述目标容器执行Kubernetes的原地升级策略，其中，所述执行Kubernetes的原地升级策略包括：通过修改所述目标容器的镜像字段和所述Podannotations字段，以停止所述目标容器。

在一种可能的实现方式中，该方法还包括：所述sidecar控制器确定需要对所述目标容器执行容器退出机制，包括：事件监听器监听所述目标Pod中的容器的工作状态；所述事件监听器在所述目标Pod的容器重启策略为never的情况下，判断所述目标Pod中的主容器是否全部退出，其中，所述never是指在任何情况下均不重启容器；所述事件监听器在所述目标Pod中的主容器全部退出的情况下，触发所述sidecar控制器对所述目标容器执行容器退出机制。

在一种可能的实现方式中，该方法还包括：所述sidecar控制器确定需要对所述目标容器执行容器退出机制，包括：事件监听器监听所述目标Pod中的容器的工作状态；所述事件监听器在所述目标Pod的容器重启策略为onfailure的情况下，判断所述目标Pod中的主容器是否全部执行任务成功并退出，其中，所述onfailure是指在Pod中的容器非正常退出时重启异常容器；所述事件监听器在所述目标Pod中的主容器全部执行任务成功并退出情况下，触发所述sidecar控制器对所述目标容器执行容器退出机制。

第二方面，本申请提供了一种应用于Kubernetes的容器编排系统，包括：API服务器，用于接收短任务控制器发送的目标Pod的Pod创建请求；Webhook组件，用于拦截所述Pod的创建请求，并扫描所述Pod创建请求中的目标容器的容器配置信息，以确定所述目标容器中是否包括预先定义的第一环境变量，所述第一环境变量用于指示所述目标容器为sidecar容器，所述目标容器为所述目标Pod中包括的任一容器；Webhook组件还用于在所述目标容器包括所述第一环境变量的情况下，对所述目标容器进行Downward API形式化改造，所述Downward API形式化改造包括：将所述目标容器的启动命令中的内容复制到Podannotations字段中，并将所述Pod annotations字段以Downward API的方式挂载到第二环境变量中；所述API服务器还用于在所述Downward API形式化改造完成后，向写入所述目标Pod的Pod配置信息。

第三方面，提供了一种应用于Kubernetes的容器编排方法，包括：sidecar控制器确定需要对目标Pod中的目标容器执行容器退出机制，所述sidecar容器设置于kubernetes集群中的主节点中；在所述目标Pod位于真实节点的情况下，所述sidecar控制器向交互组件发送指示信息，以指示停止所述目标容器，所述交互组件设置于Kubernetes集群中的节点中，用于通过容器进行时接口CRI实现与容器之间的交互；所述交互组件调用CRI，将所述目标容器停止。

第四方面，一种应用于Kubernetes的容器编排系统，包括：sidecar控制器，设置于kubernetes集群中的主节点中；交互组件，设置于Kubernetes集群中的节点中，用于通过容器进行时接口CRI实现与容器之间的交互；所述sidecar控制器用于确定需要对目标Pod中的目标容器执行容器退出机制；以及在所述目标Pod位于真实节点的情况下，向所述交互组件指示停止所述目标容器；所述交互组件用于调用CRI，将所述目标容器停止。

第五方面，提供了一种电子设备，包括处理器，该处理器用于从存储器调用计算机程序，当所述计算机程序被执行时，该处理器用于执行上述第一方面或第一方面中任意可能的实现方式中由API服务器执行的方法，或者，用于执行上述第一方面或第一方面中任意可能的实现方式中由Webhook组件执行的方法，或者，用于执行上述第一方面或第一方面中任意可能的实现方式中由sidecar控制器执行的方法。

第六方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序包括用于执行上述第一方面或第一方面中任意可能的实现方式中由API服务器执行的方法的代码，或者，用于执行上述第一方面或第一方面中任意可能的实现方式中由Webhook组件执行的方法的代码，或者，用于执行上述第一方面或第一方面中任意可能的实现方式中由sidecar控制器执行的方法的代码。

第七方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序包括用于执行上述第一方面或第一方面中任意可能的实现方式中由API服务器执行的方法的代码，或者，用于执行上述第一方面或第一方面中任意可能的实现方式中由Webhook组件执行的方法的代码，或者，用于执行上述第一方面或第一方面中任意可能的实现方式中由sidecar控制器执行的方法的代码。

第八方面，提供了一种电子设备，包括处理器，该处理器用于从存储器调用计算机程序，当所述计算机程序被执行时，该处理器用于执行上述第三方面中由sidecar控制器执行的方法，或者，用于执行上述第三方面中由交互组件执行的方法。

第九方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序包括用于执行上述第三方面中由sidecar控制器执行的方法的代码，或者，用于执行上述第三方面中由交互组件执行的方法的代码。

第十方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序包括用于执行上述第三方面中由sidecar控制器执行的方法的代码，或者，用于执行上述第三方面中由交互组件执行的方法的代码。

在本申请实施例中，在建立Pod的过程中，Kubernetes Webhook机制可以根据第一环境变量识别sidecar容器，并对sidecar容器进行Downward API形式化改造，使得后续通过Downward API修改容器的启动命令，实现sidecar容器的退出机制，这种方案可以绕过兼容性限制，实现了容器退出方案的普适性，用户无需针对每一种场景进行适配，一套方案可以解决多种短任务容器编排场景。

附图说明

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

图1是本申请一实施例的K8S架构的应用场景的示意图；

图2是本申请又一实施例的K8S架构的应用场景的示意图；

图3是本申请一实施例的容器的编排方法的流程示意图；

图4是本申请又一实施例的容器的编排方法的流程示意图；

图5是本申请一实施例的应用于Kubernetes的容器编排方法的具体流程示意图；

图6是本申请一实施例的装置600的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

首先对本申请所涉及的名词进行解释。

Kubernetes:简称为K8S，是一种用于自动部署、扩展和管理容器化应用程序的开源系统。或者说，是一种容器编排系统，用于容器管理和容器之间的负载平衡。

容器：可以理解为一种特殊的进程，可以将资源、文件、状态和配置划分到一个独立的空间。这个独立空间可以被转移到任何宿主机器上，并且不影响里面的软件的运行。

舱(Pod)：K8S中的最小容器编排单元，一个Pod可以包含多个容器。通常情况下，一个服务器集群中可包括多个节点，每个节点中可包括多个Pod。

短任务容器编排器：也称为短任务控制器，是一种专门为临时任务/短时计算任务设计的容器编排方式，当Pod中的容器全部都退出后，才表示Pod中的计算任务完成。典型的需要短任务编排的任务有AI计算、搜索推荐广告的计算任务等。在K8S中，短任务容器编排器可以包括Kubernetes工作控制器(Kubernetes Job controller,Kubernetes Job)，或者在后文中也称为Job控制器、Job controller。或者，K8S也可以支持第三方提供的短任务控制器。

短任务容器：运行一段时间、或者计算完成后即刻主动退出的容器。在短任务容器编排场景中，所有的用户任务计算的主容器都是短任务容器。

长任务容器：是指一直运行的容器，一般不会主动退出。例如，长任务容器通常用于web应用、日志采集程序、运维程序等。长任务容器一般指sidecar容器。

主容器：用来完成主要目的容器，一般指处理任务计算的容器。

边车(sidecar)容器：辅助主容器完成计算的容器，例如，一个Pod中包含一个主容器和多个sidecar容器；本申请的适用场景包括主容器是短任务容器，sidecar是长任务容器的情形。

Command/args:容器的启动命令。

ETCD：是一种分布式键值数据库，用于配置共享和服务发现。它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。应用程序可以从ETCD中读写数据。键值存储是指将数据存储在分层组织的目录中，例如在标准文件系统中。

回调(Webhook)组件：K8S中为用户预留的回调组件，是一种自定义的可扩展机制。

容器重启策略(restart policy)：是K8S中的Pod中的容器重启的预设策略。该容器重启策略适用于Pod中的所有容器。重启策略仅针对同一节点上的kubelet的容器重启动作。当Pod中的容器退出时，kubelet会按指数回退方式计算重启的延迟，例如，10s、20s、40s。若容器执行了一段时间并且没有出现问题，kubelet对该容器的重启回退计时器执行重置操作。

具体地，在Pod的配置参数中包括restart policy字段，其可能的取值包括always、onfailure和never。作为示例，容器重启策略不同的取值对应的情形如下：

always：在任何情况下，只要Pod里的容器不在运行状态，总是自动重启这些不在运行状态的容器；

onfailure:在Pod里的容器非正常退出时才重启异常容器，其中，容器正常退出时退出码为0，非正常退出时退出码非0；

never:在任何情况下都不重启容器。

需要说明的是，在短任务容器编排场景下，只有never和onfailure两种取值，不存在always取值。

容器运行时接口(container runtime interface，CRI)：由K8S定义的一组与容器运行时进行交互的接口。

OpenKruise：是阿里巴巴开源的云原生应用自动化管理套件，基于Kubernetes架构进行了标准扩展。

图1是本申请一实施例的K8S架构的应用场景的示意图。如图1所示，K8S集群包括主节点(Master)和节点(Node)。

Master节点为集群的控制节点，用于管理和控制整个集群，负责K8S中的控制命令的具体执行过程。Master节点中主要包括以下组件。

应用编程接口服务器(application programming interface server,APIserver)：是集群的统一入口以及集群中各组件的协调中心，集群的管理员以及用户均通过API server接入K8S。所有对象资源的增删、修改、查找以及监听操作都可以由API server处理后再提交给ETCD存储。其它组件需要通过API server查询或修改数据，只有APIserver有权直接操作ETCD。

其中，上述管理员可以指用于运行和维护K8S架构的后台工作人员，或者是云产品提供人员，例如日志服务、监测服务的云产品提供方。上述用户可以指利用K8S架构中提供的资源运行容器，以进行程序开发的人员。

控制器管理器(controller manager)：是K8S中的资源对象的自动化控制中心，用于维护管理集群的状态，例如，故障检测，自动扩展、更新等。Controller manager中还包括工作控制器(Job controller)，Job controller用于实现临时任务/短时计算任务设计的容器编排。作为示例，Job controller也可以被其它第三方的短任务容器编排控制器替代。

调度器(Scheduler)：负责K8S中的资源调度，例如，按照预定的调度策略将Pod调度到相应的机器中。

ETCD:分布式键值数据库，用于保存整个集群的状态数据。例如，Pod、服务(service)等对象信息。

Node节点：用于运行Master节点分配的工作负载。Node节点上主要包括以下组件。

Kubelet：是Master节点在Node节点上的代理(agent)，用于管理本节点运行容器的生命周期，例如，容器的创建、启动、停止等任务，并且与Master节点协作，实现集群管理的基本功能。

Kube-proxy：负责实现Pod的网络代理，用于维护网络规则和负载均衡。

K8S中原生的短任务容器编排控制器(例如，Job controller)会以Pod为基本单位来判断任务是否完成，以及任务是否成功。但在一个Pod中，往往不仅包含任务相关的主容器，还会包含一些负责日志采集、日常运维任务的sidecar容器。短任务控制器需要等一个Pod中所有的容器退出后才能判定Pod计算任务完成，并且需要所有容器返回成功才会认为Pod计算成功。然而，这些不同的容器往往由不同的部门、甚至不同的平台、公司负责维护，例如，在一些短任务计算场景下，主容器由用户提供，sidecar容器由运营商提供。主容器是一个短任务容器，而sidecar容器是长任务容器，由于sidecar容器无法检测主容器何时退出，用户也不知晓主容器有哪些对应的sidecar容器，导致主容器完成任务计算后，sidecar容器依旧在运行。短任务控制器检测到Pod中有容器未完成，将一直等待，直到认定任务因超时而失败。这既造成了计算存储等资源浪费，又引起短任务控制器误判，导致该场景下无法进行短任务容器编排。

针对这个问题，业内并没有较为通用或者产品化的解决方案，通常是针对个别场景进行个案化定制。因此，需要一种适用范围更广的容器主动退出机制，当检测到主容器完成时，主动将长任务的sidecar容器停止，以达到节约资源和提高K8S架构的短任务容器编排的管理效率的目的。

为了解决上述问题，本申请实施例采取了一种应用于K8S的容器编排的方案，主要思想为通过对sidecar容器进行环境变量标注的方式实现容器退出机制。在该方案中，管理员或用户可以在Pod模板中通过预先定义的环境变量标识，来标识出需要处理的sidecar容器。在后续过程中，当短任务控制器开始执行作业编排，开始创建Pod时，Webhook组件和Jobcontroller会根据这些标识选中对应的sidecar容器进行改造和处理，并结合主容器的状态来选择合适的时机将这些sidecar容器进行退出。

为了实现上述方案，本申请实施例对K8S架构中的Webhook组件功能进行了修改，并在Master节点中增加了sidecar控制器，接下来将结合图2介绍本申请实施例的改造后的K8S架构。

图2是本申请又一实施例的K8S架构的应用场景的示意图。如图2所示，本申请实施例在Master节点中增加了sidecar控制器，或者也可以称为sidecar终端控制器(sidecarterminator controller)。sidecar控制器用于实现Pod中的sidecar容器的容器退出机制。sidecar控制器中还包括事件监听器。事件监听器用于监听Pod中的容器的状态，并在容器状态发生变化时，启动判断逻辑过程，以确定是否触发sidecar控制器执行容器退出机制。

此外，本申请实施例还对Webhook组件的功能进行了定义，Webhook组件可以用于拦截和修改API server向ETCD发送的控制信令，例如，Pod创建请求、容器的启动命令(Command/args)等。可选地，Webhook组件可以设置于Master节点中的任何模块中，例如，API server或者Controller manager中。在一些示例中，Webhook组件也可以设置于节点中。

可选地，如图2所示，本申请实施例适用于安装有交互组件的K8S架构。交互组件是指部署到集群中的节点上的组件，可以通过CRI与容器或者容器进行时实现交互。作为示例，交互组件可以是运行deamon进程的组件。作为示例而非限定，交互组件可以包括OpenKruise中的kruise-deamon组件。

后文中将描述利用sidecar-daemon组件执行容器停止策略，以实现sidecar容器的主动退出机制的方案。其中，容器停止策略可以指sidecar控制器通过协调daemon进程，从而通过CRI实现停止容器的一种策略，作为示例，容器停止策略包括但不限于OpenKruise的容器重启请求(container restart request，CRR)策略。

应理解，图1或图2中的应用场景的说明仅仅作为示例而非限定，在实践中，可以在上述场景的基础上作适当的变形和增减，仍然适用于本申请实施例的方案。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图3是本申请一实施例的容器的编排方法的流程示意图。该方法中的步骤可以由图2中的各组件执行。如图3所示，该方法包括以下内容。

S301、API服务器获取短任务控制器发送的目标Pod的Pod创建请求。

可选地，上述短任务控制器可以是K8S中的Job controller，也可以是其它任意第三方短任务容器编排控制器。上述API服务器可以包括图3中的API server。

可选地，Pod创建请求中包括Pod配置信息，Pod配置信息中可包括容器配置信息以及Pod本身层面的信息。其中，容器配置信息中可包括Pod中运行的容器的环境变量等信息。Pod本身层面的信息可包括Pod的名称、身份(identifier,ID)、安全策略、挂载的存储盘等信息。

S302、Webhook组件拦截Pod的创建请求，并扫描Pod创建请求中的目标容器的容器配置信息，以确定目标容器中是否包括预先定义的第一环境变量，第一环境变量用于指示目标容器为sidecar容器，目标容器为目标Pod中包括的任一容器。

可选地，管理员、用户或者系统在创建sidecar容器时，可以在sidecar容器中定义第一环境变量的状态，以便于后续处理过程中识别第一环境变量。例如，假设第一环境变量表示为SIDECAR_TERMINATION，则可以定义SIDECAR_TERMINATION＝“ture”时，表示该容器为sidecar容器。

S303、Webhook组件在目标容器包括第一环境变量的情况下，对目标容器进行Downward API形式化改造，Downward API形式化改造包括：将目标容器的启动命令中的内容复制到Pod annotations字段中，并将Pod annotations字段以Downward API的方式挂载到第二环境变量中。

其中，Pod annotations字段是Pod中的一个注释性的字段，Downward API是K8S中的一种API接口，Downward API可以通过环境变量将信息暴露给运行中的容器，这使得容器使用自己或者集群的信息，而不必通过Kubernetes客户端或API server来获得。

经过上述Downward API形式化改造之后，由于可以通过环境变量驱动DownwardAPI的方式执行容器的启动命令(command/args)，因此在后续过程中，可以通过修改环境变量的内容，达到修改容器的启动命令(command/args)的目的，以绕过K8S架构的限制。

作为示例，上述第二环境变量可表示为START_COMMAND，将Pod annotations字段以Downward API的方式挂载到第二环境变量中，可以表示为：Annotations[START_COMMAND]＝“xxxx”。

S304、API服务器在Downward API形式化改造完成后，向分布式数据库写入目标Pod的Pod配置信息。

可选地，上述分布式数据库包括ETCD，或者也可以是其它类型的分布式数据库。

可选地，在Downward API形式化改造完成后，Webhook组件向API server返回成功状态码，API server将修改后的Pod的创建请求中的Pod配置信息写入ETCD，以等待后续调度和容器创建执行等操作。

在本申请实施例中，在建立Pod的过程中，Kubernetes Webhook机制可以根据第一环境变量识别sidecar容器，并对sidecar容器进行Downward API形式化改造，使得后续通过Downward API修改容器的启动命令，实现sidecar容器的退出机制，这种方案可以绕过兼容性限制，实现了容器退出方案的普适性，用户无需针对每一种场景进行适配，一套方案可以解决多种短任务容器编排场景。

由于Kubernetes中Pod中的容器command/args无法直接修改，于是本申请利用Kubernetes Webhook对sidecar容器进行Downward API形式化改造。Pod创建之初，将sidecar容器的command/args写入环境变量，并通过Downward API挂载到Pod Annotations之上。由于Pod Annotations是可修改的资源，因此在需要执行容器退出的情况下，可以通过修改Pod Annotations来间接修改sidecar容器的command/args，从而绕过兼容性限制，使得任意容器均可复用同一个可快速主动退出镜像，达高提供通用性的目的。

Pod被调度且创建容器成功后，容器开始执行任务计算，在计算过程中，事件监听器监听Pod的状态，当Pod中的容器发生变化时，事件监听器判断是否需要对sidecar容器执行容器退出机制，并触发sidecar控制器对目标容器执行容器退出机制。

在一些示例中，sidecar控制器确定需要对目标容器执行容器退出机制，包括：事件监听器监听目标Pod中的容器的工作状态；事件监听器在目标Pod的容器重启策略为never的情况下，判断目标Pod中的主容器是否全部退出，其中，never是指在任何情况下均不重启容器；事件监听器在目标Pod中的主容器全部退出的情况下，触发sidecar控制器对目标容器执行容器退出机制。

在一些示例中，sidecar控制器确定需要对目标容器执行容器退出机制，包括：事件监听器监听目标Pod中的容器的工作状态；事件监听器在目标Pod的容器重启策略为onfailure的情况下，判断目标Pod中的主容器是否全部执行任务成功并退出，其中，onfailure是指在Pod中的容器非正常退出时重启异常容器；事件监听器在目标Pod中的主容器全部执行任务成功并退出情况下，触发sidecar控制器对目标容器执行容器退出机制。

在sidecar控制器确定需要执行容器退出机制之后，sidecar控制器可以判断Pod所在节点类型是真实节点还是虚拟节点，并根据节点类型不同，执行不同的容器退出策略。其中，上述真实节点可以指普通节点，指示Pod运行在物理主机中。上述虚拟节点可以指Virtual-kubelet，虚拟节点只是一个程序，其背后并无真实的物理主机支持，也无法通过调用CRI进行交互。

在一些示例中，sidecar控制器确定需要对目标容器执行容器退出机制；在目标Pod位于真实节点的情况下，sidecar控制器通过调用CRI，将目标容器停止。

作为示例，sidecar控制器通过调用CRI，将目标容器停止，包括：所述sidecar控制器向交互组件发送指示信息，以指示停止所述目标容器，所述交互组件调用CRI，将所述目标容器停止。

其中，交互组件是指部署到集群中的节点上的组件，可以通过CRI与容器或者容器进行时实现交互。作为示例，交互组件可以是运行deamon进程的组件。作为示例而非限定，交互组件可以包括OpenKruise中的kruise-deamon组件。

例如，sidecar控制器通过协调daemon进程，从而通过CRI实现停止容器。或者说，利用容器停止策略将目标容器停止。其中，容器停止策略可以指sidecar控制器通过协调daemon进程，从而通过CRI实现停止容器的一种策略，作为示例，容器停止策略包括但不限于OpenKruise的CRR策略。

在本申请实施例中，在节点中设置交互组件，该交互组件能够通过容器CRI实现与容器或者容器进行时之间的交互，因此，sidecar控制器可通过调用CRI实现容器退出机制，操作简单，通用性高，耗时较少，可以提高容器退出的效率。

在又一些示例中，在目标Pod位于虚拟节点的情况下，sidecar控制器对目标容器执行Kubernetes的原地升级策略，其中，执行Kubernetes的原地升级策略包括：通过修改目标容器的镜像字段和Pod annotations字段，以停止所述目标容器，其中，修改Podannotation字段的目的是修改目标容器的启动命令。

其中，对于运行在虚拟节点Virtual-Kubelet上的Pod，由于无法调用CRI接口，所以会执行原地升级策略。

原地升级策略的原理如下：Pod可以停掉容器，对Pod中的镜像字段进行修改，然后重新建立新的容器镜像。但是在原有方案中，Kubernetes只支持修改Pod的镜像字段，不允许修改Command/args，这要求所替换的镜像需要强兼容原镜像，由于不同用户运行的容器的类型不同，从而导致该方案没有通用性。

因此，本申请实施例在Pod建立之前利用Webhook组件使用Downward API对Command/args进行了改造，绕过了Kubernetes的限制，因此可以通过在原地升级策略中修改Pod Annotations的方式，来达到间接修改Command/args的目的。具体地，可以通过Downward API将Command/args修改为停止运行，从而Pod在停掉容器，并修改Command/args之后，新建立的容器镜像可以直接停止运行。这种方案利用了原地升级策略，但无需对每个镜像进行定制化来兼容不同镜像的启动命令(Command/args)，因此不涉及镜像之间的强兼容的问题，无需考虑运行容器类型，可以提高本申请方案的通用性。

在本申请实施例中，避免了对容器进行改造。主要利用以下技术进行解决：对于普通节点，可通过调用CRI将其进行停止；对于虚拟节点，利用Kubernetes Pod原地升级策略，将原sidecar容器镜像替换为可快速主动退出的镜像，达到将其停止的目的。

本申请实施例提出了一种通用的容器主动退出方案，该方案能够使得主容器完成计算后，将其他还在运行的容器进行主动退出，从而达到节约资源、引导K8S中的短任务控制器正确判断任务完成状态的目的。

本申请实施例不仅适用于Kubernetes原生的Job controller，还适用于任意第三方扩展的短任务容器编排场景，可以监听用户的主容器的计算完成情况，当其计算完成退出后，将sidecar容器停止，引导Job controller等短任务控制器完成正确的任务状态判断，节省资源。本方案能够应对多种Kubernetes短任务容器编排场景，并且无需对主容器和sidecar容器进行改造，具有较高的通用性。

图4是本申请一实施例的容器的编排方法的流程示意图。该方法中的步骤可以由图2中的各组件执行。如图4所示，该方法包括以下内容。

S401、sidecar控制器确定需要对目标Pod中的目标容器执行容器退出机制，所述sidecar容器设置于kubernetes集群中的主节点中。

S402、在所述目标Pod位于真实节点的情况下，所述sidecar控制器向交互组件发送指示信息，以指示停止所述目标容器，所述交互组件设置于Kubernetes集群中的节点中，用于通过容器进行时接口CRI实现与容器之间的交互。

其中，交互组件是指部署到集群中的节点上的组件，可以通过CRI与容器或者容器进行时实现交互。作为示例，交互组件可以是运行deamon进程的组件。作为示例而非限定，交互组件可以包括OpenKruise中的kruise-deamon组件。

例如，sidecar控制器通过协调daemon进程，从而通过CRI实现停止容器。或者说，利用容器停止策略将目标容器停止。其中，容器停止策略可以指sidecar控制器通过协调daemon进程，从而通过CRI实现停止容器的一种策略，作为示例，容器停止策略包括但不限于OpenKruise的CRR策略。

S403、所述交互组件调用CRI，将所述目标容器停止。

在本申请实施例中，在节点中设置交互组件，该交互组件能够通过容器CRI实现与容器或者容器进行时之间的交互，因此，sidecar控制器可通过调用CRI实现容器退出机制，操作简单，通用性高，耗时较少，可以提高容器退出的效率。

可选地，在S401中，sidecar控制器确定需要对目标Pod中的目标容器执行容器退出机制的具体方式可参考图3中的相关描述，为了简洁，此处不再赘述。

图5是本申请一实施例的应用于Kubernetes的容器编排方法的具体流程示意图。可选地，图5中的Job controller可以被其它第三方短任务容器编排控制器替代，本申请实施例对此不作限定。如图5所示，该方法包括以下内容。

S501、在Job controller创建Pod过程中，向API server发送Pod创建请求，相应地，API server接收Pod创建请求。

可选地，Pod创建请求中包括Pod配置信息，Pod配置信息中可包括容器配置信息以及Pod本身层面的信息。其中，容器配置信息中可包括Pod中运行的容器的环境变量等信息。Pod本身层面的信息可包括Pod的名称、身份(identifier,ID)、安全策略、挂载的存储盘等信息。

S502、在API server向ETCD写入Pod创建请求中的Pod配置信息之前，Webhook组件拦截Pod创建请求。

S503、Webhook扫描Pod创建请求中的容器配置信息，查看是否有容器包括预先定义的第一环境变量，第一环境变量用于指示该容器为sidecar容器。若有容器包含第一环境变量，说明该容器为sidecar容器，则执行S504，即执行Downward API形式化改造。

可选地，若该Pod中没有容器包含第一环境变量，则可以不作处理，API server可以将Pod配置信息写入ETCD。

作为示例，Job controller创建Pod时，该Pod创建请求会被Webhook组件所拦截。在API Server将Pod配置信息写入ETCD，完成对象存储之前，Webhook组件会扫描一遍Pod中的容器，看是否包含预先规定的第一环境变量，如果携带，则说明该容器是需要处理的sidecar容器，则对其进行Downward API形式化改造。

S504、对sidecar容器进行Downward API形式化改造。

Downward API形式化改造包括：将目标容器的启动命令中的内容复制到Podannotations字段中，并将Pod annotations字段以Downward API的方式挂载到第二环境变量中。

经过Downward API形式化改造之后，由于可以通过环境变量驱动Downward API的方式执行容器的启动命令(command/args)，因此在后续过程中，可以通过修改环境变量的内容，达到修改容器的启动命令(command/args)的目的，以绕过K8S架构的限制。

S505、在Downward API形式化改造完成后，Webhook组件向API server返回成功状态码，API server将修改后的Pod的创建请求中的Pod配置信息写入ETCD，以等待后续调度和容器创建执行等操作。

S506、Pod被调度且创建容器成功后，容器开始执行任务计算，在计算过程中，事件监听器监听Pod的状态，当Pod中的容器发生变化时，事件监听器判断是否需要对sidecar容器执行容器退出机制。

其中，事件监听器判断逻辑过程可继续参见图5，上述判断逻辑过程包括以下内容。

A1、判断是否有容器携带预先定义的第一环境变量；若携带有第一环境变量，则判断Pod的容器重启策略；若未携带第一环境变量，则结束判断逻辑过程。

A2、若Pod的容器重启策略为never，则执行A4。

A3、若Pod的容器重启策略为onfailure，则执行A5。

A4、判断Pod中的主容器是否全部退出，若全部退出，则确定需要执行容器退出机制，并触发sidecar控制器执行容器退出机制；若未全部退出，则结束判断逻辑过程。

A5、判断Pod中的主容器是否全部执行任务成功并退出。若是，则确定需要执行容器退出机制，并触发sidecar控制器执行容器退出机制；若否，则结束判断逻辑过程。

其中，容器正常退出时退出码为0，非正常退出时退出码非0。

S507、若事件监听器判断需要执行sidecar容器退出，则触发sidecar控制器执行容器退出机制。

继续参见图5，sidecar控制器执行容器退出机制包括以下内容。

B1、判断Pod所在节点类型是真实节点还是虚拟节点；若是真实节点，则执行B2；若是虚拟节点，则执行B3。

B2、对运行在真实节点上的Pod，执行容器停止策略。

例如，sidecar控制器可通过协议告知交互组件需要停止的目标容器，并令其调用CRI将目标容器退出。

B3、对运行在虚拟节点上的Pod，通过执行K8S的原地升级策略，停止sidecar容器。

其中，对于运行在虚拟节点Virtual-Kubelet上的Pod，由于无法调用CRI，所以会执行原地升级策略。

具体地，可以通过修改目标容器的镜像字段建立新的容器镜像，并通过DownwardAPI将Command/args修改为停止运行，从而Pod在停掉容器，并修改Command/args之后，新建立的容器镜像可以直接停止运行。

可选地，当控制器将sidecar容器及时停止后，Job controller可以监听到Pod状态的改变，并发现Pod已经处于结束状态，此时就可以根据Pod的成功或失败状态来正确判断任务计算的完成情况。

本申请实施例中，由于Kubernetes中Pod中的容器command/args无法直接修改，于是本申请利用Kubernetes Webhook对sidecar容器进行Downward API形式化改造。Pod创建之初，将sidecar容器的command/args写入环境变量，并通过Downward API挂载到PodAnnotations之上。由于Pod Annotations是可修改的资源，因此当原地升级时，可以通过修改Pod Annotations来间接修改sidecar容器的command/args，从而绕过兼容性限制，使得任意容器均可复用同一个可快速主动退出镜像，达高提供通用性的目的。

在本申请实施例中，利用CRI或Kubernetes原地升级机制以无需改造容器镜像的方式，正确引导Kubernetes进行短任务容器编排，同时节约计算、存储、网络等资源。

图6是本申请一实施例的装置600的结构示意图。装置600用于执行本申请实施例中由K8S中的各组件执行的方法。

该装置600包括处理器610，处理器610用于执行存储器620存储的计算机程序或指令，或读取存储器620存储的数据，以执行上文各方法实施例中的方法。可选地，处理器610为一个或多个。

可选地，如图6所示，该装置600还包括存储器620，存储器620用于存储计算机程序或指令和/或数据。该存储器620可以与处理器610集成在一起，或者也可以分离设置。可选地，存储器620为一个或多个。

可选地，如图6所示，该装置600还包括通信接口630，通信接口630用于信号的接收和/或发送。例如，处理器610用于控制通信接口630进行信号的接收和/或发送。

可选地，该装置600用于实现上文各个方法实施例中由由K8S中的各组件执行的操作。

例如，处理器610用于执行存储器620存储的计算机程序或指令，以实现上文中由API服务器执行的相关操作，或者实现上文中由Webhook组件执行的相关操作，或者实现上文中由sidecar控制器执行的相关操作，或者实现上文中由交互组件执行的相关操作，或者实现上文中由事件监听器执行的相关操作。

需要指出的是，图6中的装置600可以是前述实施例中的各组件，也可以是各组件的组成部件(如芯片)或功能模块，在此不做限定。

在本申请实施例中，处理器是一种具有信号的处理能力的电路，在一种实现中，处理器可以是具有指令读取与运行能力的电路，例如CPU、微处理器、GPU(可以理解为一种微处理器)、或DSP等；在另一种实现中，处理器可以通过硬件电路的逻辑关系实现一定功能，该硬件电路的逻辑关系是固定的或可以重构的，例如处理器为ASIC或PLD实现的硬件电路，例如FPGA。在可重构的硬件电路中，处理器加载配置文档，实现硬件电路配置的过程，可以理解为处理器加载指令，以实现以上部分或全部单元的功能的过程。此外，还可以是针对人工智能设计的硬件电路，其可以理解为一种ASIC，例如NPU、TPU、DPU等。

可见，以上装置中的各单元可以是被配置成实施以上方法的一个或多个处理器(或处理电路)，例如：CPU、GPU、NPU、TPU、DPU、微处理器、DSP、ASIC、FPGA，或这些处理器形式中至少两种的组合。

此外，以上装置中的各单元可以全部或部分可以集成在一起，或者可以独立实现。在一种实现中，这些单元集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。该SOC中可以包括至少一个处理器，用于实现以上任一种方法或实现该装置各单元的功能，该至少一个处理器的种类可以不同，例如包括CPU和FPGA，CPU和人工智能处理器，CPU和GPU等。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序/指令被处理器执行时，致使处理器实现上文中由API服务器执行的方法中的步骤，或者实现上文中由Webhook组件执行的方法中的步骤，或者实现上文中由sidecar控制器执行的方法中的步骤，或者实现上文中由交互组件执行的方法中的步骤，或者实现上文中由事件监听器执行的方法中的步骤。

相应地，本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序/指令被处理器执行时，致使处理器实现上文中由API服务器执行的方法中的步骤，或者实现上文中由Webhook组件执行的方法中的步骤，或者实现上文中由sidecar控制器执行的方法中的步骤，或者实现上文中由交互组件执行的方法中的步骤，或者实现上文中由事件监听器执行的方法中的步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种应用于Kubernetes的容器编排方法，其特征在于，包括：

API服务器获取短任务控制器发送的目标Pod的Pod创建请求；

Webhook组件拦截所述Pod的创建请求，并扫描所述Pod创建请求中的目标容器的容器配置信息，以确定所述目标容器中是否包括预先定义的第一环境变量，所述第一环境变量用于指示所述目标容器为sidecar容器，所述目标容器为所述目标Pod中包括的任一容器；

Webhook组件在所述目标容器包括所述第一环境变量的情况下，对所述目标容器进行Downward API形式化改造，所述Downward API形式化改造包括：将所述目标容器的启动命令中的内容复制到Pod annotations字段中，并将所述Pod annotations字段以DownwardAPI的方式挂载到第二环境变量中；

所述API服务器在所述Downward API形式化改造完成后，向分布式数据库写入所述目标Pod的Pod配置信息。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

sidecar控制器确定需要对所述目标容器执行容器退出机制；

在所述目标Pod位于真实节点的情况下，所述sidecar控制器通过调用容器进行时接口CRI，将所述目标容器停止；或者，

在所述目标Pod位于虚拟节点的情况下，所述sidecar控制器对所述目标容器执行Kubernetes的原地升级策略，其中，所述执行Kubernetes的原地升级策略包括：通过修改所述目标容器的镜像字段和所述Pod annotations字段，以停止所述目标容器。

3.如权利要求2所述的方法，其特征在于，所述sidecar控制器确定需要对所述目标容器执行容器退出机制，包括：

事件监听器监听所述目标Pod中的容器的工作状态；

所述事件监听器在所述目标Pod的容器重启策略为never的情况下，判断所述目标Pod中的主容器是否全部退出，其中，所述never是指在任何情况下均不重启容器；

所述事件监听器在所述目标Pod中的主容器全部退出的情况下，触发所述sidecar控制器对所述目标容器执行容器退出机制。

4.如权利要求2所述的方法，其特征在于，所述sidecar控制器确定需要对所述目标容器执行容器退出机制，包括：

事件监听器监听所述目标Pod中的容器的工作状态；

所述事件监听器在所述目标Pod的容器重启策略为onfailure的情况下，判断所述目标Pod中的主容器是否全部执行任务成功并退出，其中，所述onfailure是指在Pod中的容器非正常退出时重启异常容器；

所述事件监听器在所述目标Pod中的主容器全部执行任务成功并退出情况下，触发所述sidecar控制器对所述目标容器执行容器退出机制。

5.一种应用于Kubernetes的容器编排方法，其特征在于，包括：

sidecar控制器确定需要对目标Pod中的目标容器执行容器退出机制，所述sidecar容器设置于kubernetes集群中的主节点中；

在所述目标Pod位于真实节点的情况下，所述sidecar控制器向交互组件发送指示信息，以指示停止所述目标容器，所述交互组件设置于Kubernetes集群中的节点中，用于通过容器进行时接口CRI实现与容器之间的交互；

所述交互组件调用CRI，将所述目标容器停止。

6.一种应用于Kubernetes的容器编排系统，其特征在于，包括：

API服务器，用于接收短任务控制器发送的目标Pod的Pod创建请求；

Webhook组件，用于拦截所述Pod的创建请求，并扫描所述Pod创建请求中的目标容器的容器配置信息，以确定所述目标容器中是否包括预先定义的第一环境变量，所述第一环境变量用于指示所述目标容器为sidecar容器，所述目标容器为所述目标Pod中包括的任一容器；

Webhook组件还用于在所述目标容器包括所述第一环境变量的情况下，对所述目标容器进行Downward API形式化改造，所述Downward API形式化改造包括：将所述目标容器的启动命令中的内容复制到Pod annotations字段中，并将所述Pod annotations字段以Downward API的方式挂载到第二环境变量中；

所述API服务器还用于在所述Downward API形式化改造完成后，向分布式数据库写入所述目标Pod的Pod配置信息。

7.如权利要求6所述的系统，其特征在于，所述系统还包括sidecar控制器，用于：确定需要对所述目标容器执行容器退出机制；在所述目标Pod位于真实节点的情况下，通过调用容器运行时接口CRI，将所述目标容器停止；或者，在所述目标Pod位于虚拟节点的情况下，对所述目标容器执行Kubernetes的原地升级策略，其中，所述执行Kubernetes的原地升级策略包括：通过修改所述目标容器的镜像字段和所述Pod annotations字段，以停止所述目标容器。

8.如权利要求7所述的系统，其特征在于，所述sidecar控制器中还包括事件监听器，在确定需要对所述目标容器执行容器退出机制方面，所述事件监听器具体用于：监听所述目标Pod中的容器的工作状态；在所述目标Pod的容器重启策略为never的情况下，判断所述目标Pod中的主容器是否全部退出，其中，所述never是指在任何情况下均不重启容器；在所述目标Pod中的主容器全部退出的情况下，触发所述sidecar控制器对所述目标容器执行容器退出机制。

9.如权利要求7所述的系统，其特征在于，所述sidecar控制器中还包括事件监听器，在确定需要对所述目标容器执行容器退出机制方面，所述事件监听器具体用于：监听所述目标Pod中的容器的工作状态；在所述目标Pod的容器重启策略为onfailure的情况下，判断所述目标Pod中的主容器是否全部执行任务成功并退出，其中，所述onfailure是指在Pod中的容器非正常退出时重启异常容器；在所述目标Pod中的主容器全部执行任务成功并退出情况下，触发所述sidecar控制器对所述目标容器执行容器退出机制。

10.一种应用于Kubernetes的容器编排系统，其特征在于，包括：

sidecar控制器，设置于kubernetes集群中的主节点中；

交互组件，设置于Kubernetes集群中的节点中，用于通过容器进行时接口CRI实现与容器之间的交互；

所述sidecar控制器用于确定需要对目标Pod中的目标容器执行容器退出机制；以及在所述目标Pod位于真实节点的情况下，向所述交互组件指示停止所述目标容器；

所述交互组件用于调用CRI，将所述目标容器停止。

11.一种电子设备，其特征在于，所述电子设备包括处理器，所述处理器用于从存储器调用计算机程序，当所述计算机程序被执行时，所述处理器用于执行如权利要求1至4中任一项由所述API服务器执行的方法，或者，用于执行如权利要求1至4中任一项中由所述Webhook组件执行的方法，或者，用于执行如权利要求2至4中任一项中由所述sidecar控制器执行的方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至4中任一项中由所述API服务器执行的方法，或者，用于实现如权利要求1至4中任一项中由所述Webhook组件执行的方法，或者，用于实现如权利要求2至4中任一项中由所述sidecar控制器执行的方法。

13.一种电子设备，其特征在于，所述电子设备包括处理器，所述处理器用于从存储器调用计算机程序，当所述计算机程序被执行时，所述处理器用于执行如权利要求5中由所述sidecar控制器执行的方法，或者，用于执行如权利要求5中由所述交互组件执行的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求5中由所述sidecar控制器执行的方法，或者，用于实现如权利要求5中由所述交互组件执行的方法。

Images