CN113422700A - 无感升级方法及无感升级装置 - Google Patents

Abstract

本发明揭示了无感升级方法，用于将容器组中的边车服务容器从旧版本升级至新版本，该无感升级方法包括：建立一临时容器组，运行新版本的过渡边车服务容器；将业务流量从容器组中旧版本的边车服务容器逐步转移至过渡边车服务容器；将容器组中的边车服务容器从旧版本升级至新版本；将业务流量从过渡边车服务容器逐步转移至容器组中新版本的边车服务容器；删除临时容器组，临时容器组中的过渡边车服务容器一并删除。本发明还揭示了执行上述无感升级方法的无感升级装置。本发明利用添加临时容器组来实现程序升级，临时容器组在使用完毕后可以整体删除，本发明还通过流量控制器进行容器组和临时容器组之间的流量切换，达到无感升级的体验。

Description

无感升级方法及无感升级装置

技术领域

本发明涉及软件技术领域，更具体地说，涉及分布式架构中的软件更新技术。

背景技术

在企业应用开发中为了使得开发的应用能够获得更好的弹性伸缩能力，通常会使用分布式的微服务架构，即：使用多个提供相同服务的实例来提供一个具体的服务。服务实例间可以相互作为备份，当请求量增大时也可以通过增加服务实例的方式快速提高总体请求吞吐量。

对于分布式服务的管理(包括服务的注册与发现、路由及负载均衡、熔断限流和监控等)被称为服务治理。在传统的服务治理架构中，通常业务应用自身需要引入特定的类库以完成服务治理的需求，这样，业务应用本身需要增加服务治理功能的相关代码。在现有的服务治理架构中，服务治理功能被装入业务应用，服务治理功能的升级需要业务应用分别升级服务治理类库并重新发布代码才能完成。同时，对于使用不同语言开发的业务应用来说，还需要分别开发不同语言版本的服务治理类库。因此，服务治理功能装入业务应用的架构使得服务治理功能的升级变得非常麻烦。

服务网格(Service Mesh)是一种新型的服务治理架构。服务网格采用边车(Sidecar)的模式，在业务应用的进程外单独运行一个边车进程，在边车进程内完成所有服务治理的功能。服务网格架构利用边车模式解决了传统服务治理架构中服务治理功能和业务功能耦合的问题，同时解决了多语言的问题。目前的服务网格架构通常都在分布式容器引擎平台Kubernetes环境中实现。Kubernetes是一个成熟的服务调度管理框架。Kubernetes中的基本调度单元称为容器组(Pod)，一个容器组中可以包含多个容器(Container)。在容器中可以运行程序镜像。在服务网格架构中，业务引用以及与之对应的边车服务运行在同一个容器组(Pod)中，业务应用为一个容器，运行业务应用程序的镜像，边车服务为另一个容器，运行边车程序镜像。在需要对边车服务进行版本升级时，需要将边车服务容器中原来旧版本的边车程序镜像替换为新版本的边车程序镜像。容器中的程序镜像被替换后，需要重启程序才能正常运行，替换和重启的过程中，原来的边车服务暂停，会导致在途的请求丢失，出现服务中断的情况。服务中断对于分布式应用环境下的需求而言是不可接受的。

分布式应用环境下的需求对于各种服务升级有无感升级的要求。无感升级，又被称为无缝升级或热升级，是指在持续请求的过程中，不影响请求顺利响应的升级过程。即：对于正常的业务调用方和服务方来说，诸如边车在内的各种应用程序的升级过程是透明无感的，所有的业务请求在升级过程中都能够正确地被处理，而不会出现丢失或者停止的情况。

现有技术中也有基于Kubernetes平台的边车的无缝升级方案。比如CN111552496A揭示了一种基于添加临时容器实现无缝升级边车的系统与方法，系统包含共享存储器内存储有挂载在容器组上的共享存储卷；镜像存储控制器将新边车控制程序与新边车代理程序打包成传输至热升级控制器的边车容器镜像；热升级控制器根据热升级信号将边车容器镜像传输至临时容器控制器；临时容器控制器通过边车容器镜像向容器组中注入临时容器；临时容器中的新边车控制程序通过共享存储卷与旧边车控制程序连接，新边车控制程序对新边车代理程序赋予新ID；新边车代理程序获取旧边车代理程序中的数据信息进行热更新，完成对流量的接管，新边车代理程序启动后通过Unix域套接字发送指令到旧边车代理程序，旧边车代理程序接收指令后退出。

又比如CN107515776A揭示了一种业务无感升级方法、待升级节点和可读存储介质。本发明中的待升级节点获取处于运行状态的第一当前版本容器，所述第一当前版本容器创建于一个容器组Pod中，创建与新版本镜像对应的新版本容器，将所述新版本容器添加至所述容器组Pod中，从所述容器组Pod中获取所述第一当前版本容器的配置信息，将所述配置信息写入所述容器组Pod的新版本容器，运行所述容器组Pod的新版本容器，并将所述容器组Pod的第一当前版本容器删除。该种版本升级方式，由于新版本容器与第一当前版本容器都包装在同一Pod中，在替换运行过程中，将不会间断业务的执行，而且升级速度较快，解决了当前不能较好地实现业务无感升级的技术问题。

无论是CN111552496A还是CN107515776A，都采用了在容器组Pod中增加临时容器的方式来实现边车服务的无感升级。但使用临时容器的方式存在一个问题：在Kubernetes的官方文档上对于临时容器的描述中写道：“与常规容器类似，将临时容器添加到容器组后，将不能更改或删除临时容器。”因此，在使用临时容器完成边车的无感升级后，临时容器将始终存在，无法被更改或者删除，这会造成严重的资源浪费。截止目前为止，Kubernetes在最新版本中依旧没有提供删除临时容器的方法，所以，基于临时容器的边车升级方法会不断占用资源，随着版本升级次数的增加，临时容器所占用的资源会越来越多。并且，临时容器与原来的边车服务容器处于同一个容器组Pod中，两个相同的业务镜像在同一个容器组Pod中运行会产生端口冲突的问题，需要通过额外的技术手段进行处理。

总结而言，虽然现有技术中提出了边车服务的无感升级方法，但这些方法的缺陷非常明显。

发明内容

本发明提出一种基于临时容器组的边车服务的无感升级技术。

根据本发明的一实施例，提出一种无感升级方法，用于将容器组中的边车服务容器从旧版本升级至新版本，该无感升级方法包括：

建立一临时容器组，该临时容器组中仅运行过渡边车服务容器，该过渡边车服务容器是新版本；

将部分业务流量分配至临时容器组中的过渡边车服务容器，过渡边车服务容器和容器组中旧版本的边车服务容器同步运行，逐步减少容器组中的边车服务容器的业务流量，同时逐步增加过渡边车服务容器的业务流量，直至全部的业务流量转移至过渡边车服务容器；

将容器组中的边车服务容器从旧版本升级至新版本；

将部分业务流量分配至容器组中新版本的边车服务容器，过渡边车服务容器和容器组中新版本的边车服务容器同步运行，逐步减少过渡边车服务容器的业务流量，同时逐步增加容器组中的边车服务容器的业务流量，直至全部的业务流量转移至容器组中的边车服务容器；

删除临时容器组，临时容器组中的过渡边车服务容器一并删除。

在一个实施例中，容器组包括：

流量控制器，流量控制器对接收到的业务请求进行流量分配；

边车服务容器，边车服务容器运行边车服务的镜像；

业务应用容器，业务应用容器运行业务应用的镜像；

其中业务请求由流量分配器分配给边车服务容器，经边车服务容器接入业务应用容器。

在一个实施例中，临时容器组中的过渡边车服务容器完成部署后启动，启动后先进入非就绪状态，流量控制器不将业务流量分配给非就绪状态的过渡边车服务容器，过渡边车服务容器与业务应用容器连接后进入就绪状态，流量控制器向就绪状态的过渡边车服务容器分配业务流量。容器组中的边车服务容器升级到新版本后启动，启动后先进入非就绪状态，流量控制器不将业务流量分配给非就绪状态的边车服务容器，边车服务容器与业务应用容器连接后进入就绪状态，流量控制器向就绪状态的边车服务容器分配业务流量。

在一个实施例中，在临时容器组中建立容器，并向该容器推送新版本的边车服务的镜像，以进行过渡边车服务容器的部署。将容器组中边车服务容器中的镜像替换为新版本的边车服务的镜像，以进行容器组中边车服务容器的升级。

在一个实施例中，该无感升级方法运行于Kubernetes容器平台上，容器平台包括数个容器组，当其中一个容器组中的边车服务容器需要升级时，选择该容器组，使用该无感升级方法将边车服务容器从旧版本升级到新版本。

在一个实施例中，流量控制器以灰度切换流量的方式将业务流量从容器组中旧版本的边车服务容器转移至过渡边车服务容器，以及从过渡边车服务容器转移至容器组中新版本的边车服务容器。灰度切换流量的方式包括：分阶段成倍扩大流量的方式、分阶段等幅度扩大流量的方式或者分阶段台阶式扩大流量的方式。

在一个实施例中，该无感升级方法应用于服务网格模式的微服务架构，服务网格模式中服务治理功能从业务应用中剥离而被设置在边车服务中。

根据本发明的一实施例，提出一种无感升级装置，执行前述的无感升级方法，将容器组中的边车服务容器从旧版本升级至新版本，该无感升级装置向容器平台和容器组发送指令。

在一个实施例中，无感升级装置检测到其中一个容器组中的边车服务容器的升级需求，执行无感升级方法，在容器平台上建立临时容器组，基于建立临时容器组完成边车服务容器的升级，升级完成后删除临时容器组。

本发明的无感升级方法和无感升级装置利用添加临时容器组来实现程序升级，临时容器组在使用完毕后可以整体删除，不会持续占用系统资源。本发明还在业务应用和边车服务的程序组中增加了流量控制器，通过流量控制器进行容器组和临时容器组之间的流量切换，达到无感升级的体验。

附图说明

图1揭示了根据本发明的一实施例的无感升级方法的流程图。

图2a、图2b、图2c和图2d揭示了根据本发明的一实施例的无感升级方法的执行过程。

图3揭示了根据本发明的一实施例的无感升级装置的模块示意图。

具体实施方式

参考图1所示，图1揭示了根据本发明的一实施例的无感升级方法的流程图。该无感升级方法用于将容器组中的边车服务容器从旧版本升级至新版本，该无感升级方法包括如下的步骤：

S1、建立一临时容器组，该临时容器组中仅运行过渡边车服务容器，该过渡边车服务容器是新版本。

S2、将部分业务流量分配至临时容器组中的过渡边车服务容器，过渡边车服务容器和容器组中旧版本的边车服务容器同步运行，逐步减少容器组中的边车服务容器的业务流量，同时逐步增加过渡边车服务容器的业务流量，直至全部的业务流量转移至过渡边车服务容器。

S3、将容器组中的边车服务容器从旧版本升级至新版本。

S4、将部分业务流量分配至容器组中新版本的边车服务容器，过渡边车服务容器和容器组中新版本的边车服务容器同步运行，逐步减少过渡边车服务容器的业务流量，同时逐步增加容器组中的边车服务容器的业务流量，直至全部的业务流量转移至容器组中的边车服务容器。

S5、删除临时容器组，临时容器组中的过渡边车服务容器一并删除。

图2a、图2b、图2c和图2d揭示了根据本发明的一实施例的无感升级方法的执行过程。下面结合图2a、图2b、图2c和图2d更加详细地描述本发明的无感升级的过程。在图示的实施例中，每一容器组Pod包括三个容器：流量控制器101、边车服务容器102和业务应用容器103。流量控制器101对接收到的业务请求进行流量分配。流量控制器101自身也是一个容器，运行流量控制程序的镜像。流量控制器101可以有多种实现方式。比如可以通过Iptables、开源的代理类软件envoy等来实现，或者自行编写脚本和程序也可以实现流量控制器。对于本领域的技术人员而言，实现具有流量分配功能的流量控制程序是常用的实现手段。流量控制器101通常不需要进行版本升级。边车服务容器102运行边车服务的镜像。业务应用容器103运行业务应用的镜像。本发明的无感升级方法应用于服务网格(ServiceMesh)模式的微服务架构，在服务网格模式中服务治理功能从业务应用中剥离而被设置在边车服务中。因此，业务请求由流量分配器101分配给边车服务容器102，经边车服务容器102接入业务应用容器103。图2a、图2b、图2c和图2d所示的过程是在分布式容器引擎平台Kubernetes环境下运行。

图2a揭示了无感升级的过程的第一阶段。此时容器组Pod中的边车服务容器102运行的是旧版本的边车服务程序的镜像。在初始阶段，容器组Pod的业务请求流向为：流量控制器101将所有的业务请求的流量分配给边车服务容器102，再经由边车服务容器102提供给应用服务容器103。在服务治理功能升级，需要对边车服务进行版本升级时，首先建立一临时容器组104，Kubernetes引擎平台会根据指令建立一个临时容器组。该临时容器组104中仅运行过渡边车服务容器105。过渡边车服务容器105中是新版本的边车服务程序的镜像，该过程在图2a中用步骤①表示。即：在临时容器组中建立容器，并向该容器推送新版本的边车服务的镜像，以进行过渡边车服务容器的部署。在临时容器组104和过渡边车服务容器105部署完毕之后，首先是需要启动过渡边车服务容器中的过渡边车服务。临时容器组104中的过渡边车服务容器105完成部署后启动，启动后先进入非就绪状态。流量控制器101不会将业务流量分配给非就绪状态的过渡边车服务容器。过渡边车服务容器105与业务应用容器103连接后进入就绪状态，流量控制器101向就绪状态的过渡边车服务容器105分配业务流量。根据Kubernetes平台的特性，过渡边车服务容器105刚启动时会处于非就绪状态。就绪与非就绪是Kubernetes定义的概念，Kubernetes中的每个容器都有是否就绪这个状态，当容器处于非就绪状态时，不应该有流量进入容器。过渡边车服务容器105启动后会根据启动时传入的参数自动连接对应的业务应用容器103。过渡边车服务容器105连接业务应用容器103的过程如图2a中的步骤②所示。当过渡边车服务容器105连接业务应用容器103成功后，容器就会进入就绪状态。容器的就绪状态可以被监听到(监听容器是否就绪是Kubernetes平台提供的能力)。在过渡边车服务容器105就绪后，流量控制器101开始将流量逐步从边车服务容器102切换到过渡边车服务容器105上，该过程如图2a中的步骤③所示。在这个阶段，过渡边车服务容器105和容器组Pod中旧版本的边车服务容器102同步运行，流量控制器101会逐步减少容器组中的边车服务容器的业务流量，同时逐步增加过渡边车服务容器的业务流量，直至全部的业务流量转移至过渡边车服务容器。在一个实施例中，流量控制器101以灰度切换流量的方式将业务流量从容器组中旧版本的边车服务容器转移至过渡边车服务容器。灰度切换流量的方式包括：分阶段成倍扩大流量的方式、分阶段等幅度扩大流量的方式或者分阶段台阶式扩大流量的方式。分阶段成倍扩大流量的方式是诸如：从流量的6％开始，一个阶段之后提升到12％，再过一个阶段提升到25％，再到50％，最后到100％。分阶段等幅度扩大流量的方式是诸如：从流量的10％开始，一个阶段之后提升到20％，再过一个阶段提升到30％，每一个阶段增加10％，最后到100％。分阶段台阶式扩大流量的方式是诸如：首先分配流量的50％，一个阶段之后提升到100％。流量切换方式并没有硬性的限制，只要无感升级的过程和流量控制器被正确地实现，都不会影响无感升级的效果。比较常用的流量切换的方式是分阶段成倍扩大流量的方式或者分阶段等幅度扩大流量的方式。一开始只有一小部分流量切换到新版本的边车服务(过渡边车服务)，大部分流量仍然通过旧版本的边车服务进入业务应用。这样做的好处是：1)如果在这个过程中出现问题，那么只会影响一小部分请求；2)通过一小部分流量进入新版本的边车服务，可以给新版本的边车服务一个预热的过程。之后，如果没有出现异常情况，将逐步加大进入新版本的边车服务的流量比例，直到所有流量都通过新版本的边车服务(过渡边车服务)进入业务应用。

图2b揭示了无感升级的过程的第二阶段。如图2b所示，在业务流量全部切换到临时容器组104中的过渡边车服务容器105后，容器组Pod中的边车服务容器102已经没有流量通过。这时流量控制器101断开与边车服务容器102(此时为旧版本)的连接，该过程如图2b中的步骤④所示。然后Kubernetes引擎平台会根据指令对边车服务容器102进行升级，用新版本的边车服务程序的镜像替换原来旧版本的边车服务的镜像。在进行程序镜像的替换时，Kubernetes引擎平台会通知边车服务容器102停止服务，并且断开边车服务容器102与业务应用容器103的连接，该过程如图2b中的步骤⑤所示。对容器内程序镜像的替换、以及容器之间的连接与断开都是Kubernetes引擎平台自带的功能，本发明直接使用这些功能。

图2c揭示了无感升级的过程的第三阶段。如图2c所示，Kubernetes引擎平台替换边车服务容器102中的镜像，将边车服务程序替换为新版本，然后重新启动新版本的边车服务容器102，该过程如图2c中的步骤⑥所示。即：将容器组中边车服务容器中的镜像替换为新版本的边车服务的镜像，以进行容器组中边车服务容器的升级。容器组Pod中的边车服务容器102升级到新版本后启动，启动后同样是先进入非就绪状态，流量控制器101不将业务流量分配给非就绪状态的边车服务容器102。边车服务容器102与业务应用容器103连接后进入就绪状态，流量控制器101向就绪状态的边车服务容器102分配业务流量。流量控制器101将部分业务流量分配至容器组中新版本的边车服务容器102。过渡边车服务容器105和容器组中新版本的边车服务容器102同步运行(两者均为新版本)。逐步减少过渡边车服务容器的业务流量，同时逐步增加容器组中的边车服务容器的业务流量，直至全部的业务流量转移至容器组中的边车服务容器。新版本的边车服务容器102启动后连接业务应用容器103并从非就绪状态进入就绪状态的过程如图2b中的步骤⑦所示。在边车服务容器102就绪后，流量控制器101开始将流量逐步从过渡边车服务容器105切换到新版本的边车服务容器102上，该过程如图2c中的步骤⑧所示。步骤⑦和步骤⑧的过程与前述的步骤②和步骤③的过程类似，只是切换的方向不同，步骤⑦和步骤⑧的过程可以参考前述的步骤②和步骤③，此处不再重复描述。

图2d揭示了无感升级的过程的第四阶段。如图2d所示，在业务流量全部切换回容器组Pod中的新版本的边车服务容器102后，临时容器组104中的过渡边车服务容器105已经没有流量通过。这时流量控制器101断开与过渡边车服务容器105的连接，该过程如图2d中的步骤⑨所示。Kubernetes引擎平台根据指令通知过渡边车服务容器105停止服务，并且断开过渡边车服务容器105与业务应用容器103的连接，该过程如图2d中的步骤⑩所示。在与流量控制器101和业务应用容器103的连接均断开之后，Kubernetes引擎平台将临时容器组104连同过渡边车服务容器105一起删除。在图2d中，临时容器组104连同过渡边车服务容器105用虚线展示，表示在步骤⑨和步骤⑩执行完毕后，Kubernetes引擎平台删除临时容器组104和过渡边车服务容器105。Kubernetes引擎平台提供了删除容器组的功能，所以可以以容器组为单位进行整体删除，以释放所占用的资源。本发明利用Kubernetes引擎平台能够整体删除容器组的特性，解决了资源占用的问题。通过在容器组Pod内增加流量控制器，解决了在容器组之间进行流量切换以实现无感升级的功能。

图3揭示了根据本发明的一实施例的无感升级装置的模块示意图。本发明还提出一种无感升级装置，执行前述的无感升级方法，将容器组中的边车服务容器从旧版本升级至新版本，该无感升级装置向容器平台和容器组发送指令。参考图3所示，该无感升级装置201也是一个引用程序，连接到Kubernetes容器引擎平台202，Kubernetes容器引擎平台202包括数个容器组Pod，每一个容器组Pod包括流量控制器101、边车服务容器102和应用服务容器103。不同的容器组运行不同的应用服务，虽然引用服务的程序有所不同，但是容器组Pod的基本结构都是类似的，服务治理功能从业务应用中剥离而被设置在边车服务中。当其中一个容器组Pod中的边车服务容器需要升级时，选择该容器组。无感升级装置201向Kubernetes容器引擎平台202以及容器组中的各个组件发送指令，执行前述的无感升级方法，在Kubernetes容器引擎平台中新建临时容器组104和过渡边车服务容器105，利用临时容器组实现边车服务容器从旧版本升级到新版本期间的无感升级过程，确保业务请求不中断、不丢失。

本发明的无感升级方法和无感升级装置利用添加临时容器组来实现程序升级，临时容器组在使用完毕后可以整体删除，不会持续占用系统资源。本发明还在业务应用和边车服务的程序组中增加了流量控制器，通过流量控制器进行容器组和临时容器组之间的流量切换，达到无感升级的体验。

还需要注意的是，以上所列举的实施例仅为本发明的具体实施例。显然本发明不局限于以上实施例，随之做出的类似变化或变形是本领域技术人员能从本发明公开的内容直接得出或者很容易便联想到的，均应属于本发明的保护范围。上述实施例是提供给熟悉本领域内的人员来实现或使用本发明的，熟悉本领域的人员可在不脱离本发明的发明思想的情况下，对上述实施例做出种种修改或变化，因而本发明的保护范围并不被上述实施例所限，而应该是符合权利要求书提到的创新性特征的最大范围。

Claims (9)

1.一种无感升级方法，用于将容器组中的边车服务容器从旧版本升级至新版本，其特征在于，所述无感升级方法包括：

建立一临时容器组，该临时容器组中仅运行过渡边车服务容器，该过渡边车服务容器是新版本；

将部分业务流量分配至临时容器组中的过渡边车服务容器，过渡边车服务容器和容器组中旧版本的边车服务容器同步运行，逐步减少容器组中的边车服务容器的业务流量，同时逐步增加过渡边车服务容器的业务流量，直至全部的业务流量转移至过渡边车服务容器；

将容器组中的边车服务容器从旧版本升级至新版本；

将部分业务流量分配至容器组中新版本的边车服务容器，过渡边车服务容器和容器组中新版本的边车服务容器同步运行，逐步减少过渡边车服务容器的业务流量，同时逐步增加容器组中的边车服务容器的业务流量，直至全部的业务流量转移至容器组中的边车服务容器；

删除临时容器组，临时容器组中的过渡边车服务容器一并删除。

2.如权利要求1所述的无感升级方法，其特征在于，所述容器组包括：

流量控制器，流量控制器对接收到的业务请求进行流量分配；

边车服务容器，边车服务容器运行边车服务的镜像；

业务应用容器，业务应用容器运行业务应用的镜像；

其中业务请求由流量分配器分配给边车服务容器，经边车服务容器接入业务应用容器。

3.如权利要求2所述的无感升级方法，其特征在于，

临时容器组中的过渡边车服务容器完成部署后启动，启动后先进入非就绪状态，流量控制器不将业务流量分配给非就绪状态的过渡边车服务容器，过渡边车服务容器与业务应用容器连接后进入就绪状态，流量控制器向就绪状态的过渡边车服务容器分配业务流量；

容器组中的边车服务容器升级到新版本后启动，启动后先进入非就绪状态，流量控制器不将业务流量分配给非就绪状态的边车服务容器，边车服务容器与业务应用容器连接后进入就绪状态，流量控制器向就绪状态的边车服务容器分配业务流量。

4.如权利要求3所述的无感升级方法，其特征在于，

在临时容器组中建立容器，并向该容器推送新版本的边车服务的镜像，以进行过渡边车服务容器的部署；

将容器组中边车服务容器中的镜像替换为新版本的边车服务的镜像，以进行容器组中边车服务容器的升级。

5.如权利要求4所述的无感升级方法，其特征在于，该无感升级方法运行于Kubernetes容器平台上，容器平台包括数个容器组，当其中一个容器组中的边车服务容器需要升级时，选择该容器组，使用该无感升级方法将边车服务容器从旧版本升级到新版本。

6.如权利要求3所述的无感升级方法，其特征在于，流量控制器以灰度切换流量的方式将业务流量从容器组中旧版本的边车服务容器转移至过渡边车服务容器，以及从过渡边车服务容器转移至容器组中新版本的边车服务容器；

所述灰度切换流量的方式包括：分阶段成倍扩大流量的方式、分阶段等幅度扩大流量的方式或者分阶段台阶式扩大流量的方式。

7.如权利要求2所述的无感升级方法，其特征在于，该无感升级方法应用于服务网格模式的微服务架构，服务网格模式中服务治理功能从业务应用中剥离而被设置在边车服务中。

8.一种无感升级装置，执行如权利要求1-7中任一项所述的无感升级方法，将容器组中的边车服务容器从旧版本升级至新版本，该无感升级装置向容器平台和容器组发送指令。

9.如权利要求8所述的无感升级装置，其特征在于，所述无感升级装置检测到其中一个容器组中的边车服务容器的升级需求，执行所述无感升级方法，在容器平台上建立临时容器组，基于建立临时容器组完成边车服务容器的升级，升级完成后删除临时容器组。

Images