CN116225617A - 容器实例的管理迁移方法、装置和电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种容器实例的管理迁移方法、装置和电子设备及存储介质，依据本申请实施例，获取目标容器实例在第一容器引擎中对应的管理配置数据，所述管理配置数据有对应的在第一容器引擎中的存储指引信息；根据所述管理配置数据在第二容器引擎中的存储指引信息以及不同容器引擎中对应的存储指引信息的对应关系，将所述管理配置数据写入所述第二容器引擎；启动所述第二容器引擎对所述目标容器实例的管理任务，以将所述目标容器实例的管理迁移至所述第二容器引擎，在不影响容器实例的任务进程的状态下，实现容器实例的管理迁移，完成由第一容器引擎到第二容器引擎的热迁移。

Description

容器实例的管理迁移方法、装置和电子设备及存储介质

技术领域

本申请涉及容器化技术领域，尤其涉及一种容器实例的管理迁移方法、装置和电子设备及存储介质。

背景技术

容器化技术是指将应用软件代码和所需的组件(例如库、框架和其他依赖项)打包在一起，让它们隔离在自己的容器中的技术。容器可以将容器内的应用软件和用于承载容器的周围计算环境或是基础结构隔离开来，因此，基于容器化技术开发应用软件可以在任何环境和基础架构上运行。容器化技术可以用于创建全新、可扩展的云原生应用程序，实现对传统系统的改造，这项技术轻量、易于管理、可移动性高的特点使其受到欢迎，相关技术也随之迅速发展。

随着容器化技术的应用范围的逐渐扩大，用户对容器的需求逐渐提高，这促使了容器化技术的更新和升级。容器服务提供商可以通过对容器管理工具以及组件的更新或是替换，实现容器的持续迭代，以基于容器化技术提供更优质的服务。

目前，在对已经启动容器实例进行升级时，例如对管理容器的容器引擎的迁移时，需要暂停容器实例中的应用进程，或是需要额外的资源以使用升级后的容器引擎重建容器实例。这提升了资源开销和开发成本，并且严重影响了用户使用容器服务的使用体验。因此，需要提供新的容器实例的管理迁移方法，以减低对容器实例的管理进行迁移时的资源开销，提升用户体验，进一步助力容器化技术的发展。

发明内容

本申请实施例提供一种容器实例的管理迁移方法、装置和电子设备及存储介质，以解决上述一个或多个技术问题。

第一方面，本申请实施例提供了一种容器实例的管理迁移方法，所述方法包括：获取目标容器实例在第一容器引擎中对应的管理配置数据，所述管理配置数据有对应的在第一容器引擎中的存储指引信息；根据所述管理配置数据在第二容器引擎中的存储指引信息以及不同容器引擎中对应的存储指引信息的对应关系，将所述管理配置数据写入所述第二容器引擎；启动所述第二容器引擎对所述目标容器实例的管理任务，以将所述目标容器实例的管理迁移至所述第二容器引擎。

第二方面，本申请实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，所述处理器在执行所述计算机程序时实现上述任一项所述的方法。

第三方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法。

与相关技术相比，本申请具有如下优点：

依据本申请实施例，首先获取目标容器实例在第一容器引擎中对应的管理配置数据，管理配置数据有对应的在第一容器引擎中的存储指引信息。根据存储指引信息获取管理配置数据可以保证所获取的管理配置数据的准确性，从而确保管理迁移的安全性。在由第一容器引擎获取到管理配置数据后，根据管理配置数据在第二容器引擎中的存储指引信息以及不同容器引擎中对应的存储指引信息的对应关系，将管理配置数据写入第二容器引擎。通过存储指引信息的对应关系，可以将管理配置数据准确写入第二容器引擎，以使得第二容器引擎可以按照管理配置数据对容器实例进行管理。然后，启动所述第二容器引擎对所述目标容器实例的管理任务，以将所述目标容器实例的管理迁移至所述第二容器引擎。由于获取和写入管理配置数据的过程中不涉及停止第一容器引擎的管理任务，从而可以在不影响容器实例所提供的服务进程的状态下，实现容器实例的管理迁移，完成由第一容器引擎到第二容器引擎的热迁移，提高容器化应用用户的使用体验。

进一步，可以在由第一容器引擎获取管理配置数据之前，对由第一容器引擎记录的数据与目标容器实例的实时运行状态进行对比，并在确认对比结果一致的情况下，获取目标容器实例在第一容器引擎中对应的管理配置数据，以保证所获取管理配置数据的准确性，以及管理迁移的安全性。

由于管理配置数据的数据结构复杂，可以根据多种存储指引信息分别进行对管理配置数据的获取。例如，可以根据字段标识、键名、存储路径等存储指引信息的索引，获取相应的管理配置数据，以保证所获取的管理配置数据的准确性。

除此之外，还可以在将管理配置数据写入第二容器引擎之后，可以通过调用目标容器实例的响应模块对应的模拟装置，向第一容器引擎和第二容器引擎分别发送请求消息，并对比第一容器引擎和第二容器引擎分别反馈的响应消息，以根据对比结果确定目标容器实例的管理迁移成功。通过这种方式可以在不停止第一容器引擎对目标容器实例的管理的前提下，同时获取由第一容器引擎和第二容器引擎分别反馈的响应消息，以对所填入第二容器引擎管理配置数据的准确性的检查，确定第二容器引擎可以根据所填入的管理配置数据成功接管目标容器实例。

可以理解的是，在理想状态下，所获得的来自第一容器引擎和第二容器引擎的响应消息是一致的，然而实际应用中会产生一些可以忽略的不一致的情况，因此，在对比第一容器引擎和第二容器引擎分别反馈的响应消息时，还可以设定对比维度，并忽略在设定对比维度内的不一致情况，以提高管理迁移的灰度能力。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，可依照说明书的内容予以实施，并且为了让本申请的上述和其他目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请的一些实施方式，而不应将其视为是对本申请范围的限制。

图1A示出了一种容器实例的管理调用链路的示意图；

图1B示出了一种容器实例的节点架构示意图；

图1C示出了一种管理容器组的架构示意图；

图2A示出了本申请实施例中提供的一种容器实例的管理迁移方案的场景示意图；

图2B示出了本申请实施例中提供的一种容器实例的管理迁移方案的应用实例示意图；

图3示出了本申请实施例中提供的一种容器实例的管理迁移方法的流程图；

图4示出了一种管理容器组的管理配置数据的示意图；

图5示出了本申请实施例中提供的一种容器实例的管理迁移方案的流程图；

图6示出了本申请实施例中提供的一种容器实例的管理迁移装置的结构框图；以及

图7示出了用来实现本申请实施例的电子设备的框图。

具体实施方式

在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的构思或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的，而非限制性的。

为便于理解本申请实施例的技术方案，以下对本申请实施例的相关技术进行说明。以下相关技术作为可选方案与本申请实施例的技术方案可以进行任意结合，其均属于本申请实施例的保护范围。

首先结合图1A、图1B和图1C对本申请中涉及到的相关概念做出介绍。

图1A示出了一种容器实例的管理调用链路的示意图。如图1A所示，在容器集群管理平台上，实际负责运行容器集群中的容器实例的组件是节点代理(Node Agent)组件，该组件通过容器运行时接口(Container Runtime Interface，CRI)与容器引擎(ContainerEngine)进行交互，具体而言，节点代理组件可以通过发送接口请求对容器实例进行启动和管理，守护运行容器实例的程序进程。与之对应地，容器引擎通过实现容器运行时接口即可接入容器集群管理平台，从而接收来自节点代理组件的管理和调用。其中，节点代理组件可以由容器集群管理平台提供，例如，开源容器集群管理平台Kubernetes可以对云平台中的一个或多个主机上的容器实例集群进行管理，由Kubernetes提供的节点代理组件为Kubelet。在节点代理组件启动容器引擎后，容器引擎可以根据容器实例的管理配置数据，调用底层运行时(Low-Level Runtimes)，并与一个或多个底层运行时一同实现对容器实例的管理，确保容器实例按照预期运行。在一些场景中，也将容器引擎称为高层运行时(High-levelRuntimes)。其中，底层运行时主要负责为容器实例设置命名空间(Namespace)和控制组等功能，而容器引擎可以支持更多高级功能，主要负责镜像管理、远程过程调用(RemoteProcedure Call，RPC)和提供API(Application Programming Interface，应用程序接口)等功能。可以理解的是，在实际应用中，不同的容器引擎或是底层运行时所支持的功能也会有所差异。

图1B示出了一种容器实例的节点架构示意图。在容器化技术场景下，节点可以是互联网数据中心(Internet Data Center，IDC)中的物理机，也可以是云计算平台上的虚拟机，具体又可以包括主节点(Master Node)和工作节点(Worker Node)。如图1B所示，上述涉及到的节点代理组件运行在容器实例集群的各个工作节点中，负责通过接收并执行由主节点发来的指令管理Pod(管理容器组)及Pod中的容器实例，以维护部署在该工作节点上的容器实例的生命周期。其中，主节点可以用于为容器实例集群提供配置和管理资源的API，具体可以接收来自用户界面(User Interface，UI)或是命令行界面(Command-LineInterface，CLI)的指示，并按照指示下发任务至与主节点连接的工作节点。工作节点是指用于承载容器实例的最小计算硬件单元，每个工作节点上都运行有节点代理组件。

管理容器组是容器集群管理平台上容器化应用的最小管理维度，每个管理容器组中可以运行有一个或多个相互关联的容器实例。也即是说，在工作节点中，节点代理组件以管理容器组为单位对部署在该工作节点的容器实例进行管理。容器通常被设计为一个容器只运行一个进程，不会将多个进程聚集在一个单独的容器中。在这一设定条件下，可以将互相紧密耦合并且需要使用一些共享资源(比如磁盘)的多个容器实例放到同一个管理容器组中，并通过将管理容器组作为一个整体进行调用和管理，实现对由多个进程组成的应用程序的容器化处理。

图1C示出了一种管理容器组的架构示意图。如图1C所示，Pod中容器实例可以包括Sandbox(沙箱容器实例)和Container(功能容器实例)这两种容器类型。其中，沙箱容器实例用于为Pod配置基础运行环境。在实际应用中，在创建Pod时，节点代理组件首先会创建一个沙箱容器实例，然后再创建功能容器实例。所创建的功能容器实例与沙箱容器实例相关联，功能容器实例是用于承载并运行容器化应用的服务负载的容器实例。图1C示出的管理容器组内有1个沙箱容器实例(沙箱容器实例0)和与该沙箱容器实例相关联的3个功能容器实例(功能容器实例0，1,和2)。上述3个功能容器实例在由沙箱容器实例所配置的基础运行环境中运行。

接下来对应用本申请实施例所提供的容器实例的管理迁移方案的应用场景进行说明。图2A是示例性的用于实现本申请实施例中提供的一种容器实例的管理迁移方案的场景的示意图。如图2A所示，容器化应用的提供方通过容器集群管理平台管理容器化应用。为了对容器实例集群进行升级，容器化应用的提供方希望将容器实例的管理由第一容器引擎迁移至第二容器引擎。

将从第一容器引擎获得管理配置数据填入第二容器引擎，以使得第二容器引擎可以根据管理配置数据管理目标容器实例，并以热迁移(迁移过程不停止服务进程)的方式实现由第一容器引擎到第二容器引擎的管理迁移。由于目标容器实例上的服务负载在迁移过程中可以正常运行，因此对于由目标容器实例运行的容器化应用，上述迁移过程对使用容器化应用的用户来说是无感知的，从而可以在升级容器实例集群的同时保证服务不中断，进而保证了用户的使用体验。

为了提高管理迁移的准确性和安全性，可以为管理迁移进行前置检查(Pre-Check)和后置检查(Post-Check)。其中，前置检查可以包括，在进行管理迁移前对第一容器引擎中所记录的管理配置数据的准确性的检查。如图2A所示，目标容器实例的运行是由第一容器引擎调用底层运行时进行管理的。由于在第一容器引擎和底层运行时之间存在数据同步不及时的情况，因此，对于目标容器实例的运行状态这一数据，相比于第一容器引擎，底层运行时对目标容器实例运行状态的记录更为准确。在这种情况下，可以对比第一容器引擎和底层运行时对同一管理配置数据的记录，并可以在对比结果出现差异时重启节点代理组件，以通过重新启动第一容器引擎的方式，使第一链路上的数据同步，以使得由第一容器引擎记录的管理配置数据更为准确，从而提高管理迁移的安全性。

涉及到的后置检查可以包括在启动第二容器引擎对目标容器实例的管理任务之前，对所填入第二容器引擎管理配置数据的准确性的检查。例如，可以分别对第一容器引擎和第二容器引擎发送请求消息，然后对比所获得的响应消息。在理想状态中，在所填入的管理配置数据准确无误的情况下，所获得的来自第一容器引擎和第二容器引擎的响应消息是一致的。因此，通过确定响应消息的对比结果一致，可以确定管理迁移成功，迁移结果无误。通过后置检查可以提高管理迁移的安全性，避免在填入第二容器引擎的管理配置数据有误时就将第二容器引擎投入使用，导致容器化应用的服务受到影响。

除此以外，在对多个目标容器实例进行管理迁移时，在启动第二容器引擎对目标容器实例的管理任务前，还可以通过灰度发布的方式，实现管理迁移的平滑过渡，进一步提高管理迁移过程中容器实例集群的稳定性。

图2B示出了本申请实施例中提供的一种容器实例的管理迁移方案的应用实例示意图。具体而言，图2B中示意性地示出了在Kubernetes分别使用Docker和Containerd管理容器实例时的管理调用链路示意图。在以Docker作为容器引擎时，容器实例的管理调用链路如图2B中第一链路所示。由于Docker本身并没有实现容器运行时接口，因此需要为Docker配置一个接口转接组件Dockershim(Docker垫片)，以将容器运行时接口转化为Docker API，使得节点代理组件能够正确地通过Docker管理容器实例，从而使Docker可以接入容器集群管理平台。在第一链路中，Containerd作为底层运行时，用于接收由Docker下发的创建、删除容器实例等请求，并创建相应的任务进程，以实现上述请求。

在以Containerd作为容器引擎时，容器实例的管理调用链路如图2B中第二链路所示。以Containerd作为容器引擎时，可以通过为Containerd接入插件(Plugin)的方式，为Containerd拓展能力。例如，接入CRI Plugin(CRI插件)后的Containerd可以获得通过CRI与Kubelet进行交互的能力，以使得Kubelet可以通过Containerd管理容器实例。

在本申请实施例中，可以将用于执行容器实例的管理迁移方法的装置集成于插件中，并将此插件记为管理迁移插件。通过为Containerd接入管理迁移插件，可以使Containerd获得管理迁移的能力。例如，接入管理迁移插件后的Containerd可以从目标容器实例的容器引擎获取管理配置数据，以使用获取到管理配置数据对目标容器实例进行管理，并配置Kubelet，使得Kubelet请求Containerd开始对目标容器实例的管理任务，从而完成将目标容器实例的管理迁移至Containerd的迁移过程。可以理解的是，在本申请实施例中，在对容器实例进行管理迁移前，可以首先检查用管理迁移插件的存在情况。在确定管理迁移插件存在的情况下，可以进一步检查管理迁移插件的管理迁移功能的运行状态。在管理迁移功能为开启，且正常运行时，即可使用管理迁移插件对目标容器实例进行管理迁移。

除此之外，由图2B可以看出，相比于以Docker作为容器引擎的第一链路，以Containerd作为容器引擎时的第二链路更短，第二链路远程过程调用的次数更少，因此使用第二链路管理并运行容器实例可以有更稳定的效果。此外，在第二链路中所涉及到的组件也更少，从而占用的节点资源更少，相比于使用第一链路，使用第二链路还可减少资源消耗，提高容器实例集群的整体性能。

本申请实施例提供了一种容器实例的管理迁移方法，如图3所示为本申请一实施例的容器实例的管理迁移方法300的流程图，该方法300可以包括：

在步骤S301中，获取目标容器实例在第一容器引擎中对应的管理配置数据，所述管理配置数据有对应的在第一容器引擎中的存储指引信息。

在本申请实施例中涉及到的容器引擎是指对容器实例进行镜像管理、远程过程调用和提供API等管理功能的容器管理工具。涉及到的目标容器实例是指容器实例集群中的部分或全部容器实例。其中，为了对管理迁移前后的容器引擎进行区分，将迁移前所使用的容器引擎为第一容器引擎，将迁移后管理目标容器实例的容器引擎记为第二容器引擎。

在对容器实例进行管理迁移时，首先获取目标容器实例在第一容器引擎中对应的管理配置数据，也即是第一容器在管理目标容器实例时所使用的管理配置数据。涉及到的管理配置数据可以包括目标容器实例的元数据(Metadata)、说明数据(Spec)和状态数据(Status)。其中，元数据又可以包括容器名、容器ID、日志文件路径、命名空间和标签等；说明数据可以包括与目标容器实例相关的挂在卷数据；状态数据可以包括目标容器实例的运行状态、条件、内部IP地址(Internet Protocol Address，互联网协议地址)等数据。

目标容器实例的管理配置数据可以是由第一容器引擎所直接生成并记录的数据；也可以是由第一容器引擎所调用的底层运行时所生成，并由第一容器引擎记录的数据。第一容器引擎依据管理配置数据对目标容器实例进行管理，与目标容器实例对应的管理配置数据存储在第一容器引擎对应的信息数据库中，且对应具有独特的存储指引信息。在该信息数据库中，根据存储指引信息的索引即可准确获取与存储指引信息对应的管理配置数据。

在一种可能的实现方式中，还可以在容器实例集群中确定第一容器引擎对应管理的容器实例，作为待执行管理迁移的目标容器实例。也即是说，在对容器实例集群实施管理迁移前，可以首先将以第一容器引擎作为容器引擎的容器实例确定为目标容器实例，以在后续将目标容器实例的管理由第一容器引擎迁移为第二容器引擎。在确定容器实例集群中以第一容器引擎作为容器引擎的容器实例时，可以通过节点代理组件读取容器实例中容器实例的容器引擎信息，并将容器引擎信息为第一容器引擎所对应管理的容器实例确定为目标容器实例。

在容器实例集群中，多个容器实例可能对应由不同容器引擎管理，通过首先确定待执行管理迁移的目标容器实例，可以保证管理迁移的对象满足管理迁移的需求。上述管理迁移的需求即是指将容器实例的管理由第一容器引擎迁移为第二容器引擎的需求。在实际应用中，该需求可能来源于容器化应用提供方、容器服务提供商以及容器集群管理平台提供商。以下通过两个应用示例进行展开说明。

在一个应用示例中，容器化应用的提供方使用第一容器引擎管理容器集群。随着各容器引擎的版本更新，容器化应用的提供方希望使用功能更完善的第二容器引擎管理容器集群，以向容器化应用用户提供更加稳定的服务，从而会产生管理迁移的需求。

在另一个应用示例中，在容器集群管理平台提供商停止某些工具或是组件的情况下，也会产生管理迁移的需求。例如，在基于Kubernetes管理容器实例集群，容器实例集群中的全部或部分容器实例使用Docker作为容器引擎的应用场景下，结合图2B以及前述说明可知，Docker需要通过Dockershim实现容器运行时接口。其中，由于Dockershim是由Kubernetes为Docker提供的接口转接组件，因此，Dockershim的维护与Kubernetes具有较强的依赖性。在Kubernetes停止提供Dockershim的情况下，对于容器集群中使用Docker作为容器引擎的容器实例，即会产生将Docker迁移为除了Docker以外的其他容器引擎的管理管理迁移的需求。在这一应用场景下，Docker即为第一容器引擎，在对容器实例集群中的容器实例进行管理迁移前，即可首先确定容器实例的容器引擎，将由Docker管理的容器实例确定为待执行管理迁移的目标容器实例。

在一种可能的实现方式中，还可以确认目标容器实例的命名空间中记录的管理配置数据与目标容器实例的实时运行状态一致。其中，涉及到的运行状态可以包括Creating(创建中)、Created(已创建，但还未运行)、Running(运行中，正在执行设定的任务)和Stopped(运行完成，或运行出错，或暂停状态)等。目标容器实例的命名空间中记录的管理配置数据是指由目标容器实例的第一容器引擎所记录的关于目标容器实例运行状态的数据。也即是说，在对目标容器实例进行管理迁移前，可以确认由第一容器引擎所记录的目标容器实例的运行状态与目标容器实例的实时运行状态一致。通过确认由第一容器引擎记录的数据与目标容器实例的实时运行状态一致，可以保证由第一容器引擎获取的管理配置数据的准确性，从而可以提高对目标容器实例进行管理迁移的安全性。

如图2A所示，在目标容器实例的管理调用链路中，容器实例由容器引擎调用底层运行时进行管理。由于在管理调用链路中的数据同步不及时，对于同一管理配置数据，可能存在由容器引擎和底层运行时所记录的内容不一致的情况。可以理解的是，容器引擎和底层运行时对于目标容器实例管理的分工具有差异，容器引擎和底层运行时各自所管理内容对应具有正确的管理配置数据，即可确保目标容器实例的正常运行。在实际应用中，即使存在上述不一致的情况，也不影响目标容器实例的正常运行，然而，在管理迁移的场景下，容器引擎中记录的管理配置数据与目标容器实例的实时运行状态不一致会导致迁移结果产生错误，因此需要对容器引擎中记录的管理配置数据进行检查，确认容器引擎中记录的管理配置数据与实际状态的一致性。

由于底层运行时直接负责对于目标容器实例生命周期的管理，因此对于目标容器实例的运行状态，由底层运行时所记录的数据更为准确，也即是说，由底层运行时获取的运行状态是目标容器实例的实时运行状态。通过确认由容器引擎和底层运行时分别记录的目标容器实例的运行状态一致，可以确认目标容器实例的命名空间中记录的管理配置数据与目标容器实例的实时运行状态一致。具体而言，在第一容器引擎侧，通过目标容器实例的命名空间中记录的管理配置数据可以获取由第一容器引擎记录的目标容器实例的运行状态。在底层运行时侧，通过读取底层运行时的信息数据库，可以获取由底层运行时记录的目标容器实例的运行状态。在分别获取到由第一容器引擎和底层运行时记录的运行状态后，将所获取的到运行状态进行对比，若对比结果一致，可以确认目标容器实例的命名空间中记录的管理配置数据与目标容器实例的实时运行状态一致，从而确认由第一容器引擎记录的容器运行状态准确，进而可以提高对目标容器实例进行管理迁移的安全性。

在上述对比结果是不一致时，可以通过重启第一容器引擎的方式，同步第一容器引擎中记录的管理配置数据与目标容器实例的底层运行时所记录的管理配置数据，使目标容器实例的命名空间中记录的管理配置数据与目标容器实例的实时运行状态一致。

结合图2B中示出的应用场景，在使用第一链路管理容器集群的场景下，Docker和Containerd中分别记录有关于Docker容器实例的管理配置数据，其中即包括容器的运行状态。在第二链路上的管理迁移插件获取由第一链路Docker侧记录的管理配置数据前，首先确认第一链路中Docker侧和Containerd侧对Docker容器实例的运行状态的记录是否一致。例如，若发现某一Docker容器实例在Docker侧记录的运行状态为Running，而在Containerd侧记录的运行状态为Stopped，则说明Docker容器实例的命名空间中记录的管理配置数据与其实时运行状态不一致，此时可以通过重启Docker，完成第一链路中Docker侧与Containerd侧记录的管理配置数据的数据同步，使Docker容器实例的命名空间中记录的管理配置数据与其实时运行状态一致，从而保证由第二链路上的管理迁移插件所获取的管理配置数据的准确性，进而提高由Docker容器实例迁移为Containerd容器实例的安全性。

在一种可能的实现方式中，在获取目标容器实例在第一容器引擎中对应的管理配置数据时，可以从第一容器引擎对应的信息数据库中读取字段数据作为管理配置数据。也即是说，以字段形式存储在第一容器引擎的信息数据库中的管理配置数据，可以直接通过读取信息数据库的方式获取。

其中，字段数据可以包括第一类字段和/或第二类字段中包括的键值对(Key-Value)。具体而言，第一类字段包括字段标识和字段内容。在获取第一类字段以作为管理配置数据时，可以以第一类字段的字段标识为索引，读取信息数据库中与字段标识对应的字段内容，并将字段标识和字段内容获取为管理配置数据。例如，在由Docker作为第一容器引擎的场景下，在获取目标容器实例在Docker中对应的管理配置数据时，上述第一类字段的字段标识即可以包括容器主机名(docker.Config.Hostname)、容器名(docker.Name)、容器ID(docker.ID)和容器镜像(docker.Image)等。根据上述字段标识的索引，即可在Docker的信息数据库中读取相应字段内容，以获取管理配置数据。

第二类字段的字段标识为标签(Tag)。以标签为字段标识的第二类字段，字段内容以键值对的形式存储了数据结构更为复杂的管理配置数据。相比于可以直接将字段标识和字段内容作为管理配置数据的第一类字段，在获取第二类字段时，以标签为索引读取第一容器引擎在信息数据库中对应于该字段标识的字段内容，然后将字段内容中的一个或多个键值对作为管理配置数据。

图4示出了在一个应用示例中管理容器组的管理配置数据的示意图。如图4所示，在Pod名为bar/foo的管理容器组中部署有四个目标容器实例，其中一个目标容器实例已经停止运行，另外三个目标容器实例中的一个是沙箱容器实例，另外两个是与该沙箱容器实例相关联的功能容器实例。在运行中的沙箱容器实例即对应记录有第一类字段和第二类字段。其中，第一类字段的字段标识包括容器名和容器ID，这两个字段标识所对应的字段内容分别为k8s_POD_dummy_foo_bar_iamuid_1和abcdefg。对于字段表示为标签的第二类字段，其对应的字段内容为一个键值对，该键值对的Key(键名)为io.kubernetes.docker.type，Value(值)为podsandbox。与沙箱容器实例关联的两个功能容器实例也记录有第一类字段和第二类字段，由于数据结构与上述沙箱容器实例中所记录的相同，具体的记录内容在此不再赘述。

结合图4，在获取管理配置数据时，即可将上述获取到的第一类字段，即容器名：k8s_POD_dummy_foo_bar_iamuid_1和容器ID：abcdefg，以及第二类字段，即io.kubernetes.docker.type＝podsandbox作为管理配置数据。

在一种可能的实现方式中，在获取目标容器实例在第一容器引擎中对应的管理配置数据时，可以从第一容器引擎对应的信息数据库中读取目标容器实例对应的网络隔离状态和容器隔离状态，生成目标容器实例的命名空间对应的隔离配置数据，作为管理配置数据。其中，网络隔离状态包括是否与宿主机隔离，容器隔离状态包括容器级隔离、Pod级隔离和不隔离(共享宿主机)。在获取到上述目标容器实例对应的网络隔离状态和容器隔离状态后，即可根据多获取到的隔离状态生成目标容器实例的命名空间对应的隔离配置数据。

例如，在获取到关于UNIX分时操作系统(UNIX Time Sharing，UTS)的网络隔离状态为与宿主机隔离时，所生成的目标容器实例的命名空间对应的隔离配置数据为容器级隔离。除此之外，还可以基于目标容器实例的类型，生成隔离配置数据。例如，对于功能容器实例，关于其进程间通讯(Inter-Process Communication，IPC)的命名空间，即可以直接生成隔离配置数据为容器级隔离，作为管理配置数据；在获取到关于进程号(ProcessIdentification，PID)的容器隔离状态为与其他容器共享时，对于功能容器实例，对应的隔离配置数据可以为NamespaceMode_TARGET，或是NamespaceMode_POD。

另外，还可以从第一容器引擎对应的信息数据库中查找第三类字段，其中，第三类字段包括字段标识为访问路径和挂载卷的多个字段。可以理解的是，此处提及的访问路径是指第一容器引擎用于访问相关数据(例如挂载卷)的路径，对于第一容器引擎所处的第一链路来讲，该访问路径即是存储上述相关数据的存储路径。可以首先以访问路径这一字段标识为索引，获取对应的字段内容，即实际的访问路径，然后通过访问所获取的访问路径，读取记录在该访问路径下的挂载卷作为管理配置数据。

在一种可能的实现方式中，在获取目标容器实例在第一容器引擎中对应的管理配置数据时，可以从目标容器实例的宿主机读取目标容器实例的命名空间的网络接口对应的网络地址信息，作为管理配置数据。其中，网路地址信息是指目标容器实例所处的管理容器组所使用的IP地址。在一个应用示例中，在获取目标容器实例的网络地址信息时，可以通过执行读取命令，获得由宿主机提供的目标容器实例在eth0接口上的IP地址，作为管理配置数据。

在一种可能的实现方式中，在获取目标容器实例在第一容器引擎中对应的管理配置数据时，可以根据管理配置数据在第一容器引擎中的存储指引信息，获取目标容器实例在第一容器引擎中对应的管理配置数据。

本申请实施例中涉及到的管理配置数据有对应的在第一容器引擎中的存储指引信息。在获取管理配置数据时，可以获取第一容器引擎中的全量管理配置数据，也可以根据存储指引信息，获取全部或部分管理配置数据。例如，在以Docker为第一容器引擎的应用示例中，可以通过执行命令docker inspect获取Docker侧的全量元数据，作为管理配置数据。

进一步，还可以根据具体的字段标识或键名，获取相应的管理配置数据。例如，在由第一容器引擎对应的信息数据库获取管理配置数据时，可以根据字段标识或键名过滤出信息数据库中的部分数据作为管理配置数据。

在容器化技术的场景中，容器实例的管理调用链路中的容器运行时接口向容器引擎提供由容器集群管理平台管理、编排容器化应用时的接口规范，其中即包括关于管理配置数据的接口规范。由于管理调用链路中的容器引擎需要依据接口规范实现对容器实例的管理，因此，在获取目标容器实例在第一容器引擎中对应的管理配置数据之前，还可以首先基于容器引擎共用的接口规范，确定需要从所述第一容器引擎中获取的管理配置数据。也即是说，在本申请实施例中，可以基于第一容器引擎与第二容器共用的接口规范，确定所需获取的管理配置数据，以根据所需由第一容器引管理配置数据，以使得第二容器引擎可以根据所获取的管理配置数据正确地管理目标容器实例。

在一种应用示例中，目标容器实例的第一容器引擎为Docker，第二容器引擎为Containerd。结合由图2B中示出的场景，容器集群由Kubernetes平台进行管理和编排，因此第一链路和第二链路共用同一容器运行时接口(CRI)，并通过节点代理组件Kubelet与平台对接。在这一场景中，配置于Docker和Containerd的管理配置数据均符合CRI的接口规范。因此，在由Docker侧获取管理配置数据时，即可以首先基于CRI确定Containerd在管理目标容器实例所需的管理配置数据。

在一种可能的实现方式中，在获取目标容器实例在第一容器引擎中对应的管理配置数据之前，还可以确定同一管理配置数据在不同容器引擎中对应的存储指引信息。

可以理解的是，容器引擎之间的内部设置可能是不同的，对于相同的管理配置数据，第一容器引擎和第二容器引擎各自使用相应的存储指引信息，对管理配置数据进行标识。因此，在由第一容器引擎获取目标容器市里的管理配置数据之前，还可以确定管理配置数据在第一容器引擎和第二容器引擎中分别对应的存储指引信息。一方面，通过确定第二容器引擎中存储指引信息，可以根据第二容器引擎在管理容器实例时所需要的管理配置数据，再根据相同管理配置数据在第一容器引擎中对应的存储指引信息，确定需要从第一容器引擎获取的管理配置数据；另一方面，通过确定管理配置数据在第一容器引擎的存储指引信息，即可以将所确定的存储指引信息作为索引，从第一容器引擎获取相应的管理配置数据。

其中，涉及到的存储指引信息可以包括字段标识、键名、存储路径中至少一种。例如，结合前述实施例，字段标识即可以包括容器主机名、容器名和容器ID等。在一种应用示例中，目标容器实例的第一容器引擎为Docker，第二容器引擎为Containerd。在Containerd侧，容器名这一管理配置数据的具体字段标识为io.kubernetes.cri.container-name，该管理配置数据Docker的具体字段标识为io.kubernetes.container.name。也即是说，容器名这一管理配置数据在Docker的存储指引信息为io.kubernetes.container.name，然后即可以该存储指引信息为索引，获取由Docker记录的容器名的具体值。

在步骤S302中，根据所述管理配置数据在第二容器引擎中的存储指引信息以及不同容器引擎中对应的存储指引信息的对应关系，将所述管理配置数据写入所述第二容器引擎。

由于对于相同的管理配置数据，第一容器引擎和第二容器引擎各自使用相应的存储指引信息标识管理配置数据，因此可以根据存储指引信息的对应关系，确定所获取的管理配置数据在第二容器引擎的存储指引信息，并按照所确定的存储指引信息将管理配置数据写入第二容器引擎。

其中，对应关系可以通过分析第一容器引擎和第二容器引擎中对存储管理配置信数据的规则设置，并根据相同管理配置数据在不同容器引擎分别对应的存储指引信息确定。在一个应用实例中，以Docker作为第一容器引擎，并以Containerd作为第二容器引擎。在该应用场景中，一些可能的字段标识及键名的对应关系如下表1所示。

表1Docker-Containerd字段标识及键名的对应关系

如表1所示Docker侧和Containerd侧分别使用不同的存储指引信息(如表1中示出的字段标识或是键名)标识管理配置数据。在由Docker侧获取到管理配置数据后，即可根据表1中示出的字段标识及键名的对应关系，确定该管理配置数据在Containerd侧的存储指引信息，将管理配置数据写入Containerd由存储指引信息所指引的存储位置中。

可以理解的是，由于容器引擎之间的内部设置具有差异，在将管理配置数据写入第二容器引擎之前，可以按照第二容器引擎内部设置的要求，对所写入的数据做出适应性调整，具体可以包括对数据格式进行调整，或是调整所需的关键词字符等。本申请实施例对具体的调整内容不做限制。

例如，结合上述应用示例，对于容器类型这一管理配置数据，Docker侧对于容器类型的具体管理配置数据的格式要求为podsandbox和container，分别对应于沙箱容器实例和功能容器实例。而Containerd侧对于容器类型的具体管理配置数据的格式要求为sandbox和container。在由Docker侧获取到容器类型为podsandbox时，在写入Containerd前，可以将podsandbox调整为sandbox(即去除pod字符)，再按照存储指引信息将sandbox写入Containerd侧对应的存储位置。

在本申请实施例中，根据对应关系写入管理配置数据，可以保证将管理配置数据写入第二容器引擎中正确的存储位置，从而使得第二容器引擎可以根据所写入的管理配置数据对目标容器实例进行管理，进而保证管理迁移的成功执行。

在一种可能的实现方式中，在将管理配置数据写入第二容器引擎中时，可以根据管理配置数据在第二容器引擎中对应的存储指引信息，将管理配置数据写入第二容器引擎中存储指引信息对应的存储位置。

结合前述实施例，基于由第一容器引擎获取的字段数据，对于第一类字段或第二类字段，即可直接根据在上述实施例中提及的字段标识及键名的对应关系或标签对应关系(如表1示出的Docker-Containerd字段标识及键名的对应关系)，将所获取的管理配置数据按照其在第二容器引擎中的字段标识或键名，写入与第二容器引擎对应的信息数据库中。类似地，对于从目标容器实例的宿主机读取的网络地址信息，也可以根据第二容器引擎中关于目标容器引擎网络地址信息的存储指引信息，将所获取到的网络地址信息写入相应的存储位置。例如，在以Docker为第一容器引擎，以Containerd为第二容器引擎的应用示例中，可以将由Docker侧所读取到的目标容器实例网络接口上的IP地址，写入Containerd侧以sandboxstore.Metadata.IP为字段标识的相应存储位置中。对于第三类字段，在由第一容器引擎获取到挂载卷后，可以整体拷贝挂载卷，并将拷贝的挂载卷写入由第二容器引擎对应的存储路径下。

除此之外，在将目标容器实例的命名空间对应的隔离配置数据写入第二容器引擎时，可以根据第一容器引擎和第二容器引擎中关于命名空间的存储指引信息的对应关系，将生成的隔离配置数据写入所述第二容器引擎；也可以首先确定目标容器实例的容器类型，并根据目标容器实例的类型，写入相应的隔离配置数据。其中，容器类型即包括前述提及的沙箱容器实例和功能容器实例。在确定目标容器实例的容器类型时，可以根据第一类字段中以容器类型为字段标识的索引获取对应的字段内容。例如，在获取到目标容器实例为沙箱容器实例时，即可以在写入IPC的命名空间的管理配置数据时，直接写入容器级隔离。

在一种可能的实现方式中，在将管理配置数据写入第二容器引擎之后，还可以通过调用目标容器实例的响应模块对应的模拟装置，向第一容器引擎和第二容器引擎分别发送请求消息。对比第一容器引擎和第二容器引擎分别反馈的响应消息，并根据对比结果确定目标容器实例的管理迁移成功。也即是说，可以在将管理配置数据写入第二容器引擎之后，通过模拟运行的方式对所获取的管理配置数据的准确性进行检验，从而确定目标容器实例的管理可以成功由第一容器引擎迁移至第二容器引擎。

其中，目标容器实例的响应模块是指用于响应针对目标容器实例的请求消息的模块。响应模块在接受到请求消息后，会反馈相应的响应消息。例如，关于目标实例创建、更新和停止时间的请求消息，响应模块所反馈的响应消息即是由请求消息所请求的关于目标实例创建、更新和停止时间的具体数据。涉及到的模拟装置用于模拟容器引擎在正常工作时管理目标容器实例的工作状态。通过调用目标容器实例的响应模块的模拟装置，即可以获取由容器引擎根据当前的管理配置数据管理目标实例容器的状态下所返回的响应消息。通过分别向第一容器引擎和第二容器引擎分别发送请求消息，可以同时获取由第一容器引擎和第二容器引擎所反馈的响应消息。

可以理解的是，在使用相同的管理配置数据对目标容器实例进行管理时，由不同容器引擎所反馈的响应消息应当是一致的。因此，通过对比上述由第一容器引擎和第二容器引擎所反馈的响应消息，即可在对比结果两侧响应消息一致时，确定迁移管理迁移成功。

结合图2B，在一个应用实例中，在使用Docker作为第一容器引擎，并使用Containerd作为第二容器引擎的场景下，第一链路上的Dockershim在部署形态上与Kubelet是编译在一起的，为了避免在Docker容器的运行状态实时变化的情况下获取由Docker侧返回的响应消息，可以读取Dockershim对应执行调用目标容器实例的响应模块的代码，并将读取到的代码集成于模拟装置中，通过执行该模拟装置，即可模拟Dockershim在正常工作时调用目标容器实例的响应模块的功能，以向Docker发送请求消息，从而可以获得由Docker侧反馈的响应消息；在第二链路中，通过向管理迁移插件发送请求消息，以获得由Containerd侧反馈的响应消息。然后，通过对比两侧反馈的响应消息，即可以在对比结果为两侧反馈的消息一致时，确定目标容器实例管理可以成功迁移，从而提高管理迁移的安全性。

在一种可能的实现方式中，在根据对比结果确定目标容器实例的管理迁移成功时，可以首先去除设定对比维度对应的对比结果，然后根据剩余对比结果一致，确定目标容器实例的管理迁移成功。由于第一容器引擎和第二容器引擎的架构和内部实现存在差异，在使用相同的管理配置数据管理容器实例时，对于相同的请求消息，由上述两种容器引擎分别反馈的响应消息可能存在不一致的情况，且其中一些不一致的情况不能用于判定管理迁移失败。也即是说，在确定目标容器实例的管理迁移成功时，在一些对比维度下，对比结果的不一致是可以忽略的。下面列举一些可能的对比维度示例。

例如，对于相同的容器镜像，在Docker侧以标签形式记录该镜像，而Containerd侧以摘要形式记录该镜像，从而导致两侧对于同一镜像的反馈消息并不一致；结合上述情况，在Docker侧的一个镜像可能对应有多个不同的标签，从而对于相同镜像，在Docker侧的标签和Containerd侧的摘要之间是n：1的关系，从而导致两侧对于统一镜像的反馈消息并不一致；又如，由于Docker通过调用作为底层运行时的Containerd管理目标容器实例，对于目标容器实的更新、停止时间的记录，两侧由于数据同步不及时而略有差别，从而导致反馈消息并不一致；再如，Docker侧与Containerd侧对于目标容器实例的日志存储位置可能存在区别，从而关于日志文件路径的响应信息可能存在不一致的情况。以上仅示意性地列举出一些可能的对比维度，由于在上述对比维度下产生的不一致是可以接受的，在根据对比结果确定目标容器实例的管理迁移成功时，通过忽略在上述对比维度下得到的对比结果，可以提高管理迁移的灰度能力，使得管理迁移顺畅进行。在实际应用中，还可以根据管理迁移的实践结果对设定维度进行调整，以进一步提高管理迁移的灰度能力，本申请实施例对具体的对比维度的设定不做限制。

在步骤S303中，启动所述第二容器引擎对所述目标容器实例的管理任务，以将所述目标容器实例的管理迁移至所述第二容器引擎。

其中，涉及到管理任务是指容器引擎对容器集群的管理任务。在本申请实施例中，启动第二容器引擎对目标容器实例的管理任务，也即是启用第二引擎容器对目标容器实例的管理。由于一个目标容器实例仅可以由一个容器引擎进行管理，因此启动第二容器引擎对目标容器实例的管理任务，即可以完成将目标容器引擎的管理由第一容器引擎迁移至第二容器引擎的管理迁移。

在一种可能的实现方式中，可以通过修改目标容器实例对应配置的容器引擎为第二容器引擎，以启动第二容器引擎对目标容器实例的管理任务。例如，可以在目标容器实例所对应的节点代理组件中，对目标容器实例所使用的容器引擎的配置由第一容器引擎改为第二容器引擎。

结合图2B，在Containerd接入的管理迁移插件完成由第一链路的Docker获取管理配置数据，并将所获取的管理配置数据写入Containerd后，将Kubelet中对目标容器实例所使用的容器引擎配置由Docker改为Containerd，然后重新启动Kubelet，重启后的目标容器实例的容器引擎即为Containerd，从而启动由Containerd对目标容器实例进行管理的管理任务，即可完成将将目标容器引擎的管理由Docker迁移至Containerd的管理迁移，以使得目标容器实例由Docker容器实例迁移为Containerd容器实例。

另外，在对多个目标容器实例进行管理迁移时，在启动第二容器引擎对目标容器实例的管理任务前，还可以通过灰度发布的方式，在容器实例集群中保留一部分节点上目标容器实例由第一容器引擎管理的状态，仅将另一部分节点上目标容器实例的管理迁移至第二容器引擎，从而实现管理迁移的平滑过渡，进一步提高管理迁移过程中容器实例集群的稳定性。

图5示出了本申请实施例中提供的一种容器实例的管理迁移方案的流程图。该流程图是对于使用Kubernetes平台管理容器集群的场景下，将容器实例的管理由Docker迁移至Containerd时的一种可能的实施方式的流程示意，上述场景即是由图2B所示出的应用场景。如图5所示，P1至P2示出了由本申请实施例提供的一种前置检查的流程，P2至P3示出了由本申请实施例提供的一种将管理配置数据写入Containerd的流程，P3至P4示出了由本申请实施例提供的一种后置检查的流程。在执行管理迁移时，可以使用CPT(Checkpoint)机制，例如使用CPT文件，对管理迁移中的多种状态进行记录，并根据状态相应执行后续步骤。以下对由图5示出的流程做进一步解释。

在执行前置检查的相关步骤以前，可以首先检查由Kubelet所管理的容器集群是否开启了热迁移功能。换而言之，在该场景中，可以首先判断是否对容器集群中的容器实例进行由Docker到Containerd的管理迁移。在确定迁移功能没有开启的情况下，无需执行后续与管理迁移相关的步骤。在确定迁移功能开启的情况下，可以读取CPT文件，获取当前的管理迁移状态。在由CPT文件读取到当前容器引擎的使用状态为正在使用Containerd作为容器引擎时，可以确定当前容器引擎符合预期，进而确定无需执行后续与管理迁移相关的步骤。在由CPT文件读取当前容器引擎的使用状态为正在使用Docker作为容器引擎时，即可确定需要进行管理迁移，并继续执行下一步骤。在确定需要进行管理迁移后，可以检查CPT文件中关于容器实例管理配置的修改状态的记录。若确定当前已经在Kubelet中修改过管理配置，即说明已经对容器实例完成了前置检查、向Containerd写入管理配置数据和将Kubelet中对容器实例所使用的容器引擎配置由Docker改为Containerd的相关步骤，从而确定可以跳过上述相关步骤，并开始执行后置检查的相关步骤。

在确定尚未对容器实例进行管理配置修改后，可以进行管理迁移的前置检查。首先可以检查管理迁移插件的启动状态。管理迁移插件即是由图2B所示出的第二链路中配置于Containerd上的插件。在该场景下，由管理迁移插件执行获取管理配置数据、驱动管理配置修改等相关步骤。因此，在管理迁移插件的启动状态为已启动时，可以继续进行后续步骤。在管理迁移插件的启动状态为其他状态(如未启动或是其他错误状态)时，可以向该容器集群的相关运维人员，例如容器化应用提供方的人员上报错误，并退出管理迁移流程。

在确定管理迁移插件已经启动后，可以对Docker中所记录的实时运行状态是否一致进行检查。在Docker中所记录的容器实例的运行状态与容器实例的实时运行状态不一致的情况下，可以通过重启Docker的方式，尝试修复Docker中所记录的错误数据，使Docker的记录同步为和实时运行状态一致。在一次重启后，若Docker记录的运行状态与实时运行状态仍不一致，可以通过多次重启的方式，使数据同步。可以理解的是，在本申请实施例中，还可以对重启次数进行记录，并预先设置最多尝试次数。在重启次数超出了预先设置的尝试次数后，可以向运维人员上报错误，终止当前流程，退出管理迁移。若在重启次数超出预先设置的尝试次数前，Docker记录的运行状态与实时运行状态已经一致，则可以确定完成了前置检查，可以进行后续步骤。

在通过前置检查后，可以由Docker侧获取管理配置数据。具体而言，在获取时，可以创建符号链接fake-docker-root，通过该连接读取真实路径下Docker侧的获取管理配置数据。换而言之，可以通过该链接，由Docker存储指引信息所指示的管理配置数据的存储位置，读取相应的管理配置数据。管理迁移插件在Containerd启动时会从符号链接获取，并向Containerd侧写入数据，因此可以通过重启Containerd的方式完成数据写入。在向Containerd写入管理配置数据后，即可修改Kubelet对容器实例的容器引擎配置为Containerd。然后更新CPT文件，以标记当前已经完成对容器引擎的管理配置修改。

最后，可以进行后置检查。在开始后置检查的相关步骤之前，可以首先检查CPT文件中关于后置检查状态的记录。在确定当前还未通过后置检查时，可以通过分别向Docker侧与Containerd侧发送请求消息，对比接收到的响应消息。在基于对比结果判断是否通过后置检查前，可以首先忽略记录在白名单(例如一个记录设定对比维度的文件)中的对比结果不一致的情况。然后再对对比结果进行检查，在由Docker侧与Containerd侧获得到的响应消息不一致时，可以向运维人员上报错误，终止当前流程，退出管理迁移。在由Docker侧与Containerd侧获得到的响应消息一致时，可以判断当前状态为通过后置检查，并将这一状态记录于CPT文件中，以标记当前已经完成了后置检查，并通过重启Kubelet的方式，使得Kubelet按照容器引擎配置请求Containerd开始对目标容器实例的管理任务。

与本申请实施例提供的方法的应用场景以及方法相对应地，本申请实施例还提供一种容器实例的管理迁移装置。如图6所示为本申请一实施例的容器实例的管理迁移装置600的结构框图，该装置600可以包括：

数据获取模块601，用于获取目标容器实例在第一容器引擎中对应的管理配置数据，所述管理配置数据有对应的在第一容器引擎中的存储指引信息；

数据写入模块602，用于根据所述管理配置数据在第二容器引擎中的存储指引信息以及不同容器引擎中对应的存储指引信息的对应关系，将所述管理配置数据写入所述第二容器引擎；

管理迁移模块603，用于启动所述第二容器引擎对所述目标容器实例的管理任务，以将所述目标容器实例的管理迁移至所述第二容器引擎。

在一种可能的实现方式中，所述装置600还可以包括容器实例确定模块，用于在容器实例集群中确定第一容器引擎对应管理的容器实例，作为待执行管理迁移的目标容器实例。

在一种可能的实现方式中，所述数据获取模块601，可以具体用于：从所述第一容器引擎对应的信息数据库中读取字段数据作为管理配置数据，所述字段数据包括第一类字段和/或第二类字段中包括的键值对，所述第一类字段包括字段标识和字段内容，所述第二类字段的字段标识为标签。

在一种可能的实现方式中，所述数据获取模块601，可以具体用于：从所述第一容器引擎对应的信息数据库中读取所述目标容器实例对应的网络隔离状态和容器隔离状态，生成所述目标容器实例的命名空间对应的隔离配置数据，作为管理配置数据；或，从所述第一容器引擎对应的信息数据库中查找第三类字段，通过访问所述第三类字段包括的访问路径获取挂载卷，作为管理配置数据，所述第三类字段包括字段标识为访问路径和挂载卷的多个字段。

在一种可能的实现方式中，所述数据获取模块601，可以具体用于：从所述目标容器实例的宿主机读取所述目标容器实例的命名空间的网络接口对应的网络地址信息，作为管理配置数据。

在一种可能的实现方式中，所述数据获取模块601，可以具体用于：根据所述管理配置数据在第一容器引擎中的存储指引信息，获取目标容器实例在所述第一容器引擎中对应的管理配置数据。

在一种可能的实现方式中，所述装置600还可以包括数据确定模块，用于在所述获取目标容器实例在第一容器引擎中对应的管理配置数据之前，基于容器引擎共用的接口规范，确定需要从所述第一容器引擎中获取的管理配置数据。

在一种可能的实现方式中，所述装置600还可以包括信息确定模块，用于在所述获取目标容器实例在第一容器引擎中对应的管理配置数据之前，确定同一管理配置数据在不同容器引擎中对应的存储指引信息，所述存储指引信息包括字段标识、键名、存储路径中至少一种。

在一种可能的实现方式中，所述数据写入模块602，可以具体用于：根据管理配置数据在第二容器引擎中对应的存储指引信息，将所述管理配置数据写入所述第二容器引擎中所述存储指引信息对应的存储位置。

在一种可能的实现方式中，所述管理迁移模块603，可以具体用于：修改所述目标容器实例对应配置的容器引擎为第二容器引擎。

在一种可能的实现方式中，所述装置600还可以包括状态确认模块，用于确认所述目标容器实例的命名空间中记录的管理配置数据与所述目标容器实例的实时运行状态一致。

在一种可能的实现方式中，所述装置600还可以包括迁移成功确定模块，用于在所述将所述管理配置数据写入所述第二容器引擎之后，通过调用目标容器实例的响应模块对应的模拟装置，向所述第一容器引擎和第二容器引擎分别发送请求消息；对比所述第一容器引擎和第二容器引擎分别反馈的响应消息，并根据对比结果确定目标容器实例的管理迁移成功。

在一种可能的实现方式中，所述迁移成功确定模块，可以具体用于：去除设定对比维度对应的对比结果；根据剩余对比结果一致，确定目标容器实例的管理迁移成功。

本申请实施例各装置中的各模块的功能可以参见上述方法中的对应描述，并具备相应的有益效果，在此不再赘述。

图7为用来实现本申请实施例的电子设备的框图。如图7所示，该电子设备包括：存储器701和处理器702，存储器701内存储有可在处理器702上运行的计算机程序。处理器702执行该计算机程序时实现上述实施例中的方法。存储器701和处理器702的数量可以为一个或多个。

该电子设备还包括：

通信接口703，用于与外界设备进行通信，进行数据交互传输。

如果存储器701、处理器702和通信接口703独立实现，则存储器701、处理器702和通信接口703可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(PeripheralComponentInterconnect，PCI)总线或扩展工业标准体系结构(Extended IndustryStandard Architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器701、处理器702及通信接口703集成在一块芯片上，则存储器701、处理器702及通信接口703可以通过内部接口完成相互间的通信。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现本申请实施例中提供的方法。

本申请实施例还提供了一种芯片，该芯片包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行本申请实施例提供的方法。

本申请实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行申请实施例提供的方法。

应理解的是，上述处理器可以是处理器(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(FieldProgrammableGate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(Advanced RISC Machines，ARM)架构的处理器。

进一步地，可选的，上述存储器可以包括只读存储器和随机访问存储器。该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以包括只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以包括随机访问存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM均可用。例如，静态随机访问存储器(Static RAM，SRAM)、动态随机访问存储器(Dynamic Random Access Memory，DRAM)、同步动态随机访问存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机访问存储器(Double Data RateSDRAM，DDR SDRAM)、增强型同步动态随机访问存储器(EnhancedSDRAM，ESDRAM)、同步链接动态随机访问存储器(Sync link DRAM，SLDRAM)和直接内存总线随机访问存储器(DirectRambus RAM，DR RAM)。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生依照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中描述的或在此以其他方式描述的任何过程或方法可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中描述的或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

以上所述，仅为本申请的示例性实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请记载的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (15)

1.一种容器实例的管理迁移方法，包括：

获取目标容器实例在第一容器引擎中对应的管理配置数据，所述管理配置数据有对应的在第一容器引擎中的存储指引信息；

根据所述管理配置数据在第二容器引擎中的存储指引信息以及不同容器引擎中对应的存储指引信息的对应关系，将所述管理配置数据写入所述第二容器引擎；

启动所述第二容器引擎对所述目标容器实例的管理任务，以将所述目标容器实例的管理迁移至所述第二容器引擎。

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

在容器实例集群中确定第一容器引擎对应管理的容器实例，作为待执行管理迁移的目标容器实例。

3.根据权利要求1所述的方法，其中，所述获取目标容器实例在第一容器引擎中对应的管理配置数据包括：

从所述第一容器引擎对应的信息数据库中读取字段数据作为管理配置数据，所述字段数据包括第一类字段和/或第二类字段中包括的键值对，所述第一类字段包括字段标识和字段内容，所述第二类字段的字段标识为标签。

4.根据权利要求1所述的方法，其中，所述获取目标容器实例在第一容器引擎中对应的管理配置数据包括：

从所述第一容器引擎对应的信息数据库中读取所述目标容器实例对应的网络隔离状态和容器隔离状态，生成所述目标容器实例的命名空间对应的隔离配置数据，作为管理配置数据；

或，从所述第一容器引擎对应的信息数据库中查找第三类字段，通过访问所述第三类字段包括的访问路径获取挂载卷，作为管理配置数据，所述第三类字段包括字段标识为访问路径和挂载卷的多个字段。

5.根据权利要求1所述的方法，其中，所述获取目标容器实例在第一容器引擎中对应的管理配置数据包括：

从所述目标容器实例的宿主机读取所述目标容器实例的命名空间的网络接口对应的网络地址信息，作为管理配置数据。

6.根据权利要求1所述的方法，其中，所述获取目标容器实例在第一容器引擎中对应的管理配置数据包括：

根据所述管理配置数据在第一容器引擎中的存储指引信息，获取目标容器实例在所述第一容器引擎中对应的管理配置数据。

7.根据权利要求1所述的方法，其中，在所述获取目标容器实例在第一容器引擎中对应的管理配置数据之前，所述方法还包括：

基于容器引擎共用的接口规范，确定需要从所述第一容器引擎中获取的管理配置数据。

8.根据权利要求1所述的方法，其中，在所述获取目标容器实例在第一容器引擎中对应的管理配置数据之前，所述方法还包括：

确定同一管理配置数据在不同容器引擎中对应的存储指引信息，所述存储指引信息包括字段标识、键名、存储路径中至少一种。

9.根据权利要求1所述的方法，其中，所述将所述管理配置数据写入所述第二容器引擎中包括：

根据管理配置数据在第二容器引擎中对应的存储指引信息，将所述管理配置数据写入所述第二容器引擎中所述存储指引信息对应的存储位置。

10.根据权利要求1所述的方法，其中，所述启动所述第二容器引擎对所述目标容器实例的管理任务包括：

修改所述目标容器实例对应配置的容器引擎为第二容器引擎。

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

确认所述目标容器实例的命名空间中记录的管理配置数据与所述目标容器实例的实时运行状态一致。

12.根据权利要求1所述的方法，其中，在所述将所述管理配置数据写入所述第二容器引擎之后，所述方法还包括：

通过调用目标容器实例的响应模块对应的模拟装置，向所述第一容器引擎和第二容器引擎分别发送请求消息；

对比所述第一容器引擎和第二容器引擎分别反馈的响应消息，并根据对比结果确定目标容器实例的管理迁移成功。

13.根据权利要求12所述的方法，其中，所述根据对比结果确定目标容器实例的管理迁移成功包括：

去除设定对比维度对应的对比结果；

根据剩余对比结果一致，确定目标容器实例的管理迁移成功。

14.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，所述处理器在执行所述计算机程序时实现权利要求1-13中任一项所述的方法。

15.一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-13中任一项所述的方法。

Images