CN112506617A - Kubernetes集群中边车容器的镜像更新方法及装置 - Google Patents

Abstract

本发明公开了一种Kubernetes集群中边车容器的镜像更新方法及装置，方法包括：从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；获取目标节点上部署的业务Pod的标识、以及目标Pod的标识，目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；根据目标Pod的标识获取目标Pod的IP地址，基于目标Pod的IP地址，指示对应的目标Pod对业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。采用本发明的方法进行边车容器的镜像更新时，可以实现在更新边车容器的时候业务容器不被重启并且业务Pod不被重新调度，使业务容器在边车容器的镜像更新过程中无感知。

Description

Kubernetes集群中边车容器的镜像更新方法及装置

技术领域

本发明涉及集群信息领域，尤其涉及一种Kubernetes集群中边车容器的镜像更新方法及装置。

背景技术

Kubernetes是一种可以自动部署、扩展和管理“容器化应用程序”的开源系统，包括多个工作节点。每个工作节点中均部署有多个容器组Pod，每个Pod中封装有一个或多个用于承载软件程序的业务容器。除业务容器外，Pod中还可以封装边车容器，边车容器可以实现业务容器的辅助功能，如处理业务容器的日志，业务监控等功能。

边车容器一般是通用的，即多个业务使用同一个边车容器。当需要对边车容器进行镜像更新时，则需要修改服务部署的部署配置，这将导致所有Pod重新调度并重启业务容器和边车容器。一方面，业务容器的重启会影响业务稳定性；另一方面，所有Pod的重新调度需要消耗Kubernetes集群资源，导致更新流程消耗较多的时间。

发明内容

本说明书实施例提供一种Kubernetes集群中边车容器的镜像更新方法及装置，可以实现在更新边车容器的时候业务容器不被重启并且业务Pod不被重新调度，使业务容器在边车容器的镜像更新过程中无感知。

为解决上述技术问题，本说明书实施例是这样实现的：

第一方面，提出了一种Kubernetes集群中边车容器镜像更新方法，包括：

从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取所述目标节点上部署的业务Pod的标识、以及目标Pod的标识，所述目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

根据所述目标Pod的标识获取目标Pod的IP地址，基于所述目标Pod的IP地址，指示对应的目标Pod对所述业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

第二方面，提出了一种Kubernetes集群中边车容器的镜像更新装置，包括：

目标节点确定单元，用于从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取单元，用于获取所述目标节点上部署的业务Pod的标识、以及目标Pod的标识，所述目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

边车容器镜像更新单元，用于根据所述目标Pod的标识获取目标Pod的IP地址，基于所述目标Pod的IP地址，指示对应的目标Pod对所述业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

第三方面，提出了一种电子设备，应用于应用服务端，该电子设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取所述目标节点上部署的业务Pod的标识、以及目标Pod的标识，所述目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

根据所述目标Pod的标识获取目标Pod的IP地址，基于所述目标Pod的IP地址，指示对应的目标Pod对所述业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

第四方面，提出了一种计算机可读存储介质，应用于应用服务端，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：

从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取所述目标节点上部署的业务Pod的标识、以及目标Pod的标识，所述目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

根据所述目标Pod的标识获取目标Pod的IP地址，基于所述目标Pod的IP地址，指示对应的目标Pod对所述业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

由以上实施例提供的技术方案可见，用户可以从Kubernetes集群的节点中，确定存在更新需求的边车容器所在的目标节点，进而获取目标节点上部署的业务Pod的标识、目标Pod的标识及目标Pod的IP地址，其中，目标Pod可以对业务Pod中的容器进行操作。随后，根据目标Pod的IP地址，指示目标Pod对业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

可见，利用本实施例在对边车容器进行更新时，首先获取可以对业务Pod中的容器进行操作的目标Pod的IP地址，通过IP地址和目标Pod建立HTTP连接，随后指示目标Pod对存在更新需求的边车容器进行镜像更新。该方案在实现对边车容器的镜像更新的过程中，不需对业务Pod进行重新调度，也不需重启业务容器，流程便捷高效且具有稳定性。

另外，还可以对边车容器镜像拉取策略进行自定义设置，根据用户的不同需求，实现对边车容器的镜像更新。

附图说明

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

图1是本说明书第一实施方式提供的边车容器的镜像更新方法的流程示意图。

图2是本说明书提供的Kubernetes集群中边车容器的镜像更新方法示意图。

图3是本说明书第二实施方式提供的边车容器的镜像更新方法的流程示意图。

图4是本说明书第三实施方式提供的边车容器的镜像更新装置的模块结构示意图。

图5是本说明书第四实施方式提供的电子设备的结构示意图。

具体实施方式

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

Kubernetes可以简称为K8s，是一个能用于管理云平台中多个主机上的容器化的应用。Kubernetes提供了应用部署，规划，更新，维护的一种机制。Kubernetes中应用部署是通过部署容器方式实现的，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。

在Kubernetes集群环境下，所部署的业务往往是以Pod的形式运行在节点Node上面的。通常，一个业务Pod中至少有一个业务容器，除业务容器外，还可以配置边车容器，如前文所述，边车容器又名Sidecar容器，用于实现业务容器的一些辅助功能，如，处理业务容器的日志、进行业务监控等功能。

在Kubernetes中，当Node故障、业务Pod故障、业务Pod滚动更新、业务Pod手动删除、Pod中容器重启等事件发生后，业务Pod都会根据配置信息，进行重新创建并启动新Pod，以保证与配置相同。相应的，如边车容器需要更新，同样需要修改部署配置，这将导致部署下面所有Pod重新调度并重启业务容器和边车容器。一方面，业务容器的重启会影响业务稳定性；另一方面，所有Pod的重新调度需要消耗Kubernetes集群资源，导致更新流程消耗较多的时间。

为了实现在更新边车容器的时候业务容器不被重启并且不被重新调度，使业务容器在边车容器的镜像更新过程中无感知，本说明书的第一实施方式涉及一种Kubernetes集群中边车容器镜像更新方法，如图1所示，包括以下步骤：

S101：从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

S102：获取目标节点上部署的业务Pod的标识、以及目标Pod的标识，目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

S103：根据目标Pod的标识获取目标Pod的IP地址，基于目标Pod的IP地址，指示对应的目标Pod对业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

如前文所述，Pod是kubernetes集群的基础单元，是由用户创建或部署的最小组件，也是kubernetes集群上运行容器化应用的资源对象。不同的Pod可以在不同的节点Node上运行，节点可以是物理机、也可以是虚拟机。在实际的应用环境中，可以通过创建或者更新服务部署，如Deployment(用于无状态服务)或者StatefulSet(用于有状态服务)来管理、控制Pod，比如可以在不同的Node上对Pod进行创建、删除等，并且服务部署通常可以有自己的配置信息，部署配置信息中可以包含描述所控制的Pod的多种基本信息，比如总个数、版本信息、运行情况、对应的唯一标识等。

在步骤S101中，通常会在Node上创建多个业务Pod运行，在每个业务Pod中至少设置有一个业务容器，同时，为了满足业务顺利实现，Pod中还会封装辅助业务容器的边车容器。为了满足不断提升的业务需求，如新功能、或漏洞修复等，会产生对边车容器的更新需求。在更新时，可以运行业务Pod的Node去拉取用于更新的边车容器的镜像。那么，想要实现边车容器的镜像更新，首先需要确定待更新的边车容器所在的目标节点。

作为一个例子，可以预先为不同的Node配置不同的业务标签，比如针对某个业务服务，创建对应业务标签。那么当需要对某个业务的辅助功能进行更新时，则可以根据该业务标签确定需要更新的边车容器所在的目标节点Node。

另外，还可以为不同的节点设置唯一标识，比如可以预先为每个Node配置唯一的编号、或节点名称等。具体比如，可以为不同的Node分别预先配置Node1、Node2等唯一标识。那么当需要对某个或某几个特定的Node中的业务Pod中的边车容器进行更新时，则可以根据唯一标识确定需要更新的边车容器所在的目标节点Node。

作为一个例子，服务部署Deployment可以对Pod进行控制，而Pod是由Deployment控制在不同的Node中运行，所以也可以通过Deployment，来查询边车容器所在的目标节点。如，针对某个业务，可以根据Deployment的部署配置信息、比如身份标识等，来确定存在更新需求的边车容器所在的目标节点。

在步骤S102中，可以根据目标节点信息查询出该目标节点上面所有Pod的信息，通过比对，过滤出目标Pod。目标Pod的创建过程如下：

通过Kubernetes的守护进程集功能创建守护进程服务，通过在每个Node上创建目标Pod来实现该服务。目标Pod在启动的时候挂载Node上unix:///var/run/dockershim.sock文件，用于使Pod中的cri-web应用程序可以操作所在Node上的容器。其中，cri-web程序是使用Golang开发的应用程序，既实现了CRI(容器运行时接口)又可以提供Web服务。

由于目标Pod和业务Pod创建在节点上，因此，可以根据目标节点信息查询出该节点上所有的Pod的信息，确定目标Pod的标识。

在步骤S103中，可以通过目标Pod的标识查出目标Pod的IP地址，然后根据目标Pod的IP地址，可以建立和目标Pod的HTTP连接，接收HTTP请求。请求中可以携带着业务Pod的标识及它所对应的命名空间名称，目标Pod中的cri-web收到请求后，会根据业务Pod名称及命名空间名称在Node上面找到其所对应的边车容器，然后cri-web会停止该边车容器，并删除该边车容器。

由于Kubernetes Pod的机制，在cri-web停止并删除边车容器后，整个业务Pod的状态将变成不可达。业务Pod根据自身机制重新启动边车容器，根据预设的边车容器镜像拉取策略，拉取更新后的边车容器镜像。其中，预设的边车容器镜像拉取策略配置为“Always”，即：当业务Pod中的边车容器被删除时，则在镜像仓库中拉取更新后的边车容器镜像。通过以上方案，可以实现拉取的总是最新的边车容器镜像，达到对边车容器的镜像完成更新的目的。在实际应用中，可以存在一个或多个边车容器镜像仓库，用于存储不同的边车容器镜像文件。

具体地，在实际的业务场景中，可以预先创建一个DeamonSet服务，以使系统中的Node拥有该服务。具有该服务的Node，在创建Pod并启动时，可以挂载Node上的容器服务，比如该容器服务可以是/var/run/docker.sock。而该容器服务可以用于根据给定的边车容器镜像地址拉取对应的边车容器镜像文件。

利用本实施例在对边车容器进行更新时，首先获取可以对业务Pod中的容器进行操作的目标Pod的IP地址，通过IP地址和目标Pod建立HTTP连接，随后指示目标Pod对存在更新需求的边车容器进行镜像更新。该方案在实现对边车容器的镜像更新的过程中，不需对业务Pod进行重新调度，也不需对业务容器进行重启，流程便捷高效且具有稳定性。

为便于理解，以下结合具体实施阐述本说明书的一种Kubernetes集群中边车容器的镜像更新方法。如图2所示，在实际的业务场景中，可以在Kubernetes系统外部创建一个Restful API、以及一个逻辑处理模块，而在Kubernetes系统中，可以开放对外的Kubernetes API，对外可以与逻辑处理模块进行交互，对内可以与不同Node以及Node中的功能模块进行交互。内部可以有多个节点Node，比如，图2中可以示意有2个Node，分别为Node1和Node2。每个Node中创建有业务Pod和目标Pod，其中，业务Pod中封装有业务容器和边车容器，目标Pod在启动的时候挂载Node上unix:///var/run/dockershim.sock文件，用于cri-web应用程序操作本Node上的容器服务。

Restful API作为应用接口，可以提供给用户，以便接收边车容器的镜像更新请求。逻辑处理模块，可以用于处理Restful API发送来的请求，通过与KubernetesAPI与系统内部进行交互。服务部署Deployment可以管理对应的Pod。

具体的，逻辑处理模块接收用户通过Restful API发送的边车容器的镜像更新请求，调用Kubernetes API接口，查询Deployment的部署配置信息。根据部署配置信息查询出业务Pod所在的节点信息，根据节点信息获取该节点上所有Pod的信息，如业务Pod的标识、目标Pod的标识，通过目标Pod的标识，获取目标Pod的IP地址。

逻辑处理模块根据目标Pod的IP地址和cri-web建立Web通信，逻辑处理模块向目标Pod发送边车容器的镜像更新请求，请求中携带着Deployment对应业务Pod的名称及它所对应的命名空间名称，cri-web收到请求后，根据业务Pod名称及命名空间名称在Node上找到其对应的边车容器，然后cri-web停止并删除该边车容器。

由于Kubernetes Pod的机制，在cri-web停止并删除边车容器的时候，整个业务Pod的状态将变成不可达。流量将不会调度到此Pod上面。同时业务Pod会根据自身机制重新启动边车容器，去边车容器镜像仓库拉取更新后的边车容器镜像，最终实现边车容器的镜像更新。整个更新过程，与边车容器封装在同一个业务Pod中的业务容器不会有任何变化，整个业务Pod也不会被重新调度。

本说明书的第二实施方式涉及一种Kubernetes集群中边车容器的镜像更新方法，如图3所示，包括以下步骤：

S301：接收用户发起的更新边车容器的请求，请求中包括镜像更新策略；

S302：根据镜像更新策略，确定存在更新需求的边车容器的数量，并确定相应数量的待更新的边车容器。

在步骤S301中，逻辑处理模块接收用户通过Restful API发送的边车容器的镜像更新请求，该请求包括镜像更新策略，镜像更新策略可以为根据最大不可达数更新边车容器，也可以为根据百分比数更新边车容器。

在实际应用中，根据业务的复杂程度，可能会创建多个不同的业务Pod，因此，一个Kubernetes集群中设置有许多边车容器。如果一次性更新全部边车容器可能会由于某个更新后的边车容器出现错误，而导致业务不可用，所以本说明书可以对存在更新需求的边车容器进行分批更新。镜像更新策略即对应实际每批次更新的边车容器的情况。

在步骤S302中，为了实现针对Kubernetes系统中的边车容器进行分批更新，则可以预先确定出本次存在更新需求的边车容器的数量。比如根据用户设置的边车容器镜像更新请求信息，可以确定出有10个需要更新的边车容器，为了能够对这10个边车容器进行分批更新，可以预先确定出每次更新边车容器的数量。在实际应用中，每次更新边车容器的数量可以通过不同参数设置来确定。

作为一个例子，可以通过最大不可达数设置每次更新边车容器的数量，最大不可达数指在边车容器进行更新时，最多可以容许出现不可用的业务Pod的个数，最大不可达数通常可以由Deployment服务部署的配置信息查询到。如，最大不可达数可以是2，这便可以作为分批更新边车容器的依据，即逻辑处理模块将两个两个的执行边车容器的更新。

作为一个例子，还可以根据百分比数更新边车容器，则接收用户通过Restful API发送的根据百分比数更新边车容器镜像请求，该请求中还包括用户设置的百分比数。逻辑处理模块调用Kubernetes API接口，查询Deployment服务部署中配置的业务Pod数量，将业务Pod数量和用户发送的百分比数相乘，其乘积作为存在更新需求的边车容器的数量，基于该数量进行边车容器的滚动更新。如，业务Pod数量为10，用户发送的百分比数为20％，乘积为2，即逻辑处理模块将两个两个的执行边车容器的更新。

在实际应用中，可以据业务需求灵活设置边车容器的镜像更新策略，实现对边车容器分批次镜像更新，保证更新过程的业务稳定。

本说明书的第三实施方式涉及一种Kubernetes集群中边车容器的镜像更新装置400，如图4所示，包含：目标节点确定单元401、获取单元402以及边车容器镜像更新单元403，各模块功能详细说明如下：

目标节点确定单元401，用于从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取单元402，用于用于获取目标节点上部署的业务Pod的标识、以及目标Pod的标识，目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

边车容器镜像更新单元403，用于根据目标Pod的标识获取目标Pod的IP地址，基于目标Pod的IP地址，指示对应的目标Pod对业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

进一步地，本发明实施方式提供的边车容器的镜像更新装置400中，还包括请求接受单元以及数量确定单元，其中：

请求接受单元，用于接收用户发起的更新边车容器的请求，请求中包括镜像更新策略；

数量确定单元，用于根据镜像更新策略，确定存在更新需求的边车容器的数量，并确定相应数量的待更新的边车容器。

进一步地，镜像更新策略可以为根据最大不可达数更新边车容器，也可以为根据百分比数更新边车容器，则数量确定单元还包括服务部署配置获取单元。

当镜像更新策略为根据最大不可达数更新边车容器时，则服务部署配置获取单元用于获取创建业务Pod的服务部署中配置的最大不可达数；当镜像更新策略为根据百分比数更新边车容器时，则服务部署配置获取单元可以用于获取创建业务Pod的服务部署中配置的业务Pod数量。

进一步地，本发明实施方式提供的边车容器的镜像更新装置400中，边车容器镜像更新单元403包括：通信连接建立子单元、删除子单元、镜像拉取子单元和更新子单元，其中：

通信连接建立子单元，用于根据目标Pod的IP地址与对应的目标Pod建立通信连接；

删除子单元，用于通过建立的通信连接指示对应的目标Pod删除业务Pod中的边车容器；

镜像拉取子单元，用于根据预设的边车容器镜像拉取策略，拉取更新后的边车容器镜像；

更新子单元，用于根据更新后的边车容器镜像，更新边车容器。

其中，预设的边车容器镜像拉取策略设置为：当业务Pod中的边车容器被删除时，则在镜像仓库中拉取更新后的边车容器镜像。

利用本实施例的装置在对边车容器进行更新时，首先获取可以对业务Pod中的容器进行操作的目标Pod的IP地址，通过IP地址和目标Pod建立HTTP连接，随后指示目标Pod对存在更新需求的边车容器进行镜像更新。该方案在实现对边车容器的镜像更新的过程中，不需对业务Pod进行重新调度，也不需重启业务容器，流程便捷高效且具有稳定性。另外，还可以通过设置边车容器镜像拉取策略，根据用户的不同需求，实现对边车容器的镜像更新。

值得一提的是，第三实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，以上实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明以上实施方式中不存在其它的单元。

本说明书的第四实施方式涉及一种电子设备，如图5所示。在硬件层面，电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponentInterconnect，外设部件互连标准)总线或EISA(Extended IndustryStandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成Kubernetes集群中边车容器的镜像更新装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取目标节点上部署的业务Pod的标识、以及目标Pod的标识，目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

根据目标Pod的标识获取目标Pod的IP地址，基于目标Pod的IP地址，指示对应的目标Pod对业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

上述如本说明书第五实施方式提供的一种Kubernetes集群中边车容器的镜像更新装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(CentralProcessing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application SpecificIntegratedCircuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本说明书实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

结合本说明书实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

本说明书实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行一种Kubernetes集群中边车容器的镜像更新装置执行的方法，并具体用于执行：

从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取目标节点上部署的业务Pod的标识、以及目标Pod的标识，目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

根据目标Pod的标识获取目标Pod的IP地址，基于目标Pod的IP地址，指示对应的目标Pod对业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

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

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

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

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

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

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (10)

1.一种Kubernetes集群中边车容器的镜像更新方法，其特征在于，包括：

从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取所述目标节点上部署的业务Pod的标识、以及目标Pod的标识，所述目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

根据所述目标Pod的标识获取目标Pod的IP地址，基于所述目标Pod的IP地址，指示对应的目标Pod对所述业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

2.根据权利要求1所述的方法，其特征在于，所述从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点之前，还包括：

接收用户发起的更新边车容器的请求，所述请求中包括镜像更新策略；

根据所述镜像更新策略，确定存在更新需求的边车容器的数量，并确定相应数量的待更新的边车容器。

3.根据权利要求2所述的方法，其特征在于，所述镜像更新策略包括根据最大不可达数更新边车容器，所述根据所述镜像更新策略，确定存在更新需求的边车容器的数量，包括：

获取创建所述业务Pod的服务部署中配置的最大不可达数；

将所述最大不可达数，作为所述存在更新需求的边车容器的数量。

4.根据权利要求2所述的方法，其特征在于，所述更新边车容器的请求中还包括百分比数，所述镜像更新策略包括根据百分比数更新边车容器，所述根据所述镜像更新策略，确定存在更新需求的边车容器的数量，包括：

获取创建所述业务Pod的服务部署中配置的业务Pod数量；

将所述业务Pod数量以及所述百分比数的乘积，作为所述存在更新需求的边车容器的数量。

5.根据权利要求1所述的方法，其特征在于，所述基于所述目标Pod的IP地址，指示对应的目标Pod对所述业务Pod中的边车容器进行镜像更新，包括：

根据所述目标Pod的IP地址与对应的目标Pod建立通信连接；

通过建立的通信连接指示对应的目标Pod删除所述业务Pod中的边车容器；

根据预设的边车容器镜像拉取策略，拉取更新后的边车容器镜像；

根据所述更新后的边车容器镜像，更新所述边车容器。

6.根据权利要求5所述的方法，其特征在于，所述预设的边车容器镜像拉取策略设置为：

当业务Pod中的边车容器被删除时，则在镜像仓库中拉取更新后的边车容器镜像。

7.一种Kubernetes集群中边车容器的镜像更新装置，其特征在于，包括：

目标节点确定单元，用于从Kubernetes集群的节点中，确定待更新的边车容器所在的目标节点；

获取单元，用于获取所述目标节点上部署的业务Pod的标识、以及目标Pod的标识，所述目标Pod是指预先配置的具有业务Pod中容器操作功能的Pod；

边车容器镜像更新单元，用于根据所述目标Pod的标识获取目标Pod的IP地址，基于所述目标Pod的IP地址，指示对应的目标Pod对所述业务Pod的标识对应的业务Pod中的边车容器进行镜像更新。

8.根据权利要求7所述的装置，其特征在于，所述边车容器镜像更新单元，包括：

通信连接建立子单元，用于根据所述目标Pod的IP地址与对应的目标Pod建立通信连接；

删除子单元，用于通过建立的通信连接指示对应的目标Pod删除所述业务Pod中的边车容器；

镜像拉取子单元，用于根据预设的边车容器镜像拉取策略，拉取更新后的边车容器镜像；

更新子单元，用于根据所述更新后的边车容器镜像，更新所述边车容器。

9.一种电子设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至6中任一项所述的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述的方法的步骤。

Images