[发明专利]一种辅助容器实现热升级的方法及装置

说明书

本申请公开了一种辅助容器实现热升级的方法及装置，通过为一个辅助容器注入了两个容器即辅助容器和其对应的空容器的方式，避免了原地更新一个容器而导致的流量损失的问题。另外，在完成空容器到新的辅助容器的升级和流量接管后，通过将原有的辅助容器重置为空容器的方式，避免了原有的辅助容器因为进程退出触发容器或者探活重启的问题，也避免了由于原有的辅助容器退出失败而导致的相关进程资源无法清理的问题。本申请实施例提供的辅助容器热升级的方式对容器化的应用有了完整的支持，实现了辅助容器独立热升级，而无需业务感知，从而提升了产品竞争力和用户满意度。

技术领域

本申请涉及但不限于云原生技术，尤指一种辅助容器实现热升级的方法及装置。

背景技术

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生(CloudNative)是一个组合词，其中，Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，充分利用和发挥云平台的弹性和分布式优势。云原生已经日渐成为在云上交付和运行应用的标准方式，云原生应用中和业务不直接相关的辅助功能，如日志采集、流量代理、安全扫描等，都被逐渐剥离出来，改为使用云平台提供的相应基础设施。

云原生应用普遍利用了下沉的基础设施能力，例如Service Mesh等，这些基础设施功能为了提供更好的性能和隔离能力，主要采用辅助容器的方式，和业务应用部署在同一个Pod中。Service Mesh是随着微服务架构在互联网企业的广泛实践中而产生的新一代微服务之一。Service Mesh是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，Service Mesh通常是由一系列轻量级的网络代理组成的，这些网络代理与应用程序部署在一起，只是应用程序不需要知道Service Mesh的存在。容器组(Pod)是Kubernetes(Kubernetes是一个可移植、可扩展的开源平台，用于自动部署、扩展和管理容器化应用程序)为部署、管理、编排容器化应用提出的概念，也是Kubernetes中的最小部署单元，代表了Kubernetes中一个独立的应用程序运行实例，直译过来的意思是“豆荚”，既简单又实用。Pod可以看作是由一组紧耦合的容器组成的容器组，Pod中的所有容器会被一致调度、同节点部署，并且在一个共享环境中运行。

由于辅助容器和业务容器部署在一起，辅助容器版本的更新往往和业务的发布耦合在一起，这极大地限制了基础设施功能的迭代速度，并给业务使用基础设施功能带来了很大负担。如何高效地升级下沉的基础设施决定了迭代的速度，是提升竞争力和用户满意度的关键。相关技术中并没有一种通用的支持辅助容器热升级的机制。

发明内容

本申请提供一种辅助容器实现热升级的方法及装置，能够实现辅助容器独立热升级，而无需业务感知，从而提升产品竞争力和用户满意度。

本发明实施例提供了一种辅助容器实现热升级的方法，包括：

在应用实例中创建辅助容器和辅助容器对应的空容器；

需要对辅助容器进行热升级时，将空容器升级为新的辅助容器，并在升级过程中执行切换连接操作；

完成空容器到新的辅助容器的升级，将原有的辅助容器更改为新的辅助容器对应的空容器。

在一种示例性实例中，所述在应用实例中创建辅助容器和辅助容器对应的空容器之后，还包括：

对于需要热升级的所述辅助容器，设置热升级标记，用于表示所述辅助容器采用热升级方式。

在一种示例性实例中，在所述注入辅助容器时，还包括：

为创建的所述辅助容器设置环境变量，用于标识所述辅助容器的版本；

或者，通过配置文件标识所述辅助容器的版本。